[openvpn][странное] Малопонятные глюки с SSH

Добрый вечер.

Имеется настроенная openvpn-сеть. С маршрутами, фаерволлами и тд и тп всё прекрасно: пинги ходят, компьютеры видят разрешённые к проходу порты в другой сети и проч. и проч.

Когда работаешь из сети, в которой находится сервер, то рабочие программы ведут себя как положено: ssh выводит тексты и отправляет команды, веб-сервера отдают контент. То же самое наблюдается при работе из подсети филиала. Т.е. тут никаких неожиданностей нет.

Но когда я пытаюсь поработать из дома, то сталкиваюсь со следующей проблемой: подключаюсь по ssh, ввожу какую-нибудь команду, например ls и… не вижу вывода. Более того, весь дальнейший вывод и ввод «замораживается». При этом, tcpdump показывает, что в ответ на вышеуказанную команду на мой компьютер пакеты пришли. И что всё ок. По протоколу rdesktop вроде всё нормально, а вот по http опять странности: пока грузится текст, всё отлично, всё летает, как только попадается картинка, даже самая маленькая, останавливается где-то на 5% её загрузка, тогда как текст грузится полностью.

Но самое странное в этом всём как то, что при работе из подсетей филиалов такого не наблюдается вообще, так и то, что данная проблема носит непериодический характер, но по закону подлости, проявляется в самый неприятный момент. Нет, я, конечно, могу пробрасывать туннель через ssh, но хотелось бы понять, почему openvpn так страдает, почему наблюдается какой-то «дикий» шейпинг, хотя ничего подобного не настраивалось и не включалось.

На всякий случай привожу клиентский конфиг:

client
dev tun
proto udp

# адрес сервера в центрально офисе
remote 1.1.1.1 11111
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
ns-cert-type server
tls-client

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/1.crt
key /etc/openvpn/keys/1.key
# tls-auth /etc/openvpn/keys/ta.key 1

log-append /var/log/openvpn.log
status /var/log/openvpn-status.log


user nobody
group nobody

Как говорил, он идентичный всем прочим клиентским.

Никто не сталкивался с такой проблемой?

я сталкивался с нечто

я сталкивался с нечто похожим, но у меня была проблема в некорректном значении MTU на интерфейсе клиента(отличным от того, что на интерфейсе на сервере). При этом тоже: вроде бы все работает, но вот такие черезжопности наблюдались. rsync к примеру стопорился на этапе получения списка файлов для синхронизации... Сделай tracepath проблемный_сервер при подключении через VPN...

Нейтральность - высшее достижение сознания!

Сделал. 1500 mtu, плюс, на

Сделал. 1500 mtu, плюс, на шлюзах с двух сторон прописано: $IPT -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Единственное, что может влияет, так это то, что со стороны клиента выход в интернеты осуществляется через l2tp, но вышеуказанная команда для iptables должна этот момент шлифовать.

HolyBoy написал(а): Сделал.

HolyBoy написал(а):
Сделал.

И где оно? :)

HolyBoy написал(а):
1500 mtu, плюс, на шлюзах с двух сторон прописано: $IPT -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Что-то не так!
1500 - это на самой карте, на VPN ДОЛЖНО быть меньше! Или не туда смотрите... трейс в студию!

SysA написал(а):И где оно?

SysA написал(а):
И где оно? :)

tracepath -n 192.168.1.252
 1:  192.168.10.2                                          0.113ms pmtu 1500
 1:  192.168.10.1                                          0.275ms 
 1:  192.168.10.1                                          0.198ms 
 2:  10.10.0.1                                            18.895ms 
 3:  192.168.1.252                                        20.868ms reached
     Resume: pmtu 1500 hops 3 back 62

ВПН-сеть — 10.10.0.0/24
Подсеть клиента 192.168.10.0.28
Сервера — 192.168.1.0/24

SysA написал(а):
Что-то не так!
1500 - это на самой карте, на VPN ДОЛЖНО быть меньше! Или не туда смотрите... трейс в студию!

Сами-то ВПН-пакеты может и другое МТУ имеют, точнее, у них точно другое: 1460 из-за того, что бегают через l2tp, но внутри-то они гоняют по 1500, что и наблюдаем на трейсе выше.

Я, вот, думаю, может, для tun0 принудительно mtu порезать?… До того же значения.

Сейчас вот так выглядит список интерфейсов, участвующих в работе:

2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1460 qdisc pfifo_fast state UNKNOWN qlen 3
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".