Неге бір ішкі желі әлі де VPN-нің әдепкі маршрутын айналып өтеді

VPN-ді толық туннельге ауыстырасыз, трафиктің көбісі бағынады, содан кейін бір мекенжай тікелей жауап береді — принтер, NAS, 10.x-тегі секіру хосты. Айқын оқылым — туннель ағып жатыр, сондықтан әдепкі маршруттың метрикасын төмендетесіз, бірақ ешнәрсе өзгермейді. Сол сәтсіз әрекет — белгі: әдепкі маршрут — қосалқы нұсқа, үкім емес. Маршрут іздеуі метрикаларды салыстырмас бұрын ең ұзын сәйкес префиксті алады, сондықтан /24 кез келген санды тіркесеңіз де /0-ден жеңе береді. Бұл тәртіп айқын болғанда, ағу әдетте біреудің әдейі орнатқан маршруты немесе клиент ешқашан жаппақ болмаған префикс болып шығады.

Әдепкі маршрут шын мәнінде не уәде етеді

0.0.0.0/0 кез келген IPv4 межелісіне нөл биттік нақтылықпен сәйкес келеді. Ол хост өз кестесі жақсырақ сипаттамаған кез келген нәрсеге жете алуы үшін бар. 192.168.1.0/24-ке маршрут 24 сәйкес бит алып жүреді, сондықтан 192.168.1.40 үшін ол біреу метрикаларды, әкімшілік қашықтықты немесе клиент басымдық өрісі деп атайтын нәрсені салыстырмас бұрын жеңеді. Дәл осы ереже Linux FIB-інде, Windows маршруттау кестесінде және macOS артындағы BSD стегінде қолданылады.

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

Жартылай әдепкі маршруттар, немесе әдепкі жазба неге тиіспеген болып көрінуі мүмкін

Ең таза мысал — OpenVPN-дегі redirect-gateway def1. Әдепкі маршрутыңызды жойып, оны алмастырудың орнына ол 0.0.0.0/1 және 128.0.0.0/1 қосады. Бірге жұп бүкіл IPv4-ті қамтиды, әр префикс /0-ден ұзын, және екеуі де маршрутизатордың әдепкісін орнында қалдырып жеңеді. Кейін маршруттар тізімін іске қосыңыз — бастапқы әдепкі әлі сонда, әлі шлюзіңізді көрсетеді; ол жай ғана интернет межелілері үшін ешқашан таңдалмайды.

WireGuard-тың wg-quick құралы саясатқа негізделген маршруттау арқылы сол нәтижеге жетеді. AllowedIPs 0.0.0.0/0-ді қамтығанда ол өз кестесін жасайды, белгіленген пакеттерді сонда жібереді және негізгі кестенің нөлдік ұзындықтағы префиксін елемейтін ереже қосады. Негізгі кесте өз әдепкі жазбасын сақтайды, ал ережелер интерфейске тиесілі трафик үшін алдымен туннель кестесіне жүгінетінін анықтайды.

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

Метрикалар теңдікті шешеді, префикстер жеңімпазды шешеді

Метрикалар тек межеліге бірдей жақсы сәйкес келетін үміткерлер арасында салыстырылады. Linux-та ip route get 10.20.5.9 жеңімпазды өз кестесімен бірге басып шығарады, ал ip route show table all үміткерлерді тізімдейді, оның ішінде кез келген жартылай әдепкі және ереже нұсқайтын кез келген кесте. Windows-та Find-NetRoute -RemoteIPAddress 10.20.5.9 таңдалған маршрут пен бастау мекенжайын қайтарады, ал Get-NetRoute шикі кестені көрсетеді — бірақ тиімді құны маршрут метрикасы қосу интерфейс метрикасы, сондықтан баяу адаптер жеңіп жатқандай көрінетін теңдікті жоғалтуы мүмкін.

Үш жағдай көретін нәрселеріңіздің көбін қамтиды:

