Savaoff

Оно! Работает! Спасибо!! Не гуглится, а всю эту и другие темы перелопатить нереально...

Коллеги, помогите! Был openssl 1.0.2r с поддержкой госта 2001. Утилиткой P12FromGostCSP подпись сохраняли в котейнер p12.pfx. В этом году новая подпись, купили P12FromGostCSP, сохранили в p12.pfx. Но - openssl 1.0.2 конвертить это в .pem не хочет: Error outputting keys and certificates 140615572178584:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239: 140615572178584:error:0606F076:digital envelope routines:EVP_PKCS82PKEY:unsupported private key algorithm:evp_pkey.c:84:TYPE=1.2.643.7.1.1.1.1 Ок, стави новый openssl , 1.1.1, откуда, как известно, нынче выпилен гост. Хорошие люди сделали поддержку госта к текущей версии: https://github.com/gost-engine/engine С этим engine (вернее библиотекой gost.so, которую он делает) openssl 1.1.1 поддерживает гост2012. Однако есть проблема: новый openssl 1.1.1 не понимает паролей в контейнере p12.pfx! Какой бы пароль не был установлен при экспорте программой P12FromGostCSP (простой пароль, сложный, пустой) - пишет Mac verify error: invalid password? причём, если "старый" openssl 1.0.2 писал MAC Verify ok и для прошлогоднего контейнера p12, и для нового p12 (ругаясь на алгоритм), то "новый" openssl не может конвертнуть ни старый, ни новый p12, пароль якобы не тот. Куда смотреть?..

Ещё иола была...))

кто-то врезался в оптику (ваш местный СОРМ) и так глючит ;)

так расскажите, интересно же, в чем особенности менталитета

Есть такой опыт, положительный, есть 2 rs, два "железных" 65х каталиста, между собой bgp full mesh, тщательно настроеный. Аплинкам пофиг, их и спрашивать не надо - просите сетку крупнее /30 , бгп с аплинками поднимаете на софтроутере, в анонсах указываете ip next-hop "железного" роутера, ему же скармливаете итоговую таблицу с софтроутера, тоже с ip next-hop аплинков, что бы он знал, куда чего форвардить. "железный" и софтовый роутер должны иметь по одному ip в p2p сетке от каждого провайдера.

+1, иного выхода всё равно нет. Ну продержатся sup720-3bxl ещё полгода-год с натяжкой, а дальше что? префиксов всё больше... Ещё помогает унести ipv6 с sup720, хоть там и не очень много маршрутов, но свободной памяти становится как-то резко больше. ipv6 уж точно можно на soft-router перенести.

*между делом* управление железкой (telnet, ssh, etc) зафильтровали по ipv6? ;)

Впервые слышу. Реально, впервые слышу "то перестает, то память кончается". 65ая железка не для детей конечно, требует особого подхода. Но предсказуемая и вот тем что вы описали в реальности не страдает. Это или руки или партия памяти битая. Наверняка Вы ещё многого не слышали и когда-нибудь впервые услышите :) Кстати с выборочным не анонсированием части маршрутов части пирам сталкивались и в Корбине. У нас - на двух железках, у них - не знаю на скольки. Побороть не удалось ни нам, ни им, хотя они долго долбали TAC на эту тему.

в начале 2007го FV было 140 тыс маршрутов, если не ошибаюсь. Сейчас почти 500. 6тонник отличная железка, но при нескольких FV на текущий момент - не стабильная. То тупо память кончается (особенно, если на нем еще и несколько FV ipv6), то перестает анонсить часть префиксов некоторым пирам и с этим ничего не поделать, только перезагрузка.. а искать менее глючный иос путём перебора на боевом роутере - не серьезно.

добавлю, что многие аплинки позволяют с помощью bgp community управлять localpref ваших анонсов в своей сети

ip community-list ISP1_ASXXX_PREF_LIST _ASXXX$ это интересная конструкция :) Вероятно, имелось ввиду ip as-path access-list номер_access_листа permit _ASXXX$ ? И в роут-мапе match as-path номер_access_листа

Нда, не поленился, посмотрел архив одной уважаемой конференции.. давал там в 2007м году объявление о сходных вакансиях и сходных условиях... народ в основном гугукал: http://www.lexa.ru/inet-admins/msg16471.html

я его активно юзаю. им можно даже тегированный трафик гонять. собственно, все минусы tcp-туннелинга заметны на больших rtt и/или наличии пакетлосса. и на wifi это бывает заметно(когда клиентов много или же трафика). openvpn и vtund используют один и тот же модуль ядра - "tun" написаный Maxim Krasnyansky <max_mk@yahoo.com>. При этом vtund собственно он же и написал тоже. В режиме tap'а прекрасно гоняется тегированый трафик, что openvpn, что vtund, подтверждаю. Оба умеют что поверх tcp, что по верх udp строить туннели. Изначально юзал vtund, но он долго не восстанавливет тунель, если физика обвалилась-поднялясь - во всяком случае мне не удалось его отстроить. openvpn в этом плане шустрее. Зато vtund умеет и lzo и zip компрессию, а openvpn только lzo. Через туннели openvpn между офисами по всей РФ прекрасно работает и голос и видео.

OpenVPN хорошо работает, и виндовый tap-интерфейс умеет создавать. И тунель строит поверх udp|tcp, на выбор. Есть еще такой vtund, он умеет gzip'овать трафик, если очень надо, остальные возможности как у openvpn, только под винду нет версий.