Kāpēc viena apakštīkla joprojām apiet VPN noklusējuma maršrutu

Jūs pārslēdzat VPN uz pilnu tuneli, lielākā daļa trafika paklausa, un tad viena adrese atbild tieši — printeris, NAS, lēciena hosts 10.x tīklā. Acīmredzamais lasījums ir tāds, ka tunelis noplūst, tāpēc jūs samazināt noklusējuma maršruta metriku, un nekas nemainās. Šis neveiksmīgais mēģinājums ir pavediens: noklusējuma maršruts ir rezerves variants, nevis spriedums. Maršruta meklēšana ņem garāko atbilstošo prefiksu, pirms tā vispār salīdzina metrikas, tāpēc /24 turpina uzvarēt /0, lai kādu skaitli jūs pievienotu jebkuram no tiem. Kad šī kārtība ir skaidra, noplūde parasti ir maršruts, ko kāds apzināti instalējis, vai prefikss, ko klients nekad nav domājis segt.

Ko noklusējuma maršruts patiešām sola

0.0.0.0/0 atbilst jebkuram IPv4 galamērķim ar nulli bitu specifiskuma. Tas pastāv, lai hosts varētu sasniegt visu, ko tā tabula neapraksta labāk. Maršruts uz 192.168.1.0/24 nes 24 atbilstošus bitus, tāpēc 192.168.1.40 tas uzvar, pirms kāds salīdzina metrikas, administratīvo attālumu vai to, ko klients sauc par prioritātes lauku. Tas pats noteikums ir spēkā Linux FIB, Windows maršrutēšanas tabulā un BSD stekā aiz macOS.

Parastā LAN šāda uzvedība ir funkcija. Vietējā apakštīkla ir tieši pievienota, printeris turpina darboties, kamēr tunelis nes jūsu pārlūkošanu, un nekas nav nepareizi konfigurēts. Jautājums, ko ir vērts uzdot, nav kāpēc tā viena adrese iet tieši, bet gan kurš prefikss kurā tabulā tai atbilst un kas to tur ievietoja.

Pusnoklusējuma maršruti jeb kāpēc noklusējuma ieraksts var izskatīties neskarts

Vistīrākais piemērs ir redirect-gateway def1 OpenVPN. Tā vietā, lai dzēstu jūsu noklusējuma maršrutu un aizstātu to, tas pievieno 0.0.0.0/1 un 128.0.0.0/1. Kopā pāris nosedz visu IPv4, katrs prefikss ir garāks par /0, un abi pārspēj maršrutētāja noklusējuma maršrutu, atstājot to savā vietā. Palaidiet pēc tam maršrutu sarakstu, un sākotnējais noklusējuma maršruts joprojām ir tur, joprojām norāda uz jūsu vārteju; tas vienkārši nekad netiek izvēlēts interneta galamērķiem.

WireGuard wg-quick sasniedz to pašu ar uz politiku balstītu maršrutēšanu. Kad AllowedIPs nosedz 0.0.0.0/0, tas izveido savu tabulu, sūta tur marķētos paketes un pievieno noteikumu, kas ignorē galvenās tabulas nulles garuma prefiksu. Galvenā tabula saglabā savu noklusējuma ierakstu, un noteikumi izlemj, ka saskarnei piederošajam trafikam vispirms tiek jautāta tuneļa tabula.

Abiem dizainiem vajag tieši vienu maršrutu ārpus tuneļa: hosta maršrutu uz paša VPN servera adresi caur sākotnējo vārteju. Bez tā klients mēģinātu nest tuneli būvējošās paketes tuneļa iekšienē, un savienojums nekad netiktu pabeigts. Tāpēc maršruts, kas nav tunelis, jūsu tabulā ir normāls pat stingrā pilna tuneļa profilā. Maršruti, kurus ir vērts apšaubīt, ir tie, kas nosedz galamērķus, kas jums patiešām svarīgi.

Metrikas izlemj neizšķirtu, prefiksi izlemj uzvarētājus

Metrikas salīdzina tikai starp kandidātiem, kas vienlīdz labi atbilst galamērķim. Linux ip route get 10.20.5.9 izdrukā uzvarētāju kopā ar tā tabulu, un ip route show table all uzskaita kandidātus, tostarp jebkurus pusnoklusējuma maršrutus un jebkuru tabulu, uz kuru norāda noteikums. Windows Find-NetRoute -RemoteIPAddress 10.20.5.9 atgriež izvēlēto maršrutu un avota adresi, bet Get-NetRoute rāda neapstrādāto tabulu — taču faktiskās izmaksas ir maršruta metrika plus saskarnes metrika, tāpēc lēns adapteris var zaudēt neizšķirtu, kuru šķietami uzvar.

Trīs gadījumi nosedz lielāko daļu tā, ko redzēsiet:

