Zašto jedna podmreža i dalje zaobilazi vašu VPN zadanu rutu

Prebacite VPN na puni tunel, većina saobraćaja posluša, a onda jedna adresa odgovara direktno — štampač, NAS, skakački host na 10.x. Očigledno čitanje je da tunel curi, pa spustite metriku na zadanoj ruti i ništa se ne mijenja. Taj neuspjeli pokušaj je trag: zadana ruta je rezerva, a ne presuda. Pretraga ruta uzima najduži prefiks koji se poklapa prije nego što uopšte uporedi metrike, pa /24 nastavlja da pobeđuje /0 bez obzira koji broj prikačite na bilo koju od njih. Kad je taj poredak jasan, curenje je obično ruta koju je neko namjerno instalirao ili prefiks koji klijent nikada nije namjeravao pokriti.

Šta zadana ruta zapravo obećava

0.0.0.0/0 poklapa se sa svakim IPv4 odredištem sa nula bitova specifičnosti. Postoji da bi host mogao doći do svega što njegova tabela ne opisuje bolje. Ruta do 192.168.1.0/24 nosi 24 odgovarajuća bita, pa za 192.168.1.40 pobeđuje prije nego što iko uporedi metrike, administrativnu distancu ili kako god klijent naziva polje prioriteta. Isto pravilo važi u Linux FIB-u, Windows tabeli rutiranja i BSD steku iza macOS-a.

Na normalnom LAN-u to ponašanje je funkcija. Lokalna podmreža je direktno povezana, štampač nastavlja da radi dok tunel nosi vaše pregledanje, i ništa nije pogrešno konfigurisano. Pitanje koje vrijedi postaviti nije zašto ta jedna adresa ide direktno, nego koji prefiks u kojoj tabeli joj odgovara i ko ga je tamo stavio.

Poluzadane rute, ili zašto zadani unos može izgledati netaknut

OpenVPN-ov redirect-gateway def1 je najčistiji primjer. Umjesto da obriše vašu zadanu rutu i zamijeni je, dodaje 0.0.0.0/1 i 128.0.0.0/1. Zajedno par pokriva cijeli IPv4, svaki prefiks je duži od /0, i oba pobeđuju zadanu rutu rutera dok je ostavljaju na mjestu. Pokrenite spisak ruta poslije i originalna zadana ruta je još tu, još pokazuje na vaš gejtvej; samo nikada nije izabrana za internet odredišta.

WireGuard-ov wg-quick postiže isti ishod kroz rutiranje po politici. Kad AllowedIPs pokriva 0.0.0.0/0, pravi sopstvenu tabelu, šalje označene pakete tamo i dodaje pravilo koje ignoriše prefiks nulte dužine glavne tabele. Glavna tabela zadržava svoj zadani unos, a pravila odlučuju da se tabela tunela prva konsultuje za saobraćaj koji interfejs posjeduje.

Oba dizajna trebaju tačno jednu rutu izvan tunela: host rutu do sopstvene adrese VPN servera kroz originalni gejtvej. Bez nje bi klijent pokušao da nosi pakete koji grade tunel unutar tunela, i veza se nikada ne bi uspostavila. Zato je ruta koja nije tunelska u vašoj tabeli normalna čak i na strogom profilu punog tunela. Rute koje vrijedi dovesti u pitanje su one koje pokrivaju odredišta do kojih vam je zaista stalo.

Metrike odlučuju nerešeno, prefiksi odlučuju pobjednika

Metrike se porede samo među kandidatima koji jednako dobro odgovaraju odredištu. Na Linuxu, ip route get 10.20.5.9 ispisuje pobjednika zajedno sa njegovom tabelom, a ip route show table all navodi kandidate, uključujući sve poluzadane rute i svaku tabelu na koju pokazuje neko pravilo. Na Windowsu, Find-NetRoute -RemoteIPAddress 10.20.5.9 vraća izabranu rutu i izvornu adresu, dok Get-NetRoute prikazuje sirovu tabelu — ali efektivni trošak je metrika rute plus metrika interfejsa, pa spor adapter može izgubiti neriješeno koje izgleda da dobija.

Tri slučaja pokrivaju većinu onoga što ćete vidjeti:

