LAN маршрутизаторы және VPN клиенті: екі құрылғы, екі маршрут кестесі

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

Маршрутқа қол тигізбес бұрын екі секіруді сызыңыз

Мысал ретінде мына орналасуды алыңыз: LAN хосттары 192.168.50.0/24, кәдімгі маршрутизатор 192.168.50.1, арнайы клиент 192.168.50.15 және қашықтағы LAN 10.60.0.0/24, ол тек осы клиент ұстаған туннель арқылы ғана қолжетімді. Екі жеке ауқымның ешқайсысы екіншісімен қабаттаспайды, және туннельдің өз мекенжай жоспары бар.

Екі жеке ауқым да маңызды, өйткені олар қай құрылғы жауап бере алатынын анықтайды. Қашықтағы жақ пакеттің клиенттің туннель мекенжайынан келе жатқанын көреді, ал оның жауабы 192.168.50.0/24-ке қайтатын жол табуы керек. Тек шығыс бағыт конфигурацияланса, сұрау жұмыс істеуі мүмкін, ал жауап жоғалады.

1-қадам: маршрутизаторды туннельге емес, клиентке бағыттаңыз

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

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Бұл жазба «оны туннель жасай алатын машинаға жеткіз» дейді. Ол туннельдің қалай құрылатыны туралы ештеңе айтпайды және клиенттің өз маршрутын алмастырмайды. Басқарылатын маршрутизаторда балама құрылғының статикалық маршруттар бетінде тұрады; Linux маршрутизаторында ол LAN-ға ие интерфейс конфигурациясына жатады, сіз жабатын shell-ге емес.

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

2-қадам: клиентке туннель жағында өз маршрутын беріңіз

Клиент енді 10.60.0.0/24 үшін пакет алады және өз кестесін қарайды. Егер оның туннель конфигурациясы сол префикс үшін маршрут орнатса, пакет шифрланған күйде жалғасады. Егер орнатпаса, пакет әдеттегі әдепкіге сәйкес келеді және 192.168.50.1-ге қайтады, ол оны қайтадан клиентке жібереді.

Бірдеңе қоспас бұрын қараңыз:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

Ілмек, пайда болған кезде, іс жүзінде шексіз емес: TTL әр өтуде төмендейді және пакет уақыт асып кетуі туралы хабармен өледі. Сондықтан қайталанатын traceroute циклді меңзеуі мүмкін, ал жай ғана қайта жібермейтін клиент сол пакетті үнсіз тастайды.

3-қадам: қайта жіберуге рұқсат беріңіз және қайту жолын таңдаңыз

Қабылдау мен қайта жіберу — әртүрлі рұқсаттар. Клиенттегі net.ipv4.ip_forward=1 ядро деңгейінде транзитке рұқсат береді, ал брандмауэр ережесі оны LAN интерфейсі мен туннель арасында әлі де рұқсат етуі керек. Клиенттің өз басқару бетіне қатынауға рұқсат беретін ереже қашықтағы LAN-ға транзитке рұқсат бермейді, және сол хост локальді түрде ping-ге жауап бергенде бұл айырмашылықты байқамау оңай.

Қашықтағы жақта айна мәселесі бар. Ол 192.168.50.0/24-дің осы аутентификацияланған клиент арқылы қолжетімді екенін білуі керек. OpenVPN арқылы бұл әдетте сервер конфигурациясы итеретін әр клиентке арналған маршрутты, немесе серверде клиенттің артындағы LAN-ды жариялайтын клиентке тән файлды білдіреді. Онсыз қашықтағы LAN жауапты тастайды немесе оны өзінің әдепкі шлюзіне, яғни интернетке жібереді.

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

4-қадам: екі шешімді де тұрақты етіп жасаңыз, содан кейін нақты жолды тексеріңіз

Әр маршруттың иесі бар, ал иесі — жүктеу кезінде немесе қайта қосылу кезінде қайта жасалатын конфигурация. Маршрутизаторда бұл статикалық маршрут жазбасы болуы мүмкін; клиентте бұл VPN профилі, NetworkManager немесе systemd-networkd болуы мүмкін. Туннельді қайта қосып, клиентті қайта жүктеу арқылы тексеріңіз, содан кейін өзгеріске сенудің орнына кестені қайта оқыңыз.

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

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