• Tas pats galamērķis, /24 pret /0: /24 uzvar prefiksa garuma dēļ, ko vien saka metrikas.
• Tas pats galamērķis, divi /24 ar atšķirīgām metrikām: uzvar zemākā faktiskā metrika.
• Tas pats galamērķis, divas tabulas, vienu izvēlas politikas noteikums: noteikums vispirms izvēlas tabulu, un prefiksu salīdzināšana notiek tajā.

Trešais gadījums ir vieta, kur beidzas lielākā daļa šo ziņojumu. Linux ip rule vai Windows VPN trafika filtrs var nosūtīt trafiku uz tabulu, kurā nekad nav bijis tuneļa noklusējuma, un galvenā tabula visu laiku izskatās nevainojami.

Kam parasti pieder apiešana

Sāciet ar profilu, nevis tabulu. Split-tunnel konfigurācijas un VPN iestatījumi atsevišķai lietotnei apzināti atstāj nosauktus prefiksus ārpus tuneļa; darba profils, kas aizsargā vienu privātu apakštīklu un ļauj vispārējai pārlūkošanai iet tieši, uzvedas tā, kā projektēts, un tā ignorēšana lauž politiku, kuru tam bija jāīsteno. Microsoft VPN maršrutēšanas vadlīnijas iezīmē to pašu līniju starp piespiedu tuneļa trafiku un skaidriem izņēmumiem, kas tās padara par noderīgu savstarpēju pārbaudi pirms kaut kā rediģēšanas.

Pēc tam meklējiet atlikumus. Maršruts, kas norāda uz saskarni, kuras vairs nav, vai uz iepriekšējā tīkla adresi, parādās pēc tam, kad dokstacijas, USB adapteri un konteineru tilti nāk un iet. Dzēst to vienu reizi nav beigas: NetworkManager savienojuma profili, netplan faili un Windows pastāvīgie maršruti to pārinstalē nākamajā savienojumā vai startā, tāpēc pirms kaut kā rediģēšanas atrodiet failu vai profilu, kuram tas pieder.

Pēc tam pārbaudiet IPv6 atsevišķi. ip -6 route un Get-NetRoute -AddressFamily IPv6 uztur atsevišķu stāvokli, atsevišķus noklusējumus un atsevišķu klienta uzvedību. Tikai IPv4 audits neko nepasaka par divkāršā steka hostu, kas klusi dod priekšroku vietējam IPv6 ceļam, un tikai tas vien var likt klientam izskatīties kā split-tunnel.

Apstipriniet ar pašas lietotnes plūsmu

Pierakstiet galamērķi, ko lietotne faktiski izmanto, pēc tam pajautājiet sistēmai ceļu, ko tā izvēlētos no avota adreses, kurai šī lietotne piesaistās. ip route get 10.20.5.9 from 192.168.1.40 uz to atbild Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 plus vietējā adrese to dara Windows. Salīdziniet rezultātu ar to, ko apgalvo profils. Pārlūka publiskās IP lapa pārbauda vienu galamērķi vienā protokolā un neko nepasaka par privāto adresi, no kuras sākās sūdzība.

Izlabojiet šaurāko objektu, kas izskaidro atšķirību. Ja izņēmums ir apstiprināts, pierakstiet prefiksu un atstājiet to; ja nav, noņemiet maršrutu vai pievienojiet skaidru šaurāku maršrutu caur tuneli, nevis samaziniet noklusējuma metriku. Metrikas samazināšana nevar pārspēt garāku prefiksu, un noklusējuma rediģēšana, kamēr divi /1 maršruti pārvalda interneta ceļu, arī neko nemaina.

Pēc tam no jauna pievienojiet tuneli un atkārtojiet to pašu vaicājumu. Klienti pārinstalē maršrutus katrā savienojumā, tāpēc izmaiņas, kas saglabājas tikai līdz nākamajai rokasspiedienam, nav pārbaudītas. Ja ceļš joprojām atšķiras, atlikušie aizdomās turamie ir politikas noteikums, otra tabula vai klienta puses filtrs — nevis noklusējuma maršruts.

• Nosauciet galamērķi un avota adresi, ko lietotne patiešām izmanto.
• Izdrukājiet uzvarētāja maršrutu ar ip route get vai Find-NetRoute.
• Pārbaudiet, vai interneta ceļu pārvalda /1 pāris vai politikas tabula.
• Uzskaitiet katru garāku par /0 prefiksu, kas atbilst galamērķim.
• Atkārtojiet IPv6 pārbaudi atsevišķi.
• Izsekojiet palikušo maršrutu atpakaļ uz failu, profilu vai filtru, kas to instalē.
• Pievienojieties no jauna un vēlreiz palaidiet vaicājumu, pirms saucat to par izlabotu.

Ja visi septiņi saskan ar profilu, tunelis dara tieši to, kam tas tika konfigurēts, un labojums pieder profilam, nevis metrikai.