• Isto odredište, /24 protiv /0: /24 pobeđuje po dužini prefiksa, šta god metrike kažu.
• Isto odredište, dva /24 sa različitim metrikama: pobeđuje niža efektivna metrika.
• Isto odredište, dvije tabele, jedna izabrana pravilom politike: pravilo prvo bira tabelu, a poređenje prefiksa se dešava unutar nje.

Treći slučaj je mjesto gdje završava većina ovih izvještaja. Linux ip rule ili Windows VPN filter saobraćaja može poslati saobraćaj u tabelu koja nikada nije držala zadanu rutu tunela, a glavna tabela izgleda savršeno cijelo vrijeme.

Ko obično posjeduje zaobilaznicu

Počnite od profila, ne od tabele. Split-tunnel konfiguracije i VPN postavke po aplikaciji namjerno ostavljaju imenovane prefikse izvan tunela; radni profil koji štiti jednu privatnu podmrežu i pušta opšte pregledanje direktno ponaša se kako je dizajniran, a njegovo nadjačavanje krši politiku koju je trebao da sprovodi. Microsoftovo uputstvo za VPN rutiranje povlači istu liniju između prisilno tunelisanog saobraćaja i izričitih izuzetaka, što ga čini korisnom unakrsnom provjerom prije nego što bilo šta uredite.

Zatim potražite ostatke. Ruta koja pokazuje na interfejs koji više ne postoji, ili na adresu iz prethodne mreže, pojavljuje se nakon što dođu i odu doking stanice, USB adapteri i kontejnerski mostovi. Brisanje jednom nije kraj: NetworkManager profili veze, netplan datoteke i Windows stalne rute je ponovo instaliraju pri sljedećem povezivanju ili podizanju, pa pronađite datoteku ili profil koji je posjeduje prije nego što bilo šta uredite.

Zatim provjerite IPv6 zasebno. ip -6 route i Get-NetRoute -AddressFamily IPv6 drže odvojeno stanje, odvojene zadane rute i odvojeno ponašanje klijenta. Revizija samo IPv4 ne govori ništa o hostu sa dvostrukim stekom koji tiho preferira izvornu IPv6 putanju, a samo to može učiniti da klijent izgleda split-tunnelisan.

Potvrdite stvarnim tokom aplikacije

Zabilježite odredište koje aplikacija zaista koristi, pa pitajte sistem za putanju koju bi preuzela sa izvorne adrese koju ta aplikacija veže. ip route get 10.20.5.9 from 192.168.1.40 odgovara na to na Linuxu; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus lokalna adresa to radi na Windowsu. Uporedite rezultat s onim što profil tvrdi. Stranica javnog IP-a u pregledaču testira jedno odredište na jednom protokolu i ne govori ništa o privatnoj adresi koja je započela žalbu.

Popravite najuži objekat koji objašnjava razliku. Ako je izuzetak odobren, zapišite prefiks i ostavite ga; ako nije, uklonite rutu ili dodajte izričitu užu rutu kroz tunel umjesto da spuštate metriku zadane rute. Spuštanje metrike ne može nadjačati duži prefiks, a uređivanje zadane rute dok dvije /1 rute posjeduju internet putanju takođe ništa ne mijenja.

Zatim ponovo povežite tunel i ponovite isti upit. Klijenti ponovo instaliraju rute pri svakom povezivanju, pa promjena koja traje samo do sljedećeg rukovanja nije testirana. Ako putanja i dalje odstupa, preostali osumnjičeni su pravilo politike, druga tabela ili filter na strani klijenta — ne zadana ruta.

• Navedite odredište i izvornu adresu koju aplikacija zaista koristi.
• Prikažite pobjedničku rutu pomoću ip route get ili Find-NetRoute.
• Provjerite da li /1 par ili tabela politike posjeduje internet putanju.
• Navedite svaki prefiks duži od /0 koji odgovara odredištu.
• Ponovite IPv6 provjeru zasebno.
• Pratite rutu koja je ostala do datoteke, profila ili filtera koji je instalira.
• Ponovo se povežite i ponovo pokrenite upit prije nego što to nazovete riješenim.

Ako se svih sedam slaže s profilom, tunel radi tačno ono za šta je konfigurisan, a popravka pripada profilu, a ne metrici.