Маршрутталған VPN клиенті серверге жетеді, бірақ LAN хосттарына жетпейді

Туннель көтеріледі, клиент VPN серверін пингтейді, ал бір қадам арғы машинадағы ортақ қалта ешқашан жауап бермейді. Клиент конфигурациясында мұны түсіндіретін ештеңе жоқ, өйткені сұрау шынымен клиенттен шығып, шынымен жетті. Сәтсіз болғаны қайтару жолы, ал сәтсіз болған құрылғы әдетте VPN хосты емес, LAN шлюзі. Жауап пакетін бақылау осы симптомдар класының бәрін түсіндіреді.

Жауапты қадағалаңыз, сұрауды емес

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

Неге бастау көзі 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

Бастау көзі мен межені тексеру серпімді желілік интерфейс нұсқаулығында құжатталған. Оны туннель трафигін шынымен тасымалдайтын интерфейсте орнатыңыз, сол данаға қосылған байланысы жоқ адаптерде емес.