PPP peer adresa verzus VPN endpoint: ktorá patrí do via

Jediný riadok na PPP rozhraní vyrieši väčšinu diskusie o routovaní na VPN krabici: vnútorná adresa a peer vytlačený vedľa nej. Prečítajte ten pár ako drobnú podsiet a budete hľadať bránu, ktorá neexistuje. Prečítajte ho ako dva konce jediného spoja a ďalší skok bude zrejmý. Porovnanie je tu medzi týmito dvoma čítaniami, pretože každá tabuľka postavená potom dedí to, ktoré ste zvolili. Nič o vonkajšom VPN endpointe nerozhoduje ani jedno z nich.

Dve čítania jedného riadku rozhrania

Vezmite reláciu, v ktorej rozhranie hlási inet 10.64.3.9 peer 10.64.3.1/32. Čítanie ako podsiet považuje 10.64.3.9 za osamelého hosta na /32 ostrove a potom hľadá router, aby dosiahlo čokoľvek za ním. Keďže jedinou ďalšou adresou na spoji je peer, toto čítanie napokon navrhne 10.64.3.9 ako bránu, čo je kruhové.

Čítanie ako endpoint je to dokumentované. Na point-to-point rozhraní peer pomenúva vzdialený koniec toho jediného spoja, takže 10.64.3.1 je použiteľný ďalší skok a 10.64.3.9 je vždy len zdrojová adresa.

Tento rozdiel určuje, čo sa smie objaviť v via. Zápis lokálnej adresy tam vytvorí trasu, ktorú jadro nedokáže preložiť na suseda, takže záznam buď neprejde validáciou, alebo pohltí prevádzku, zatiaľ čo vo výpise vyzerá úplne zdravo. Peer funguje, pretože je skutočným cieľom na spoji. Obe čítania sa zhodujú na vonkajšom VPN endpointe, ktorý je úplne samostatná identita: dosahuje sa cez underlay, nie cez tunel, ktorý ukončuje.

Čo relácia už nainštalovala

Skôr než napíšete akúkoľvek vlastnú tabuľku, vypíšte, čo prišlo so spojom. Podporovaná integrácia PPP zvyčajne pri nastavení relácie nainštaluje trasu zariadenia a trasu peeru, a tieto dva záznamy už kódujú správne čítanie.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Trasa zariadenia ako 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 nenesie bránu, pretože rozhranie samo je cestou. Trasa, ktorá pomenúva peer pomocou via, je iný objekt s inou životnosťou, a mizne, keď relácia spadne. Kopírovanie ktoréhokoľvek z týchto dvoch tvarov do trvalej tabuľky bez kontroly, ako sa znovu inštaluje, je obvyklý dôvod, prečo funkčný tunel po opätovnom pripojení stratí svoju trasu.

Porovnajte oba výpisy namiesto toho, aby ste verili pamäti. Ak trasa peeru existuje v main, ale vaša doplnková tabuľka je prázdna, naučili ste sa niečo, čo vám riadok adresy nikdy nepovedal.

Pravidlo a tabuľka sú oddelené rozhodnutia

Vybrať tabuľku a naplniť ju sú nezávislé kroky a porovnanie je tu dôležité, pretože sa oboje pri ladení často zamieňa. Pravidlo, ktoré posiela označenú prevádzku do tabuľky 100, neurobí nič, ak tabuľka 100 nemá zodpovedajúcu trasu, a dobre naplnená tabuľka je nedosiahnuteľná, ak na ňu neukazuje žiadne pravidlo.

Polovica predvolenej trasy nie je predvolená trasa. Jediná 0.0.0.0/1 pokrýva spodnú polovicu priestoru IPv4, takže zásada, ktorá chce zachytiť všetko, potrebuje aj zodpovedajúcu 128.0.0.0/1, alebo skutočnú default. Prečítať funkčnú konfiguráciu a skopírovať jednu z dvoch polovíc je spôsob, akým ľudia skončia so slučkou routovania, ktorá sa láme len na určitých cieľoch.

Nechajte zámerné výnimky pre adresy, ktoré musia zostať na LAN, a rozhodnite, čo sa stane, keď hľadanie v zvolenej tabuľke nič nenájde. Výslovná záložná trasa sa ľahšie premýšľa než prázdna tabuľka, ktorá vracia nedosiahnuteľný výsledok a robí aplikáciu skôr pokazenou než zle routovanou.

Položte hľadaniu otázku, ktorú kladie vaša aplikácia

ip route get rieši cestu; ip route show vypisuje uložené záznamy a obe sa môžu rozísť, bez toho aby jedno bolo nesprávne. Zahrňte kontext zdroja, pretože pravidlá založené na zdroji zodpovedajú len vtedy, keď hľadanie nesie zdroj.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Prvý príkaz kladie otázku z hostiteľa. Druhý pridáva vstupné rozhranie, čo je bližšie tomu, čo zažíva preposielaná prevádzka, a odpoveď často ukazuje na inú tabuľku. Žiadny z cieľov nie je živá testovacia služba; 198.51.100.23 je dokumentačná adresa, tak ju nahraďte hostiteľom, ktorý smiete sondovať.

Aj správne hľadanie dokazuje len to, že bola zvolená cesta. Nehovorí nič o tom, či druhá strana prevádzku prijíma alebo či sa odpoveď môže vrátiť tým istým uvažovaním.

Kde sa porovnanie obracia

Prevádzka hostiteľa a preposielaná prevádzka nevolia len rôzne vyhľadávania; na ceste späť stretávajú rôzne filtre. Linux uplatňuje validáciu obrátenej cesty podľa prísnejšieho z nastavení pre všetky rozhrania a pre prijímajúce rozhranie, takže zmena hodnoty jedného rozhrania nemusí mať viditeľný účinok. Routovanie založené na značke pridáva vzťah src_valid_mark, kde sa značka musí zhodovať, aby bol zdroj považovaný za platný.

Ak odpovede miznú, zatiaľ čo odchádzajúce routovanie vyzerá správne, prečítajte efektívne hodnoty, než sa ich dotknete, a meňte ich len s uvedeným dôvodom zásady.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Medzi oboma návrhmi vyberajte na základe dôkazov: ak sa aplikácia viaže na PPP adresu, stačí pravidlo zdroja plus tabuľka držiaca trasu peeru. Ak krabica preposiela prevádzku pre LAN za sebou, potrebujete aj to, aby sa vstupný kontext a spätná cesta zhodovali. Keď sa nezhodujú, opravte vlastníctvo trasy, namiesto toho aby ste uvoľnili validáciu pre celý stroj.