PPP-peeradress eller VPN-slutpunkt: vilket ska stå i via

En rad på ett PPP-gränssnitt avgör det mesta av routingdiskussionen på en VPN-burk: den inre adressen och peeren som trycks bredvid den. Läs paret som ett litet subnät och du kommer att leta efter en gateway som inte finns. Läs det som de två ändarna av en enda länk och nästa hopp blir självklart. Jämförelsen här står mellan de två läsningarna, eftersom varje tabell du bygger efteråt ärver den du valde. Inget om det yttre VPN-slutpunkten avgörs av någon av dem.

Två läsningar av en gränssnittsrad

Ta en session där gränssnittet rapporterar inet 10.64.3.9 peer 10.64.3.1/32. Subnätsläsningen behandlar 10.64.3.9 som en ensam värd på en /32-ö och letar sedan efter en router för att nå något bortom den. Eftersom den enda andra adressen på länken är peeren, slutar den läsningen med att föreslå 10.64.3.9 själv som gateway, vilket är cirkelresonemang.

Slutpunktsläsningen är den dokumenterade. På ett punkt-till-punkt-gränssnitt namnger peer den bortre änden av den enda länken, så 10.64.3.1 är det användbara nästa hoppet och 10.64.3.9 är alltid bara en källadress.

Den skillnaden styr vad som får stå i via. Att skriva den lokala adressen där ger en rutt som kärnan inte kan matcha mot en granne, så posten misslyckas i valideringen eller sväljer trafik medan den ser helt frisk ut i en lista. Peeren fungerar eftersom den är en verklig destination på länken. Båda läsningarna är överens om det yttre VPN-slutpunkten, som är en helt separat identitet: den nås via underlagret, inte via tunneln den avslutar.

Vad sessionen redan har installerat

Innan du skriver någon egen tabell, skriv ut vad som följde med länken. En PPP-integration som stöds installerar vanligtvis en enhetsrutt och en peer-rutt när sessionen sätts upp, och de två posterna kodar redan den korrekta läsningen.

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

En enhetsrutt som 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 bär ingen gateway eftersom gränssnittet självt är vägen. En rutt som namnger peeren med via är ett annat objekt med en annan livstid, och den försvinner när sessionen faller. Att kopiera endera formen till en beständig tabell utan att kontrollera hur den installeras om är det vanliga skälet till att en fungerande tunnel tappar sin rutt efter en återanslutning.

Jämför de två listorna i stället för att lita på minnet. Om peer-rutten finns i main men din extra tabell är tom, har du lärt dig något som adressraden aldrig berättade.

En regel och en tabell är separata beslut

Att välja en tabell och att fylla den är oberoende steg, och jämförelsen spelar roll här eftersom de två ofta blandas ihop vid felsökning. En regel som skickar märkt trafik till tabell 100 gör ingenting om tabell 100 saknar en matchande rutt, och en välfylld tabell är oåtkomlig om ingen regel pekar på den.

Halva en standardrutt är inte en standardrutt. En enda 0.0.0.0/1 täcker den undre halvan av IPv4-rymden, så en policy som vill fånga allt behöver även den matchande 128.0.0.0/1, eller en äkta default. Att läsa en fungerande konfiguration och kopiera en av de två halvorna är hur folk hamnar i en routingloop som bara bryts för vissa destinationer.

Lämna medvetna undantag för de adresser som måste stanna på LAN-et, och bestäm vad som händer när sökningen inte hittar något i den valda tabellen. En uttrycklig reservrutt är lättare att resonera om än en tom tabell, som ger ett oåtkomligt resultat och får applikationen att se trasig ut snarare än felrutad.

Ställ sökningen den fråga din applikation ställer

ip route get löser upp en väg; ip route show listar lagrade poster, och de två kan vara oense utan att någon är fel. Ta med källkontexten, eftersom källbaserade regler bara matchar när sökningen bär en källa.

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

Det första kommandot ställer frågan från värden. Det andra lägger till ett inkommande gränssnitt, vilket ligger närmare det vidarebefordrad trafik upplever, och svaret pekar ofta på en annan tabell. Ingen av destinationerna är en livetesttjänst; 198.51.100.23 är en dokumentationsadress, så byt ut den mot en värd du får sondera.

Även en korrekt sökning bevisar bara att en väg valdes. Den säger inget om huruvida andra sidan accepterar trafiken eller om svaret kan komma tillbaka genom samma resonemang.

Där jämförelsen tippar

Värdtrafik och vidarebefordrad trafik tar inte bara olika sökningar; de möter olika filter på vägen tillbaka. Linux tillämpar reverse-path-validering med den strängare av inställningarna för alla gränssnitt och för det mottagande gränssnittet, så en ändring av ett gränssnitts värde kan sakna synlig effekt. Märkbaserad routing lägger till relationen src_valid_mark, där märket måste stämma för att en källa ska anses giltig.

Om svar försvinner medan den utgående routingen ser rätt ut, läs de effektiva värdena innan du rör dem, och ändra dem bara med ett angivet policy-skäl.

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

Välj mellan de två designerna på bevis: om applikationen binder till PPP-adressen räcker en källregel plus en tabell som håller peer-rutten. Om burken vidarebefordrar för ett LAN bakom sig behöver du också att ingångskontexten och returvägen är överens. När de inte är det, rätta ägandet av rutten i stället för att lätta på valideringen för hela maskinen.