[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 написал(а): Сделал.
И где оно? :)
Что-то не так!
1500 - это на самой карте, на VPN ДОЛЖНО быть меньше! Или не туда смотрите... трейс в студию!
SysA написал(а):И где оно?
ВПН-сеть — 10.10.0.0/24
Подсеть клиента 192.168.10.0.28
Сервера — 192.168.1.0/24
Сами-то ВПН-пакеты может и другое МТУ имеют, точнее, у них точно другое: 1460 из-за того, что бегают через l2tp, но внутри-то они гоняют по 1500, что и наблюдаем на трейсе выше.
Я, вот, думаю, может, для tun0 принудительно mtu порезать?… До того же значения.
Сейчас вот так выглядит список интерфейсов, участвующих в работе: