OpenVPN клиенті серверге жетеді, бірақ LAN хосттарына жетпейді: тексеру тізімі

Клиент қосылғанын айтады, туннель мекенжайы 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 жасау бұл жол туралы ештеңе дәлелдемейді, өйткені ол трафик туннельден ешқашан өтпейді.

Төртінші қадам: трансляция мен қайтару маршрутының арасынан таңдаңыз

Екі жөндеу тесікті жабады, және таңдаудың ping жұмыс істейтінінен тыс салдарлары бар. Көзді трансляциялау серверді көрінетін жіберуші етеді:

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

Ережені пулмен және LAN интерфейсімен шектеңіз, содан кейін оны тұрақты етіңіз, әйтпесе келесі брандмауэрді қайта жүктеу сіздің түзетуіңізді үнсіз жояды. Бағасы — сәйкестік: әр клиент LAN журналдарында және кіру ережелерінде VPN серверіне ұқсайды, және per-client policy becomes guesswork.

LAN маршрутизаторында VPN серверіне бағытталған 10.8.0.0/24 үшін статикалық маршрут клиент мекенжайларын көрінетін күйде ұстайды және сол маршрутизатор сіздікі болса, ұзақ мерзімді жақсырақ жауап. Көптеген алаңдар біраз уақыт екеуін де жүргізеді: NAT шұғыл жөндеу үшін және брандмауэр саясаты жазылған соң маршрут. Егер сервер пул емес, сайттан сайтқа әріптес болса, сервер жағына қашықтағы қосалқы желі үшін iroute да қажет, әйтпесе әріптес маршруты бар, бірақ клиент трафигі онымен ешқашан байланыспайды.

Бесінші қадам: клиенттен тексеріп, не өзгергенін жазыңыз

Шекті серверден емес, клиенттен жабыңыз. LAN хосттағы нақты қызметке қосылыңыз, содан кейін трансляция санағыштары iptables -t nat -L POSTROUTING -v -n арқылы жылжығанын растаңыз, өйткені нөл пакетті ереже — ешқашан сәйкес келмеген ереже. Қайтару бағыты қадағаланып жатқанына дәлел керек болғанда, conntrack -L -s 10.8.0.5 ағынды және оның күйін көрсетеді.

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