Роутердегі VPN жұмыс істейді, бірақ LAN клиенттерінде интернет жоқ

Роутер өз туннелі арқылы интернетке шығады, ал оның артындағы құрылғылар шықпайды. Жіберу, түрлендіру және қайтару маршруттары — бөлек рұқсаттар.

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

Ақауды LAN хостынан оқу

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

Егер клиенттің мекенжайы түрлендірілсе, қашықтағы жақ туннель мекенжайын көреді және сол жақтан бәрі сау көрінеді, ал клиент әлі де сәтсіздікке ұшырайды. Егер түрлендірілмесе, қашықтағы жақ клиенттің ішкі желісіне қайту маршрутын білуі керек, ал көптеген шлюздерде әдепкі бойынша мұндай маршрут жоқ. Қалай болғанда да, роутердің өз табысы маңызды емес, өйткені оның пакеттері жергілікті жасалып, жіберу жолынан ешқашан өтпеген.

Жергілікті және жіберілетін трафик әртүрлі

Linux және роутерлердің көптеген прошивкалары қораптың өзі жасаған пакеттерді одан өтетін пакеттерден өзгеше өңдейді. Шығыс тізбегі бірінші түрді көреді, жіберу тізбегі екіншісін көреді, ал роутердің өз трафигіне бапталған саясат жіберуді тиіспестен қалдыруы мүмкін.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Жіберу жалпы қосылғанын тексеріңіз, содан кейін шығыс тізбегінің орнына жіберу тізбегін оқыңыз. Шифрланған сыртқы қосылымға рұқсат беретін ереже — шифры ашылған пакеттерді жіберуге рұқсат беретін ереже емес, және осы екеуін шатастыру дәл осы белгіні тудырады. Туннельдің қосылуы тек біріншісін дәлелдейді.

Қайту жолы да болуы керек

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

Бірдеңені өзгертуден бұрын орналастыру екі жобаның қайсысын қолданатынын жазыңыз, өйткені түзетулер қарама-қарсы бағыттарды көрсетеді. Түрлендіруді қосу жетіспейтін қайту маршрутын жасырады және бастапқы мекенжайды қажет ететін қолданбаларды бұзады. Түрлендірусіз қайту маршрутын қосу қашықтағы файрвол таныс емес көзді тастағанда үнсіз сәтсіздікке ұшырайды. Біреуін таңдаңыз, құжаттаңыз және екінші жағын сәйкестендіріңіз.

Клиенттің DNS-і де сол шолуға жатады. Роутердің шешушісі жауап бере алады, ал басқа серверге бағытталған клиент мүлдем ештеңе алмайды.

Бір рұқсат етілген және бір тыйым салынған ағынды тексеру

Түзетуден кейін роутердің бар сессиясынан емес, клиенттен жаңа қосылымды сынаңыз. Содан кейін туннельді пайдаланбауы тиіс сегмент әлі де пайдаланбайтынын растаңыз.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Қашықтағы ұшта байқалған бастапқы мекенжайды тексеріңіз, өйткені бұл қай жобаның шын мәнінде жұмыс істеп тұрғанын айтады. Мекенжаймен қатар атауды іздеуді де тексеріңіз, өйткені шешушінің әрекеті сол қорап арқылы өтетін бөлек жол.

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

Қатысты мақалалар