VPN клиенттері серверге жетеді, бірақ LAN желісіне жетпейді: қай шешім?

Клиент OpenVPN серверінің туннель мекенжайына ping жасап, жауап алады, содан кейін сервердің LAN желісіндегі хостты сынап көреді және ештеңе алмайды. Бұл айырмашылық ақауды едәуір тарылтады: туннель көтерілген, жіберу жұмыс істеп тұрған болуы мүмкін, ал жауап қайта әкелмейтін есіктен шығады. Үш шешім бар және дұрысы нені басқаратыныңызға және неден бас тартуға дайын екеніңізге байланысты. Төмендегі үш сұраққа ретімен жауап беріңіз, сонда таңдау талғам мәселесі болудан қалады.

Алдымен қай бағыттың бұзылғанын анықтаңыз

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

Екеуін де өзгертуден бұрын екі машинаны да тексеріңіз. Серверден оның кестесі клиентке қандай жолмен жететінін сұраңыз; LAN желісіндегі хосттан ол сол мекенжайға қалай жететінін сұраңыз. Бірінші іздеу әдетте туннельді, екіншісі LAN маршрутизаторын көрсетеді, және бұл айырмашылық бір жолдағы ақау. Екі іздеу брандмауэр аудитінен арзан және мәселенің бағытын анықтайды.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Егер LAN желісіндегі хост қазірдің өзінде VPN серверін көрсетсе, сіздің мәселеңіз брандмауэр ережесі немесе MTU шегі, ал қайтару жолының жоқтығы емес. Сүзгіні түзету үшін маршрут қоспаңыз.

Бірінші сұрақ: алыстағы LAN желісінің маршрутизаторын өңдей аласыз ба?

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

Ол пулды біреу өзгерткен күні үнсіз істен шығады. Мәнді бір рет жазып қойыңыз және үш жердің кез келгеніндегі өзгерісті үшеуіне де өзгеріс деп санаңыз.

Қызметті орналастыратын NAS немесе Layer 3 коммутаторы сол маршрутты қажет етеді, егер ол бәрін сол маршруты бар маршрутизатор арқылы жібермесе. Ішкі желіні аяқтайтын құрылғыны тексеріңіз, тек интернетке қарайтынды емес. Шағын желілерде маршруттау туралы пікірі бар үш құрылғы жиі болады.

Екінші сұрақ: LAN желісі клиент мекенжайларын көруді тоқтата ала ма?

Маршрутизатор басқа біреуге тиесілі болса, VPN серверінде аудару ынтымақтастықты талап етпейді. LAN желісіндегі хост сервердің LAN мекенжайын көреді, оған жауап береді, ал сервер кері аударады. Сондықтан құрылғылар мен NAT негізіндегі қашықтан қатынау рөлдері осылай әрекет етеді.

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

Бағасы — тиесілілік: әр клиентке арналған мекенжайлар LAN журналдарынан жойылады. LAN желісіндегі хосттағы кез келген рұқсат тізімі сонда пулды емес, серверді атауы керек.

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

Үшінші сұрақ: сервердің өзі басқа туннельдің клиенті ме?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Көп интерфейсті хосттар клиент жағынан бірдей көрінетін сабақтас ақау қосады. Жауап төменірек метрикалы интерфейстен шығады, өйткені бастапқы мекенжай басқа кестеден таңдалған. Қайтару жолын іздеумен тексеріңіз, алға жол оны білдіреді деп ойламаңыз.

Содан кейін екі бағытты да, екі өлшемді де тексеріңіз

Өзгерістен кейін клиенттен LAN желісіндегі хостқа, содан кейін LAN желісіндегі хосттан клиентке ping жасаңыз. Екінші бағыт — адамдар өткізіп жіберетін бағыт, және ол толық емес аударма ережесін әшкерелейді. Екі нәтижені де уақыт белгісімен жазып алыңыз, кейінгі регрессия салыстырмалы болуы үшін.

Содан кейін нақты деректерді жылжытыңыз, өйткені үлкен тасымалдау тоқтап тұрғанда сәтті болатын кішкентай ping — MTU белгісі. Бұл ақау маршрутты түзеткеніңіз үшін өзіңізді құттықтағаннан кейін бірден пайда болады.

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