Maršrutizavimo lentelė prieš tikrąją paiešką: kur keliauja VPN srautas

Maršrutizavimo lentelės išmetimas yra mažiausiai naudinga VPN trikčių diagnostika ir dažniausiai įklijuojama. Keturiasdešimt eilučių prefiksų pasako, ką mašina galėtų daryti, o ne ką ji padarė nepavykusiai užklausai. Mechanizmas, kurio iš tikrųjų norite, yra paieška: esant šiam šaltiniui ir šiam tikslui, kuri taisyklė atitiko, kuri lentelė buvo konsultuota ir kuri sąsaja bei kitas šuolis išėjo. Pradėkite nuo vieno tikslo ir vieno šaltinio, tada skaitykite lentelę su šiuo klausimu rankoje, ir ta pati išvestis tampa įrodymu vietoj triukšmo.

Lentelė yra kandidatų rinkinys, o ne sprendimas

Kiekvienas įrašas aprašo prefiksą ir ką daryti su jį atitinkančiu srautu: siųsti į sąsają, perduoti kitam šuoliui arba atmesti. Niekas tame sąraše nėra išdėstyta pagal ketinimą, o įrašas, kuris žmogui atrodo konkretiausias, ne visada yra tas, kurį pasirenka branduolys, nes pasirinkimas vadovaujasi ilgiausiu prefikso atitikimu, o tarp vienodų prefiksų – metrika.

Taigi pirmas žingsnis yra klausti branduolio, o ne skaityti sąrašą. Paieškos komanda atsako tikslui, o su šaltinio argumentu – tiksliai porai, kurią naudotų persiųstas ar susietas ryšys:

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

Kiekvienas aukščiau esantis adresas yra dokumentacijos pavyzdys. Esmė yra atsakymo forma: sąsaja, pasirinktas šaltinio adresas, šliuzas ir lentelė, iš kurios atėjo įrašas. Jei ši išvestis neatitinka tikėtos sąsajos, viena komanda lokalizavote problemą, ir joks visos lentelės skaitymas nebūtų pasakęs, kuris kandidatas laimėjo.

Paieška eina per taisykles, tada per lenteles

Linux sistemoje sprendimas vyksta dviem etapais. Politikos taisyklės vertinamos prioriteto tvarka, o pirmoji atitikusi taisyklė nurodo konsultuotiną lentelę; ta lentelė tada atlieka ilgiausio prefikso atitikimą. Taisyklė gali atitikti pagal šaltinį, tikslą, ugniasienės žymą, sąsają ar jų derinį, todėl pagrindinės lentelės išmetimas gali būti visiškai tikslus ir visiškai nesusijęs su tiriamu paketu.

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

Jei taisyklė siunčia srautą iš jūsų VPN telkinio į 100 lentelę, tuomet svarbi yra 100 lentelė, ir pagrindinė lentelė yra masalas. Tai taip pat yra šaltiniu pagrįsto maršrutizavimo mechanizmas maršrutizatoriuje: tas pats tikslas gali turėti du skirtingus atsakymus priklausomai nuo to, iš kur atėjo paketas, ir tik paieška su šaltinio argumentu atskleidžia, kuris galioja.

IPv6 turi savo taisykles ir lenteles. Dizainas, kuriame veikia abi šeimos, turi atlikti abi paieškas, o veikiantis IPv4 atsakymas nieko nesako apie v6 kelią, kurį dvigubo kamino klientas gali teikti pirmenybę.

Ką įdiegia VPN klientas

Klientai paprastai nepakeičia numatytojo maršruto, nes tai sulaužytų patį tunelio išorinį kelią. Jie įdiegia ką nors konkretesnio, kas laimi pagal prefikso ilgį: pora pusiau numatytųjų maršrutų, apimančių 0.0.0.0/1 ir 128.0.0.0/1, yra klasikinis triukas, nes abu yra ilgesni prefiksai nei 0.0.0.0/0 ir kartu apima visą erdvę. Kiti įdiegia konkrečius privačius prefiksus ir politikos taisyklę, o kai kurie prideda žymą, kad būtų užfiksuotas tik pasirinktas srautas.

Štai kodėl "VPN nepakeitė mano numatytojo maršruto" nėra gedimo įrodymas. Patikrinkite, ką jis vis dėlto pridėjo, ir ar aptariamas tikslas patenka į tuos prefiksus:

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

Du pusiau maršrutus lengva praleisti išmetime, nes jie neatrodo kaip numatytasis. Split-tunnel konfigūracija, pamiršusi įtraukti prefiksą, sukuria būtent tą simptomą, kurio ieškote: programa, kuri turėtų naudoti tunelį, vietoj to išsprendžia ir prisijungia lokaliai. Palyginkite įdiegtus prefiksus su tikslais, kurių vartotojui iš tikrųjų reikia, o ne su adresais, kuriuos atsitiktinai išbandėte. Split-tunnel sąrašas, apimantis failų serverį, bet ne jo sprendiklį, sukuria ryšį, kuris išsprendžiamas į viešą adresą ir tada nepraeina autentifikacijos, o tai atrodo kaip slaptažodžio problema ir yra maršruto problema.

Išorinis maršrutas taip pat turi išlikti

Tunelis pats yra srautas. Paketai, nešantys inkapsuliuotą naudingąją apkrovą, keliauja į partnerio adresą per fizinę sąsają, ir tas kelias neturi būti maršrutizuojamas atgal į tunelį. Kai taip atsitinka, gaunamas būdingas gedimas, kai tunelis užmezgamas ir tada nustoja praleisti srautą, nes tunelio transportas dabar yra tunelio viduje.

Patikrinkite partnerio adresą taip, kaip tikrinote vidinį tikslą, ir patvirtinkite, kad jis išsprendžiamas į fizinę sąsają, o ne į tunelį:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekursyvus maršrutas, politikos taisyklė, sugaunanti partnerį, arba numatytasis maršrutas, pakeistas viso tunelio klientu, yra trys įprastos priežastys. Visos trys matomos išorinėje paieškoje, ir nė viena nematoma pagrindinės lentelės išmetime, padarytame po fakto.

Ko maršrutizavimo išvestis negali pasakyti

Teisinga paieška reiškia, kad branduolys siųstų paketą į prasmingą vietą. Tai nereiškia, kad ugniasienė jį leidžia, IPsec politika jį apima, NAT taisyklė jį verčia, arba nuotolinė pusė turi grįžimo maršrutą. Kiekviena iš jų yra vėlesnis etapas, ir strongSwan persiuntimo pastabos aprašo grandinę, kurią paketas turi praeiti abiejuose galuose.

Jis taip pat neatsižvelgia į susiejimą programos lygiu. Procesas gali susieti su sąsaja, nustatyti žymą arba naudoti savo sprendiklį ir prisijungti vardu, kuris išsprendžiamas kitaip nei išbandėte. Kai paieška teisinga, o ryšys vis tiek nepavyksta, kitas klausimas – kuris procesas jį atlieka ir ar tas procesas mato tą pačią lentelę kaip jūs.

Todėl laikykite diagnostiką tvarkingą: įvardykite tikslą ir šaltinį, paleiskite paiešką, skaitykite tik tą lentelę ir taisyklę, kurią pavadino paieška, tada išbandykite kitą etapą. Ši seka išlaiko maršrutizavimo tyrimą kelių minučių ribose ir palieka įrašą, kurį kitas gali atsekti, ko įklijuota lentelė niekada nepadaro.