Linux-те VPN жіберген маршруттарды статикалық маршруттардан қалай ажыратуға болады

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

1-қадам: префикстерді орнататын механизмді атаңыз

Әртүрлі протоколдар қолжетімділікті әртүрлі жолмен қамтамасыз етеді, ал мұның бәрін хабарландыру деп атау айырмашылықты жасырады. OpenVPN сервері басқару арнасы арқылы маршрут директивасын жібереді және pull сүзгісі кедергі жасамаса, клиент оны орнатады. WireGuard конфигурациясы рұқсат етілген префикстерді жергілікті түрде тізімдейді, клиент оларды криптокілт маршруттау үшін де, өзі қосатын маршруттар үшін де пайдаланады. IPsec туннелі серіктеспен трафик селекторларын келіседі, ал ядро сол селекторлардан маршруттарды орнатады.

Кез келген кестені оқымас бұрын туннеліңіздің осылардың қайсысын пайдаланатынын анықтаңыз. Қосылу кезінде жіберілген маршрут маршруттау протоколының хабарландыруы емес және префикстің алыс ұшының артында қолжетімді екеніне уәде бермейді. Түзетудің қайда жататынын анықтайтындықтан, механизмді префикстің қасына жазып қойыңыз.

2-қадам: кестені бір қосылым бойы салыстырыңыз

Туннель төмен кезде негізгі кестені сақтаңыз, оны көтеріңіз, қайта сақтаңыз және екі жазбаны салыстырыңыз. Пайда болғанның бәрі қосылымның өмірлік цикліне жатады, ал қалғаны жергілікті конфигурацияға жатады.

Оны ip route show table main > /tmp/route-down.txt арқылы жазып алыңыз, қосылыңыз және қайта жазып алыңыз. Сайт IPv6 пайдаланса, ip -6 route үшін де солай жасаңыз, өйткені онда жоқ префикс маршруттауға қатысы жоқ сияқты көрінетін ақаулар туғызады.

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

Бір префикс үшін екі жазба қатар болуы мүмкін, ал ядро төменірек метриканы таңдайды. Метрикасы 50 статикалық маршрут екеуі де көрініп тұрса да, 100-дегі жіберілген маршруттан басым бола береді, сондықтан «маршрут бар» және «трафик оны пайдаланады» деген екі түрлі тұжырым.

ip route get 10.20.5.7 арқылы ядродан тікелей сұраңыз және ол хабарлаған интерфейсті оқыңыз. Кестеде туннель маршруты тұрса да трафик физикалық адаптерден шықса, мұны VPN клиенті емес, метрика немесе префикс ұзындығы түсіндіреді. Туннельдің артында екенін білетін хост пен олай емес екенін білетін хост үшін іздеуді қайталаңыз, ал айырмашылық бөлінудің ниетке сай жұмыс істейтінін көрсетеді.

4-қадам: туннельден ұзақ өмір сүретін жазбаларды табыңыз

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

Тұрақты жағын таралымыңыз пайдаланатын жерде тексеріңіз: systemd-networkd бірлігі, NetworkManager профилі немесе клиенттің up қалтасындағы скрипт болуы мүмкін. Тірі кестені ip route del арқылы түзету тек келесі қосылымға дейін ғана сақталады. Бұл жоюды жөндеу емес, болжамды тексеру деп қараңыз.

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

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

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

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

6-қадам: ping емес, ресурсты сынаңыз

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

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