![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
какие мудаки пишут софт в циске.
В общей сложности дня три я убил на то, чтобы понять, почему их родной 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, КАЖЕТСЯ, проблему решила.
Tags:
Re: Reply to your comment...