Kodėl vienas potinklis vis dar apeina VPN numatytąjį maršrutą

Perjungiate VPN į visą tunelį, didžioji dalis srauto paklūsta, ir tada vienas adresas atsako tiesiogiai — spausdintuvas, NAS, šuolio hostas 10.x tinkle. Akivaizdus aiškinimas — tunelis nuteka, todėl sumažinate numatytojo maršruto metriką ir niekas nesikeičia. Tas nepavykęs bandymas yra užuomina: numatytasis maršrutas yra atsarginis variantas, o ne nuosprendis. Maršruto paieška paima ilgiausią sutampantį prefiksą dar prieš palygindama metrikas, todėl /24 ir toliau laimi prieš /0, kad ir kokį skaičių prikabintumėte prie bet kurio iš jų. Kai ši tvarka aiški, nutekėjimas paprastai yra maršrutas, kurį kas nors sąmoningai įdiegė, arba prefiksas, kurio klientas niekada neketino uždengti.

Ką iš tikrųjų žada numatytasis maršrutas

0.0.0.0/0 atitinka bet kurią IPv4 paskirties vietą su nuliu bitų specifiškumo. Jis egzistuoja tam, kad hostas pasiektų viską, ko jo lentelė geriau neaprašo. Maršrutas į 192.168.1.0/24 neša 24 atitinkančius bitus, todėl 192.168.1.40 atveju jis laimi dar prieš kam nors palyginant metrikas, administracinį atstumą ar tai, ką klientas vadina prioriteto lauku. Ta pati taisyklė galioja Linux FIB, Windows maršrutų lentelėje ir BSD steke už macOS.

Įprastame LAN toks elgesys yra funkcija. Vietinis potinklis prijungtas tiesiogiai, spausdintuvas veikia toliau, kol tunelis neša jūsų naršymą, ir niekas nesukonfigūruota neteisingai. Klausimas, kurį verta kelti, yra ne kodėl tas vienas adresas eina tiesiai, o kuris prefiksas kurioje lentelėje jam atitinka ir kas jį ten įdėjo.

Pusiniai numatytieji maršrutai, arba kodėl numatytasis įrašas gali atrodyti nepaliestas

Švariausias pavyzdys yra redirect-gateway def1 OpenVPN. Užuot ištrynęs jūsų numatytąjį maršrutą ir jį pakeitęs, jis prideda 0.0.0.0/1 ir 128.0.0.0/1. Kartu pora apima visą IPv4, kiekvienas prefiksas ilgesnis už /0, ir abu įveikia maršrutizatoriaus numatytąjį, palikdami jį vietoje. Paleiskite maršrutų sąrašą po to ir pradinis numatytasis vis dar ten, vis dar rodo į jūsų tinklų sietuvą; tiesiog jis niekada nepasirenkamas interneto paskirties vietoms.

WireGuard wg-quick pasiekia tą patį rezultatą politikos pagrindu veikiančiu maršrutizavimu. Kai AllowedIPs apima 0.0.0.0/0, jis sukuria savo lentelę, siunčia ten pažymėtus paketus ir prideda taisyklę, kuri ignoruoja pagrindinės lentelės nulinio ilgio prefiksą. Pagrindinė lentelė išlaiko savo numatytąjį įrašą, o taisyklės nusprendžia, kad sąsajai priklausančiam srautui pirmiausia klausiama tunelio lentelės.

Abiem dizainams reikia tiksliai vieno maršruto už tunelio: hosto maršruto į paties VPN serverio adresą per pradinį tinklų sietuvą. Be jo klientas bandytų nešti tunelį kuriančius paketus tunelio viduje, ir ryšys niekada nebūtų užbaigtas. Todėl ne tunelio maršrutas jūsų lentelėje yra normalus net griežtame viso tunelio profilyje. Maršrutai, kuriuos verta kvestionuoti, yra tie, kurie apima paskirties vietas, kurios jums tikrai rūpi.

Metrikos nusprendžia lygiąsias, prefiksai nusprendžia laimėtojus

Metrikos lyginamos tik tarp kandidatų, kurie vienodai gerai atitinka paskirties vietą. Linux ip route get 10.20.5.9 atspausdina laimėtoją kartu su jo lentele, o ip route show table all išvardija kandidatus, įskaitant bet kokius pusinius numatytuosius ir bet kurią lentelę, į kurią nurodo taisyklė. Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 grąžina pasirinktą maršrutą ir šaltinio adresą, o Get-NetRoute rodo neapdorotą lentelę — bet efektyvioji kaina yra maršruto metrika plius sąsajos metrika, todėl lėtas adapteris gali pralaimėti lygiąsias, kurias tarsi laimi.

Trys atvejai apima didžiąją dalį to, ką pamatysite:

• Ta pati paskirties vieta, /24 prieš /0: /24 laimi pagal prefikso ilgį, ką bebūtų sakoma apie metrikas.
• Ta pati paskirties vieta, du /24 su skirtingomis metrikomis: laimi mažesnė efektyvioji metrika.
• Ta pati paskirties vieta, dvi lentelės, viena pasirinkta politikos taisyklės: taisyklė pirmiausia pasirenka lentelę, o prefiksų palyginimas vyksta joje.

Trečiasis atvejis yra ten, kur baigiasi dauguma šių pranešimų. Linux ip rule arba Windows VPN srauto filtras gali nusiųsti srautą į lentelę, kurioje niekada nebuvo tunelio numatytojo, o pagrindinė lentelė visą laiką atrodo nepriekaištingai.

Kas paprastai valdo apėjimą

Pradėkite nuo profilio, o ne nuo lentelės. Split-tunnel konfigūracijos ir VPN nustatymai atskirai programai sąmoningai palieka įvardintus prefiksus už tunelio; darbo profilis, kuris apsaugo vieną privatų potinklį ir leidžia bendram naršymui eiti tiesiai, elgiasi taip, kaip suprojektuotas, o jo nepaisymas sulaužo politiką, kurią jis turėjo užtikrinti. Microsoft VPN maršrutizavimo gairės brėžia tą pačią liniją tarp priverstinio tunelio srauto ir aiškių išimčių, todėl tai yra naudinga kryžminė patikra prieš ką nors redaguojant.

Toliau ieškokite likučių. Maršrutas, nurodantis į sąsają, kurios nebėra, arba į ankstesnio tinklo adresą, pasirodo po to, kai prijungimo stotys, USB adapteriai ir konteinerių tiltai ateina ir išeina. Ištrinti jį vieną kartą — ne pabaiga: NetworkManager ryšio profiliai, netplan failai ir Windows nuolatiniai maršrutai įdiegia jį iš naujo per kitą prisijungimą ar įkrovimą, todėl prieš ką nors redaguodami raskite failą ar profilį, kuris jį valdo.

Tada patikrinkite IPv6 atskirai. ip -6 route ir Get-NetRoute -AddressFamily IPv6 laiko atskirą būseną, atskirus numatytuosius ir atskirą kliento elgesį. Tik IPv4 auditas nieko nepasako apie dvigubo steko hostą, kuris tyliai teikia pirmenybę vietiniam IPv6 keliui, ir vien tai gali priversti klientą atrodyti kaip split-tunnel.

Patvirtinkite pačios programos srautu

Užrašykite paskirties vietą, kurią programa iš tikrųjų naudoja, tada paklauskite sistemos, kokį kelią ji rinktųsi iš šaltinio adreso, prie kurio ta programa prisiriša. ip route get 10.20.5.9 from 192.168.1.40 į tai atsako Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plius vietinis adresas tai daro Windows. Palyginkite rezultatą su tuo, ką teigia profilis. Naršyklės viešo IP puslapis tikrina vieną paskirties vietą vienu protokolu ir nieko nesako apie privatų adresą, nuo kurio prasidėjo skundas.

Pataisykite siauriausią objektą, kuris paaiškina skirtumą. Jei išimtis patvirtinta, užsirašykite prefiksą ir palikite jį; jei ne, pašalinkite maršrutą arba pridėkite aiškų siauresnį maršrutą per tunelį, o ne mažinkite numatytojo metriką. Metrikos sumažinimas negali pralenkti ilgesnio prefikso, o numatytojo redagavimas, kai du /1 maršrutai valdo interneto kelią, taip pat nieko nekeičia.

Tada iš naujo prijunkite tunelį ir pakartokite tą pačią užklausą. Klientai iš naujo įdiegia maršrutus kiekvieno prisijungimo metu, todėl pakeitimas, kuris išlieka tik iki kito rankos paspaudimo, nėra išbandytas. Jei kelias vis dar skiriasi, likę įtariamieji yra politikos taisyklė, antra lentelė arba kliento pusės filtras — ne numatytasis maršrutas.

• Įvardinkite paskirties vietą ir šaltinio adresą, kuriuos programa tikrai naudoja.
• Atspausdinkite laimintį maršrutą su ip route get arba Find-NetRoute.
• Patikrinkite, ar interneto kelią valdo /1 pora, ar politikos lentelė.
• Išvardinkite kiekvieną ilgesnį už /0 prefiksą, kuris atitinka paskirties vietą.
• Pakartokite IPv6 patikrinimą atskirai.
• Atsekite likusį maršrutą atgal į failą, profilį ar filtrą, kuris jį įdiegia.
• Prisijunkite iš naujo ir dar kartą paleiskite užklausą, prieš vadindami tai sutvarkytu.

Jei visi septyni sutinka su profilu, tunelis daro būtent tai, kam buvo sukonfigūruotas, o pataisymas priklauso profiliui, o ne metrikai.