Защо сървър зад VPN клиент отговаря през тунела

Входящите връзки към хост, който също изпълнява VPN клиент, се провалят по много специфичен начин: ръкостискането пристига, демонът отговаря, а клиентът не получава нищо обратно. Нищо не блокира порта. Отговорът е излязъл през тунела, защото тунелът притежава маршрута по подразбиране и ядрото маршрутизира отговорите по дестинация, а не по спомен откъде е дошла заявката. Демонът е наред и портът е отворен.

Отговорът се маршрутизира, не се помни

VPN клиент, който инсталира маршрут по подразбиране, добавя запис, който превъзхожда LAN шлюза, било то по метрика или чрез разделяне на пространството на две по-конкретни половини. Изходящите пакети вече избират интерфейса на тунела. Ядрото никога не пита откъде първоначално е пристигнал пакетът, на който се отговаря. Това единствено пропускане обяснява всеки следващ симптом.

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

Строгото филтриране на обратния път може да изхвърли входящия пакет, преди демонът изобщо да го прочете. Проверете този брояч първо, защото филтрирано изхвърляне и маршрутизационна грешка изглеждат еднакво отвън.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Първата команда показва кой маршрут по подразбиране печели в момента. Втората съобщава дали строгото филтриране важи глобално или за интерфейс, а третата показва всяко правило във веригата за препращане, което може да участва.

Три начина да запазите обратния път

Изключването на дестинацията на услугата от тунела е най-тясната опция. Маршрут до хост, насочен към LAN шлюза, плюс демон, обвързан с физическия адрес вместо с всеки адрес, държи този един поток извън тунела. Промяната е локална и лесна за отмяна.

Политическото маршрутизиране е общият отговор. Правило, закрепено към адреса на източника или към маркировка на защитната стена, избира таблица, чийто маршрут по подразбиране сочи към WAN шлюза, докато собствените връзки на хоста продължават да използват тунела. Дръжте приоритета явен, за да не може правилото по-късно да бъде засенчено.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

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

Транслацията на източника е третата опция и единствената, която оцелява пред рутер, който вече прави NAT пред услугата. Отговорът трябва да се върне към този рутер, а маскирането към WAN интерфейса го постига, като същевременно скрива клиента от журналите на услугата. Ръчната подмяна на маршрута по подразбиране след свързване е диагностика, защото клиентът пренаписва таблицата при следващото повторно свързване.

Когато кутията маршрутизира и за LAN

Същият отказ се появява един хоп по-нататък, когато хостът маршрутизира за устройства зад себе си. Входяща връзка се препраща към вътрешно устройство, чийто единствен обратен път е тунелът, и отговорът достига до външния клиент от адреса на доставчика. Вътрешното устройство работи правилно през цялото време.

Тогава проследяването на връзки вижда отговор за поток, който никога не е записвало, и го изхвърля. Транслацията на дестинацията доставя входящата връзка до устройството, а транслацията на източника прави отговора да изглежда идващ от самия рутер.

Политически маршрут, който задържа препращания порт на WAN, докато собственият трафик на рутера използва тунела, е по-изчистеният еквивалент. Без транслация на източника отговорът е адресиран до външния клиент и вътрешното устройство няма никакъв маршрут до този адрес.

Три проверки, които разделят причините

Направете три проверки: връзка към кутията от интернет, връзка от нея към публичен хост и търсене на име. Когато първите две се разминават, виновен е обратният път. Когато имената се провалят в двете посоки, резолверът е друга повреда, която просто споделя тунела.

Първо оправете въпроса с маршрутизирането, после гледайте имената. Смесването на двете е начинът работещ сървър да бъде обвинен за счупен резолвер.

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