Usmerjevalna tabela proti dejanskemu iskanju: kam gre promet VPN

Izpis usmerjevalne tabele je najmanj uporabna diagnostika pri odpravljanju težav z VPN in najpogosteje prilepljena. Štirideset vrstic predpon vam pove, kaj bi stroj lahko naredil, ne pa, kaj je naredil za neuspešno zahtevo. Mehanizem, ki ga resnično želite, je iskanje: glede na ta vir in ta cilj, katero pravilo se je ujemalo, katera tabela je bila obravnavana in kateri vmesnik ter naslednji skok sta prišla ven. Začnite z enim ciljem in enim virom, nato berite tabelo s tem vprašanjem v roki, in enak izhod postane dokaz namesto šuma.

Tabela je niz kandidatov, ne odločitev

Vsak vnos opisuje predpono in kaj storiti s prometom, ki se z njo ujema: poslati ga na vmesnik, predati naslednjemu skoku ali ga zavreči. Nič na tem seznamu ni urejeno po namenu, in vnos, ki se človeku zdi najbolj specifičen, ni vedno tisti, ki ga izbere jedro, ker izbira sledi najdaljšemu ujemanju predpone, med enakimi predponami pa metriki.

Zato je prvi korak vprašati jedro, namesto brati seznam. Ukaz za iskanje odgovori za cilj, z argumentom vira pa odgovori za točen par, ki bi ga uporabila posredovana ali vezana povezava:

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

Vsak naslov zgoraj je dokumentacijski primer. Bistvo je oblika odgovora: vmesnik, izbrani naslov vira, prehod in tabela, iz katere je prišel vnos. Če se ta izhod ne ujema z vmesnikom, ki ste ga pričakovali, ste težavo lokalizirali z enim ukazom, in nobeno branje celotne tabele vam ne bi povedalo, kateri kandidat je zmagal.

Iskanje gre najprej skozi pravila, nato skozi tabele

V Linuxu je odločitev v dveh stopnjah. Pravila politike se ocenjujejo po vrstnem redu prednosti, in prvo pravilo, ki se ujema, imenuje tabelo za posvetovanje; ta tabela nato izvede ujemanje najdaljše predpone. Pravilo se lahko ujema po viru, cilju, oznaki požarnega zidu, vmesniku ali kombinaciji, zato je lahko izpis glavne tabele povsem natančen in povsem nepomemben za paket, ki ga preiskujete.

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

Če pravilo pošilja promet iz vašega bazena VPN v tabelo 100, je pomembna tabela 100, in glavna tabela je vaba. To je tudi mehanizem usmerjanja na podlagi vira na usmerjevalniku: isti cilj ima lahko dva različna odgovora glede na to, od kod je prišel paket, in samo iskanje z argumentom vira razkrije, kateri velja.

IPv6 ima svoja pravila in tabele. Zasnova, ki poganja obe družini, potrebuje obe iskanji, in delujoč odgovor IPv4 ne pove ničesar o poti v6, ki bi jo lahko imel raje dvojno skladovni odjemalec.

Kaj namesti odjemalec VPN

Odjemalci običajno ne nadomestijo privzete poti, ker bi to prelomilo lastno zunanjo pot tunela. Namestijo nekaj bolj specifičnega, kar zmaga po dolžini predpone: par pol-privzetih poti, ki pokrivata 0.0.0.0/1 in 128.0.0.0/1, je klasičen trik, saj sta obe daljši predponi od 0.0.0.0/0 in skupaj pokrivata ves prostor. Drugi namestijo določene zasebne predpone plus pravilo politike, nekateri pa dodajo oznako, da se ujame samo izbrani promet.

Zato "VPN mi ni spremenil privzete poti" ni dokaz okvare. Preverite, kaj je dejansko dodal, in ali zadevni cilj pade znotraj teh predpon:

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

Dve pol-poti se v izpisu zlahka spregledata, ker nista videti kot privzeta pot. Konfiguracija deljenega tunela, ki je pozabila vključiti predpono, ustvari natanko tisti simptom, ki ga lovite: aplikacija, ki bi morala uporabljati tunel, namesto tega razreši in se poveže lokalno. Primerjajte nameščene predpone s cilji, ki jih uporabnik resnično potrebuje, ne z naslovi, ki ste jih slučajno preizkusili. Seznam deljenega tunela, ki pokriva strežnik datotek, ne pa njegovega razreševalnika, ustvari povezavo, ki se razreši na javni naslov in nato ne opravi preverjanja pristnosti, kar je videti kot težava z geslom in je težava s potjo.

Tudi zunanja pot mora preživeti

Tunel je sam promet. Paketi, ki prenašajo zapakiran tovor, gredo na naslov partnerja skozi fizični vmesnik, in ta pot ne sme biti usmerjena nazaj v tunel. Ko je, dobite značilno okvaro, pri kateri se tunel vzpostavi in nato preneha prepuščati promet, ker je transport za tunel zdaj znotraj tunela.

Preverite naslov partnerja tako, kot ste preverili notranji cilj, in potrdite, da se razreši na fizični vmesnik in ne na tunel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekurzivna pot, pravilo politike, ki ujame partnerja, ali privzeta pot, ki jo je nadomestil odjemalec polnega tunela, so trije običajni vzroki. Vsi trije so vidni v zunanjem iskanju, in noben ni viden v izpisu glavne tabele, vzetem po dejstvu.

Česa vam izhod usmerjanja ne more povedati

Pravilno iskanje pomeni, da bi jedro poslalo paket na smiselno mesto. To ne pomeni, da ga požarni zid dovoli, da ga politika IPsec pokriva, da ga pravilo NAT prevede ali da ima oddaljena stran povratno pot. Vsak od teh je poznejša stopnja, in opombe strongSwan o posredovanju opisujejo verigo, skozi katero mora paket iti na obeh koncih.

Ne upošteva niti vezave na ravni aplikacije. Proces se lahko veže na vmesnik, nastavi oznako ali uporabi svoj razreševalnik in se poveže z imenom, ki se razreši drugače od tega, kar ste preizkusili. Ko je iskanje pravilno in povezava še vedno ne uspe, je naslednje vprašanje, kateri proces jo ustvarja in ali ta proces vidi isto tabelo kot vi.

Zato ohranjajte diagnostiko urejeno: poimenujte cilj in vir, zaženite iskanje, berite samo tabelo in pravilo, ki ju je iskanje poimenovalo, nato preizkusite naslednjo stopnjo. To zaporedje ohrani preiskavo usmerjanja v minutah in pusti zapis, ki mu lahko kdo drug sledi, česar prilepljena tabela nikoli ne stori.