PPP peer adresa versus VPN endpoint: která patří do via

Porovnejte čtení PPP rozhraní jako podsítě se čtením jeho inet a peer jako dvou konců spoje a podívejte se, který další skok může tabulka zásad přijmout.

Jediný řádek na PPP rozhraní vyřeší většinu diskuse o routování na VPN krabici: vnitřní adresa a peer vytištěný vedle ní. Přečtěte ten pár jako drobnou podsíť a budete hledat bránu, která neexistuje. Přečtěte ho jako dva konce jediného spoje a další skok bude zřejmý. Srovnání je zde mezi těmito dvěma čteními, protože každá tabulka postavená potom dědí to, které jste zvolili. Nic o vnějším VPN endpointu nerozhoduje ani jedno z nich.

Dvě čtení jednoho řádku rozhraní

Vezměte relaci, ve které rozhraní hlásí inet 10.64.3.9 peer 10.64.3.1/32. Čtení jako podsíť považuje 10.64.3.9 za osamělého hosta na /32 ostrově a pak hledá router, aby dosáhlo čehokoli za ním. Protože jedinou další adresou na spoji je peer, toto čtení nakonec navrhne 10.64.3.9 jako bránu, což je kruhové.

Čtení jako endpoint je to dokumentované. Na point-to-point rozhraní peer pojmenovává vzdálený konec toho jediného spoje, takže 10.64.3.1 je použitelný další skok a 10.64.3.9 je vždy jen zdrojová adresa.

Tento rozdíl určuje, co se smí objevit v via. Zapsání lokální adresy tam vytvoří trasu, kterou jádro nedokáže přeložit na souseda, takže záznam buď neprojde validací, nebo spolkne provoz, zatímco ve výpisu vypadá naprosto zdravě. Peer funguje, protože je skutečným cílem na spoji. Obě čtení se shodují na vnějším VPN endpointu, který je zcela samostatná identita: dosahuje se ho přes underlay, ne přes tunel, který ukončuje.

Co relace už nainstalovala

Než napíšete jakoukoli vlastní tabulku, vypište, co přišlo se spojem. Podporovaná integrace PPP obvykle při nastavení relace instaluje trasu zařízení a trasu peeru, a tyto dva záznamy už kódují správné čtení.

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

Trasa zařízení jako 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 nenese bránu, protože rozhraní samo je cestou. Trasa, která pojmenovává peer pomocí via, je jiný objekt s jinou životností, a mizí, když relace spadne. Kopírování kteréhokoli z těchto dvou tvarů do trvalé tabulky bez kontroly, jak se znovu instaluje, je obvyklý důvod, proč funkční tunel po opětovném připojení ztratí svou trasu.

Porovnejte oba výpisy, místo abyste věřili paměti. Pokud trasa peeru existuje v main, ale vaše doplňková tabulka je prázdná, naučili jste se něco, co vám řádek adresy nikdy neřekl.

Pravidlo a tabulka jsou oddělená rozhodnutí

Vybrat tabulku a naplnit ji jsou nezávislé kroky a srovnání je tu důležité, protože se obojí při ladění často plete. Pravidlo, které posílá označený provoz do tabulky 100, neudělá nic, pokud tabulka 100 nemá odpovídající trasu, a dobře naplněná tabulka je nedosažitelná, pokud na ni žádné pravidlo neukazuje.

Polovina výchozí trasy není výchozí trasa. Jediná 0.0.0.0/1 pokrývá spodní polovinu prostoru IPv4, takže zásada, která chce zachytit vše, potřebuje i odpovídající 128.0.0.0/1, nebo skutečnou default. Přečíst funkční konfiguraci a zkopírovat jednu ze dvou polovin je způsob, jak lidé skončí se smyčkou routování, která se láme jen na určitých cílech.

Nechte záměrné výjimky pro adresy, které musí zůstat na LAN, a rozhodněte, co se stane, když hledání ve zvolené tabulce nic nenajde. Výslovná záložní trasa se snáze promýšlí než prázdná tabulka, která vrací nedosažitelný výsledek a dělá aplikaci spíš rozbitou než špatně routovanou.

Položte hledání otázku, kterou klade vaše aplikace

ip route get řeší cestu; ip route show vypisuje uložené záznamy a oba se mohou rozejít, aniž by jeden byl špatný. Zahrňte kontext zdroje, protože pravidla založená na zdroji odpovídají jen tehdy, když hledání nese 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

První příkaz klade otázku z hostitele. Druhý přidává vstupní rozhraní, což je blíž tomu, co zažívá předávaný provoz, a odpověď často ukazuje na jinou tabulku. Žádný z cílů není živá testovací služba; 198.51.100.23 je dokumentační adresa, tak ji nahraďte hostitelem, který smíte sondovat.

I správné hledání dokazuje jen to, že byla zvolena cesta. Neříká nic o tom, zda druhá strana provoz přijímá nebo zda se odpověď může vrátit stejným uvažováním.

Kde se srovnání obrací

Provoz hostitele a předávaný provoz nevolí jen různé vyhledávání; na cestě zpět potkávají různé filtry. Linux uplatňuje validaci obrácené cesty podle přísnějšího z nastavení pro všechna rozhraní a pro přijímající rozhraní, takže změna hodnoty jednoho rozhraní nemusí mít viditelný účinek. Routování založené na značce přidává vztah src_valid_mark, kde se značka musí shodovat, aby byl zdroj považován za platný.

Pokud odpovědi mizí, zatímco odchozí routování vypadá správně, přečtěte efektivní hodnoty, než se jich dotknete, a měňte je jen s uvedeným důvodem zásady.

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

Mezi oběma návrhy vybírejte na základě důkazů: pokud se aplikace váže k PPP adrese, stačí pravidlo zdroje plus tabulka držící trasu peeru. Pokud krabice předává provoz pro LAN za sebou, potřebujete také, aby se vstupní kontext a zpětná cesta shodovaly. Když se neshodují, opravte vlastnictví trasy, místo abyste uvolnili validaci pro celý stroj.

Související články