Marsruutimistabel vs tegelik otsing: kuhu VPN-i liiklus läheb

Marsruutimistabeli dump on VPN-i tõrkeotsingus kõige vähem kasulik diagnostika ja kõige sagedamini kleebitav. Nelikümmend rida prefikseid ütleb teile, mida masin oleks võinud teha, mitte mida ta ebaõnnestunud päringu jaoks tegi. Mehhanism, mida te tegelikult soovite, on otsing: kui on antud see allikas ja see sihtkoht, siis milline reegel sobis, millist tabelit konsulteeriti ning milline liides ja järgmine hüpe väljusid. Alustage ühest sihtkohast ja ühest allikast, seejärel lugege tabelit selle küsimusega käes, ja sama väljund muutub müra asemel tõendiks.

Tabel on kandidaatide kogum, mitte otsus

Iga kirje kirjeldab prefiksit ja seda, mida teha sellele vastava liiklusega: saata see liidesele, anda järgmisele hüppele või visata ära. Miski selles loendis ei ole kavatsuse järgi järjestatud, ja kirje, mis inimesele tundub kõige täpsem, ei ole alati see, mille kernel valib, sest valik järgib pikimat prefiksi vastet ja võrdsete prefiksite korral metrikat.

Nii et esimene samm on küsida kernelilt, mitte lugeda loendit. Otsingukäsk vastab sihtkoha kohta ja allikaargumendiga vastab täpse paari kohta, mida edastatud või seotud ühendus kasutaks:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Iga ülaltoodud aadress on dokumentatsiooni näide. Mõte on vastuse kujus: liides, valitud allikaaadress, lüüs ja tabel, kust kirje tuli. Kui see väljund ei vasta liidesele, mida ootasite, olete probleemi ühe käsuga lokaliseerinud, ja ükski täieliku tabeli lugemine ei oleks teile öelnud, milline kandidaat võitis.

Otsing läbib kõigepealt reeglid, seejärel tabelid

Linuxis on otsus kahes etapis. Poliitikareeglid hinnatakse prioriteedi järjekorras ja esimene sobiv reegel nimetab tabeli, mida konsulteerida; see tabel teeb seejärel pikima prefiksi vaste. Reegel võib sobida allika, sihtkoha, tulemüürimärgi, liidese või kombinatsiooni järgi, mistõttu võib põhitabeli dump olla täiesti täpne ja teie uuritava paketi jaoks täiesti ebaoluline.

ip rule show
ip route show table all | head -40
ip route show table 100

Kui reegel saadab liikluse teie VPN-i poolist tabelisse 100, siis on tähtis tabel 100, ja põhitabel on peibutis. See on ka allikapõhise marsruutimise mehhanism ruuteril: samal sihtkohal võib olla kaks erinevat vastust sõltuvalt sellest, kust pakett tuli, ja ainult allikaargumendiga otsing paljastab, milline kehtib.

IPv6-l on oma reeglid ja tabelid. Mõlemat perekonda käitav disain vajab mõlemat otsingut, ja töötav IPv4 vastus ei ütle midagi v6 tee kohta, mida kahe virna klient võib eelistada.

Mida VPN-i klient paigaldab

Kliendid tavaliselt ei asenda vaikimisi marsruuti, sest see lõhuks tunnelil enda välise tee. Nad paigaldavad midagi täpsemat, mis võidab prefiksi pikkuse järgi: paar pool-vaikimisi marsruute, mis katavad 0.0.0.0/1 ja 128.0.0.0/1, on klassikaline trikk, kuna mõlemad on pikemad prefiksid kui 0.0.0.0/0 ja koos katavad kogu ruumi. Teised paigaldavad konkreetsed privaatsed prefiksid pluss poliitikareegli, ja mõned lisavad märgi, et tabada ainult valitud liiklust.

Seepärast ei ole "VPN ei muutnud minu vaikimisi marsruuti" tõend tõrkest. Kontrollige, mida see siiski lisas, ja kas kõnealune sihtkoht jääb nende prefiksite sisse:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Kaht pool-marsruuti on dumpis lihtne märkamata jätta, sest need ei näe välja nagu vaikimisi marsruut. Split-tunnel konfiguratsioon, mis unustas prefiksi lisada, tekitab täpselt selle sümptomi, mida taga ajate: rakendus, mis peaks tunnelit kasutama, lahendab ja ühendub hoopis kohapeal. Võrrelge paigaldatud prefikseid sihtkohtadega, mida kasutaja tegelikult vajab, mitte aadressidega, mida juhtusite testima. Split-tunnel nimekiri, mis katab failiserveri, kuid mitte selle lahendajat, tekitab ühenduse, mis lahendub avalikuks aadressiks ja seejärel ebaõnnestub autentimisel, mis näeb välja nagu parooliprobleem ja on marsruudiprobleem.

Väline marsruut peab samuti vastu pidama

Tunnel on ise liiklus. Kapseldatud kandevõimet kandvad paketid lähevad füüsilise liidese kaudu partneri aadressile ja seda teed ei tohi tunnelisse tagasi marsruutida. Kui see juhtub, saate iseloomuliku tõrke, kus tunnel luuakse ja seejärel lakkab liiklust läbi laskmast, sest tunneli transport on nüüd tunneli sees.

Kontrollige partneri aadressi samamoodi, nagu kontrollisite sisemist sihtkohta, ja kinnitage, et see lahendub füüsilisele liidesele, mitte tunnelile:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekursiivne marsruut, partneri püüdlev poliitikareegel või täistunneli kliendiga asendatud vaikimisi marsruut on kolm tavalist põhjust. Kõik kolm on välises otsingus nähtavad ja ükski neist ei ole nähtav pärast sündmust tehtud põhitabeli dumpis.

Mida marsruutimise väljund teile öelda ei saa

Õige otsing tähendab, et kernel saadaks paketi mõistlikku kohta. See ei tähenda, et tulemüür seda lubab, IPsec-poliitika seda katab, NAT-reegel seda tõlgib või kaugpoolel on tagasitee. Igaüks neist on hilisem etapp, ja strongSwan edastamise märkmed kirjeldavad ahelat, mille pakk peab mõlemas otsas läbima.

Samuti ei arvesta see rakendusetasandi sidumist. Protsess võib siduda end liidesega, määrata märgi või kasutada oma lahendajat ja ühenduda nimega, mis lahendub teisiti kui see, mida testisite. Kui otsing on õige ja ühendus siiski ebaõnnestub, on järgmine küsimus, milline protsess selle teeb ja kas see protsess näeb sama tabelit nagu teie.

Hoidke diagnostika järjestatud: nimetage sihtkoht ja allikas, käivitage otsing, lugege ainult seda tabelit ja reeglit, mille otsing nimetas, seejärel testige järgmist etappi. See jada hoiab marsruutimise uurimise minutites ja jätab kirje, mida teine inimene saab järgida, mida kleebitud tabel kunagi ei tee.