![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Знаете ли вы? Нет, вы не знаете
какие мудаки пишут софт в циске.
В общей сложности дня три я убил на то, чтобы понять, почему их родной VPN-клиент под линукс с их же родным VPN-концентратором работает крайне странно. То есть, TCP-сессии по этому туннелю устанавливаются. И по ним даже немножко байтиков передать можно. Но именно немножко. Как только пытаешься передать в любую сторону сколько-нибудь значительный объем данных, всё затыкается нафиг.
Так вот, лечится это так: ПОСЛЕ установки VPN-соединения надо на физическом сетевом интерфейсе вручную поднять MTU обратно до того значения, которое было раньше. Клиент его с какого-то бодуна опускает. Наверное, чтобы IPSec'овые заголовки помещались. Только в таком виде оно ни хрена не работает.
Ненатуралы.
Update: Ага, разбежался. Оказалось, что это лечит только в одну сторону - от концентратора к клиенту. То есть, читать почту я уже могу. А писать - нет, при отправке письма всё равно затыкается.
Update 2: А если поставить MTU 1400, то можно отправлять большие объёмы данных. Но принимать уже нельзя. То есть, посылать почту можно. Но только без TLS, а то как придёт от сервера сертификат, так всё и заткнётся. И файлы по scp, соответственно, при MTU 1500 копируются только в одну сторону, а при 1400 - только в другую.
Интересно, а есть такое промежуточное значение, чтобы в обе стороны работало?
Какой левой задней ногой они это писали? И ведь что противно, под виндой оно работает нормально, без всяких плясок с бубнами.
Update 3. Угораздило же меня так вляпаться. Оказывается, драйвер e100 в ядрах 2.6.4+ умудряетя молча дропать пакеты, у которых размер больше MTU. А софт, написанный криворукими писателями из циски, умудряется такие пакеты генерировать, даже при туннелировании через TCP. Ненатуралы еще три раза.
Короче, рекомендованная замена e100 на eepro100, КАЖЕТСЯ, проблему решила.
В общей сложности дня три я убил на то, чтобы понять, почему их родной VPN-клиент под линукс с их же родным VPN-концентратором работает крайне странно. То есть, TCP-сессии по этому туннелю устанавливаются. И по ним даже немножко байтиков передать можно. Но именно немножко. Как только пытаешься передать в любую сторону сколько-нибудь значительный объем данных, всё затыкается нафиг.
Так вот, лечится это так: ПОСЛЕ установки VPN-соединения надо на физическом сетевом интерфейсе вручную поднять MTU обратно до того значения, которое было раньше. Клиент его с какого-то бодуна опускает. Наверное, чтобы IPSec'овые заголовки помещались. Только в таком виде оно ни хрена не работает.
Ненатуралы.
Update: Ага, разбежался. Оказалось, что это лечит только в одну сторону - от концентратора к клиенту. То есть, читать почту я уже могу. А писать - нет, при отправке письма всё равно затыкается.
Update 2: А если поставить MTU 1400, то можно отправлять большие объёмы данных. Но принимать уже нельзя. То есть, посылать почту можно. Но только без TLS, а то как придёт от сервера сертификат, так всё и заткнётся. И файлы по scp, соответственно, при MTU 1500 копируются только в одну сторону, а при 1400 - только в другую.
Интересно, а есть такое промежуточное значение, чтобы в обе стороны работало?
Какой левой задней ногой они это писали? И ведь что противно, под виндой оно работает нормально, без всяких плясок с бубнами.
Update 3. Угораздило же меня так вляпаться. Оказывается, драйвер e100 в ядрах 2.6.4+ умудряетя молча дропать пакеты, у которых размер больше MTU. А софт, написанный криворукими писателями из циски, умудряется такие пакеты генерировать, даже при туннелировании через TCP. Ненатуралы еще три раза.
Короче, рекомендованная замена e100 на eepro100, КАЖЕТСЯ, проблему решила.
no subject
ОЧЕНЬ странное чувство.
(no subject)
Re: Reply to your comment...
no subject