Q про openVPM

Коллеги, выручайте!

Ситуация - две производственные площадки, связанные через интернет с помощью openVPN. До сегодняшнего дня все работало безпроблемно. А сегодня, где-то перед обедом - литовский народный праздник и пушной зверек пришел.
Итак, конфигурация:
1. openVPN-сервер на первой площадке.
2. маршрутизатор DLINK-804. Реализован проброс 1194 и 443 портов на openVPN, 50022 - на ssh.
3. собственно интернет, где пакеты перекладываются между двумя провайдерами, к которым подключены площадки.
4. Шлюзовой комп на второй площадке, где развернут openVPN-клиент. То есть в настоящее время без роутера, напрямую, для чистоты экперимента.

Что наблюдаю:

- По ssh через порт 50022 маршрутизатора ремутно на сервера первой площадки зайти могу. То есть нормальная связность есть.

- OpenVPN клиент второй площадки посылает запросы на установление соединения на IP маршрутизатора, на порт 1194. Маршрутизатор транслирует эти запросы openVPN-серверу. Сервер посылает обратно ответы. Все это видно через tcpdump. А вот до клиента эти ответы не долетают. tcpdump показывает только openVPN- запросы. Соответственно коннект валится по таймауту.
Меняю порт 1194 на 443. Те же ойцы. Добавляю на маршрутизаторе первой площадки проброс на openVPN-сервер через порт 51149. Пофигу. На сервере tcpdump показывает, что он и принимает и отправляет пакеты. А на клиенте нет никаких входящих от сервера пакетов.

Коллеги, наведите на путь избавления от напасти такой. Я не понимаю, что происходит...

Пока приладил костлек небольшой, по PREROUTING'у в iptables перекидываю терминальный трафик (22-й порт) на нужный порт, это работает, Терминальный доступ к базе данных обеспечил, но... Трафика в VPN-туннеле у меня много разного, весь так не перекинешь.

А какой трафик идет через аплинк 804-го роутера? Насколько я помню больше 4Мбит он выжимает с трудом....

Также сделайте traceroute с обеих точек. Возможно это наведет вас на мысли.

elve написал:

А какой трафик идет через аплинк 804-го роутера? Насколько я помню больше 4Мбит он выжимает с трудом....

Также сделайте traceroute с обеих точек. Возможно это наведет вас на мысли.

А мне больше и не надо. У меня исходящие каналы по 2 мегабита всего. Под них труба и настроена. Ну а на вход 804-й нормально держит и 8-12 мегабит. Так что дело не в его скорости.
Да и traceroute не шибко поможет. Полное ощущение, что появился контентный фильтр где то. Который режет пакеты, содержащие именно openvpn-трафик. Так как до хоста, на котором живет openVPN-сервер, я через роутер добираюсь без проблем. Роутер ssh-пакеты пробрасывает в обе стороны. Бес проблем. А вот идущие точно по такому же маршруту openvpn-пакеты - пропадают. На обратном ходе, ко мне, теряются. Причем перенастройка роутера на иные public-порты под этот трафик не помогает. У меня нет ни одной разумной идеи.

traceroute могло бы помочь увидеть разницу между маршрутами туда и оттуда (если она есть).

Если openvpn настроено по udp... попробуйте настроить по tcp.

elve написал:

traceroute могло бы помочь увидеть разницу между маршрутами туда и оттуда (если она есть).

Если openvpn настроено по udp... попробуйте настроить по tcp.

Я, конечно, виноват, что не уточнил. Понадеялся на телепатические способности читателей. OpenVPN у меня настроено именно по TCP. И именно поэтому я не понимаю, почему SSH-соединение с ремутным хостом через роутер, который пробрасываются нужные пакеты, устанавливается без проблем, все пакеты ходят, а такое же TCP-соединение, но по протоколу openvpn, обламывается по таймауту, ответные пакеты режутся и до отправителя не доходят.

Попробуйте tcptraceroute для нужного порта сделать. Сразу будет видно на каком из хопов режется трафик.

З.Ы. tcptraceroute это отдельная утилита такая.

elve написал:

Попробуйте tcptraceroute для нужного порта сделать. Сразу будет видно на каком из хопов режется трафик.

Блин... Он вообще не режется. Заказываю трафик с порта 1194 сервера, он прекрасно долетает по этой утилите до цели.
Заказываю соединение openVPN, пакеты на сервер приходят, он отвечает (tcpdump это прекрасно кажет), до источника ничего не доходит. Если заказываю openvpn-соединение не сильно-ремутно, а из той IP-сети, где стоит сервер с роутером, соединение устанавливается беспроблемно. То есть - сервер пакеты отдает честно. И другой хост их получает и отрабатывает. А вот через интернет - они не доходят. Как будто у них c этого интерфейса TTL=1... Но тогда почему работает ssh? Он же по тому же маршруту ходит...

Если все ходит, то нужно внимательно проверять настройки серверов и маршрутизаторов. Вдруг в файрволе есть какой-нибудь массовый запрет, куда попадает порт 1194. Ну или опечатка в конфиге или еще чего....

Иногда магия случается, но как показывает опыт, все чары рассеиваются, когда умом доходишь что и где не работает.

elve написал:

Иногда магия случается, но как показывает опыт, все чары рассеиваются, когда умом доходишь что и где не работает.

Эт-то точно... Здесь ситуация малопонятная совершенно. А именно - точная конфигурация серверной части:
1. Два различных провайдера, доступ к которым через отдельные 804-е роутеры. Которые настроены пробрасывать входящий на 1194-й порт роутера трафик на соответствующий порт сервера openvpn
2. Сервер openvpn выполнен как отказоустойчивый сервис под управлением pacemaker. То есть имеем блуждающий IP-адрес, на который и кидают трафик эти роутеры.
3. Далее - роутеры (по ряду причин) сидят в различных внутренних IP-сетях, один в 192.168.41.0, другой - в 192.168.42.0. Соответственно - блужает не один кластерный адрес сервера, а пара. При этом, каждый сервер имеет и основной IP-адрес, на который я извне попадаю через ssh.
4. Далее - настройка блуждающих адресов в инициализирующем скрипте:

/sbin/ifconfig br0:2  192.168.41.2 netmask 255.255.255.0 broadcast 192.168.41.255 mtu 1472 arp up
/sbin/ifconfig br0:20 192.168.42.2 netmask 255.255.255.0 broadcast 192.168.42.255 mtu 1472 arp up
/sbin/ip rule add from 192.168.41.2 table 101
/sbin/ip route add 192.168.41.0/24 dev br0 proto kernel scope link src 192.168.41.2 table 101
/sbin/ip route add default via 192.168.41.1 table 101
/sbin/ip rule add from 192.168.42.2 table 102
/sbin/ip route add 192.168.42.0/24 dev br0 proto kernel scope link src 192.168.42.2 table 102
/sbin/ip route add default via 192.168.42.1 table 102

Всё, вроде, формально правильно. Поднимаем интерфейсы, прописываем на них дефолтные маршруты в зависимости от источника. И... это не работает по сети 192.168.41.0 (по другой - проблем нет)
Особенность в том, что "базовый" адрес хоста тоже лежит в этой сети. Все дефолные маршруты настроены корректно. А вот не отрабатывает, если источник - 192.168.41.2.
Сейчас немного переконфигурировал роутер на проблемном направлении. Стал прокидывать трафик не на кластерный IP, а на IP реальной железки. И оно заработало.
Так что есть над чем подумать...