Рутирани VPN клијент стиже до сервера, али не до LAN домаћина

Тунел се подиже, клијент пингује VPN сервер, а дељена фасцикла на машини један скок даље никада не одговара. Ништа у конфигурацији клијента то не објашњава, јер је захтев заиста напустио клијента и заиста стигао. Оно што није успело је пут назад, а уређај који није успео је обично LAN гејтвеј, а не VPN домаћин. Праћење пакета одговора објашњава целу ову класу симптома.

Пратите одговор, не захтев

VPN сервер дешифрује пакет клијента и прослеђује га у LAN, а адреса клијента остаје у пољу извора. Домаћин одредишта одговара на ту адресу, и сада његова сопствена табела рутирања одлучује о свему. Његов подразумевани гејтвеј не зна ништа о базену тунела, па одговор одлази ка интернет провајдеру и бива одбачен негде на том путу.

Код клијента симптом је тихи тајмаут: без одбијања, без ресетовања, само ништа. Прегледање дељене фасцикле се блокира, пинг извештава да нема одговора, а серверски дневници изгледају здраво јер је сервер обавио свој посао.

Поставите повратну путању тамо где домаћини гледају

Сваки 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

Зашто изгледа да изворни 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

Провера извора и одредишта је документована у упутству за еластични мрежни интерфејс. Подесите је на интерфејсу који заиста носи саобраћај тунела, а не на неповезаном адаптеру прикљученом на исту инстанцу.