OpenVPN клиентът стига до сървъра, но не и до LAN хостовете: контролен списък

Тунелът е вдигнат и сървърът отговаря, но LAN хостовете мълчат. Проследете пакета от маршрута на клиента до обратния път, после изберете NAT или статичен маршрут.

Клиентът казва, че е свързан, адресът на тунела отговаря на ping, а нищо в офисната LAN не реагира. Виждам това след почти всяко обновяване на клиента и първият инстинкт е да отворя защитната стена, което обикновено е грешният ход: тунелът е наред и прекъсването е на един от трите скока, които пакетът трябва да премине. Извървете пътя в реда, в който пакетът го изминава – първо маршрутът на клиента, после препредаването на сървъра, после обратният път – и ще намерите виновника за няколко минути.

Първа стъпка: наблюдавайте решението за маршрутизиране на клиента

Преди да пипате сървъра, докажете, че клиентът изпраща пакета в тунела. Попитайте ядрото кой интерфейс би използвало за един конкретен LAN хост, вместо да четете цялата таблица:

ip route get 192.168.50.10

Ако отговорът посочва физическия ви адаптер и офисния шлюз, никаква промяна от страна на сървъра не може да помогне. OpenVPN раздава маршрути само когато сървърът ги избутва, затова търсете push "route 192.168.50.0 255.255.255.0" в конфигурацията на сървъра и след това свържете клиента отново. Повечето клиенти прилагат избутаните маршрути при свързване, а не при презареждане на профила.

В Windows същият въпрос има друга команда. Find-NetRoute -RemoteIPAddress 192.168.50.10 отпечатва интерфейса и следващия скок, който стекът би избрал, а route print -4 показва дали избутаният префикс изобщо съществува.

Втора стъпка: потвърдете, че сървърът ще препредаде пакета

Ако маршрутът на клиента е правилен, пакетът стига до сървъра и сървърът трябва да се съгласи да го препредаде. Превключвателят на ядрото е първата порта и sysctl net.ipv4.ip_forward трябва да върне 1. Задаването му с echo 1 > /proc/sys/net/ipv4/ip_forward работи до следващото рестартиране и точно затова същата жалба се връща седмици по-късно.

Запишете го някъде, което преживява рестарт:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Втората порта е таблицата за филтриране. Хост с инсталиран Docker често носи политика FORWARD със стойност DROP и тунелът наследява това решение. iptables -L FORWARD -v -n показва както политиката, така и броячите на пакети; ако политиката е DROP, препредаването се нуждае от явно разрешение за посоката от тунела към LAN и още едно за отговора.

Трета стъпка: проследете пакета до LAN и търсете отговора

Наблюдавайте двете страни на сървъра едновременно. Заснемете на тунела и на LAN интерфейса, филтрирано до един клиент и един хост, за да остане изходът четим:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Заявки, които се появяват на tun0 и отново на eth0 с източник 10.8.0.x, последвани от тишина, означават, че пакетът е пристигнал и отговорът е отишъл другаде. LAN хостът отговаря на шлюза си по подразбиране, този шлюз няма маршрут за VPN пула и отговорът умира на LAN рутера. Пингването на LAN хоста от сървъра не доказва нищо за този път, защото този трафик никога не пресича тунела.

Четвърта стъпка: избор между транслация и обратен маршрут

Две поправки затварят дупката и изборът има последствия отвъд това дали ping работи. Транслацията на източника прави сървъра привиден изпращач:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Ограничете правилото до пула и LAN интерфейса, после го направете постоянно, иначе следващото презареждане на защитната стена тихо премахва поправката ви. Цената е идентичност: всеки клиент изглежда като VPN сървъра в LAN журналите и правилата за достъп и per-client policy becomes guesswork.

Статичен маршрут за 10.8.0.0/24 на LAN рутера, сочещ към VPN сървъра, запазва адресите на клиентите видими и е по-добрият дългосрочен отговор, когато този рутер е ваш. Много обекти известно време поддържат и двете – NAT за незабавната поправка и маршрута, щом политиката на защитната стена бъде написана. Ако сървърът е партньор „обект към обект“, а не пул, страната на сървъра също се нуждае от iroute за отдалечената подмрежа, иначе партньорският маршрут съществува, но трафикът на клиентите никога не се свързва с него.

Пета стъпка: проверете от клиента и запишете какво се промени

Затворете цикъла от клиента, не от сървъра. Свържете се към реална услуга на LAN хоста, после потвърдете, че броячите на транслацията са се преместили с iptables -t nat -L POSTROUTING -v -n, защото правило с нула пакета е правило, което никога не е съвпадало. conntrack -L -s 10.8.0.5 показва потока и състоянието му, когато имате нужда от доказателство, че обратната посока се проследява.

Оставете бележка в конфигурацията на сървъра: коя подмрежа, кой интерфейс, кое правило и дали LAN рутерът носи обратен маршрут. Следващия път, когато обновяване на клиента изтрие избутан маршрут, тази бележка превръща гасенето на пожар в поправка на един ред.

Подобни статии