• Бір межелі, /24 — /0-ге қарсы: /24 префикс ұзындығы бойынша жеңеді, метрикалар не десе де.
• Бір межелі, әртүрлі метрикалы екі /24: төменірек тиімді метрика жеңеді.
• Бір межелі, екі кесте, біреуі саясат ережесімен таңдалған: ереже алдымен кестені таңдайды, ал префикстерді салыстыру оның ішінде жүреді.

Үшінші жағдай — осы есептердің көбі аяқталатын жер. Linux-тың ip rule немесе Windows-тың VPN трафик сүзгісі трафикті ешқашан туннельдің әдепкісін ұстамаған кестеге жіберуі мүмкін, ал негізгі кесте бүкіл уақыт бойы мінсіз көрінеді.

Бұл айналып өту әдетте кімге тиесілі

Кестеден емес, профильден бастаңыз. Split-tunnel конфигурациялары мен әр қолданбаға арналған VPN параметрлері аталған префикстерді әдейі туннельден тыс қалдырады; бір жеке ішкі желіні қорғайтын және жалпы шолуды тікелей жіберетін жұмыс профилі жобаланғандай әрекет етеді, ал оны асыра жазу оның орындауға тиіс саясатын бұзады. Microsoft-тың VPN маршруттау нұсқаулығы мәжбүрлі туннельделген трафик пен айқын ерекшеліктер арасында дәл осы шекараны сызады, бұл оны бірдеңені өңдеу алдында пайдалы айқас тексеріске айналдырады.

Содан кейін қалдықтарды іздеңіз. Енді жоқ интерфейске немесе алдыңғы желінің мекенжайына нұсқайтын маршрут доктау станциялары, USB адаптерлері мен контейнер көпірлері келіп-кеткеннен кейін пайда болады. Оны бір рет жою — соңы емес: NetworkManager қосылым профильдері, netplan файлдары және Windows-тың тұрақты маршруттары оны келесі қосылымда немесе жүктеуде қайта орнатады, сондықтан бірдеңені өңдеу алдында оған ие файлды немесе профильді табыңыз.

Содан кейін IPv6-ны бөлек тексеріңіз. ip -6 route және Get-NetRoute -AddressFamily IPv6 бөлек күйді, бөлек әдепкілерді және бөлек клиент мінез-құлқын ұстайды. Тек IPv4 аудиті табиғи IPv6 жолын үнсіз қалайтын қос стекті хост туралы ештеңе айтпайды, және тек осының өзі клиентті split-tunnel болып көрінуіне әкелуі мүмкін.

Қолданбаның өз ағынымен растаңыз

Қолданба шын мәнінде қолданатын межеліні жазып алыңыз, содан кейін жүйеден сол қолданба байланысатын бастау мекенжайынан қандай жолмен жүретінін сұраңыз. ip route get 10.20.5.9 from 192.168.1.40 Linux-та бұған жауап береді; Find-NetRoute -RemoteIPAddress 10.20.5.9 қосу жергілікті мекенжай Windows-та мұны істейді. Нәтижені профильдің мәлімдегенімен салыстырыңыз. Браузердің ашық IP беті бір протоколда бір межеліні тексереді және шағымды бастаған жеке мекенжай туралы ештеңе айтпайды.

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

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

• Қолданба шын мәнінде қолданатын межелі мен бастау мекенжайын атаңыз.
• Жеңген маршрутты ip route get немесе Find-NetRoute арқылы басып шығарыңыз.
• Интернет жолына /1 жұбы немесе саясат кестесі ие ме, соны тексеріңіз.
• Межеліге сәйкес келетін /0-ден ұзын әрбір префиксті тізімдеңіз.
• IPv6 тексеруін бөлек қайталаңыз.
• Қалған маршрутты оны орнататын файлға, профильге немесе сүзгіге дейін бақылаңыз.
• Түзетілді деп атамас бұрын қайта қосылып, сұрауды қайта іске қосыңыз.

Егер жетеуі де профильмен келіссе, туннель дәл өзі конфигурацияланғанды істеп жатыр, ал түзету метрикаға емес, профильге жатады.