Маршрутизиран VPN клиент достига сървъра, но не хостовете в LAN

Маршрутизиран клиент може да се свърже и въпреки това да губи всеки отговор от хост в LAN. Добавете обратния маршрут на шлюза, след което проверете препращането и филтрирането на пакети.

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

Следвайте отговора, не заявката

VPN сървърът декриптира пакета на клиента и го препраща в LAN, като адресът на клиента остава в полето за източник. Хостът местоназначение отговаря на този адрес и сега собствената му таблица за маршрутизация решава всичко. Шлюзът му по подразбиране не знае нищо за пула на тунела, затова отговорът тръгва към интернет доставчика и се изхвърля някъде по този път.

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

Поставете обратния маршрут там, където гледат хостовете

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Защо Source NAT изглежда, че поправя нещата

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Облачният път изисква три настройки

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

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

Изпълнете проверките в този ред

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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

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