PPP-peeradresse kontra VPN-endepunkt: hvad hører i via

Én linje på et PPP-interface afgør det meste af routingdiskussionen på en VPN-boks: den indre adresse og den peer, der står ved siden af. Læs parret som et lille subnet, og du vil lede efter en gateway, der ikke findes. Læs det som de to ender af ét enkelt link, og det næste hop bliver indlysende. Sammenligningen her står mellem de to læsninger, fordi hver tabel, du bygger bagefter, arver den, du valgte. Intet om det ydre VPN-endepunkt afgøres af nogen af dem.

To læsninger af én interfacelinje

Tag en session, hvor interfacet rapporterer inet 10.64.3.9 peer 10.64.3.1/32. Subnetlæsningen behandler 10.64.3.9 som en enlig vært på en /32-ø og leder derefter efter en router for at nå noget uden for den. Da den eneste anden adresse på linjen er peeren, ender den læsning med at foreslå 10.64.3.9 selv som gateway, hvilket er cirkulært.

Endepunktlæsningen er den dokumenterede. På et punkt-til-punkt-interface navngiver peer den fjerne ende af det ene link, så 10.64.3.1 er det brugbare næste hop, og 10.64.3.9 er altid kun en kildeadresse.

Den forskel styrer, hvad der må stå i via. Skriver man den lokale adresse der, giver det en rute, som kernen ikke kan opløse til en nabo, så posten fejler i valideringen eller sluger trafik, mens den ser helt sund ud i en liste. Peeren virker, fordi den er en rigtig destination på linket. Begge læsninger er enige om det ydre VPN-endepunkt, som er en helt separat identitet: det nås via underlaget, ikke via den tunnel, det afslutter.

Hvad sessionen allerede har installeret

Før du skriver nogen tabel selv, skal du udskrive det, der kom med linket. En understøttet PPP-integration installerer normalt en enhedsrute og en peer-rute under opsætningen af sessionen, og de to poster koder allerede den korrekte læsning.

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

En enhedsrute som 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 bærer ingen gateway, fordi interfacet selv er vejen. En rute, der navngiver peeren med via, er et andet objekt med en anden levetid, og den forsvinder, når sessionen falder. At kopiere en af de to former til en vedvarende tabel uden at kontrollere, hvordan den geninstalleres, er den sædvanlige grund til, at en fungerende tunnel mister sin rute efter en genopkobling.

Sammenlign de to lister i stedet for at stole på hukommelsen. Hvis peer-ruten findes i main, men din ekstra tabel er tom, har du lært noget, som adresselinjen aldrig fortalte dig.

En regel og en tabel er separate beslutninger

At vælge en tabel og at fylde den er uafhængige trin, og sammenligningen betyder noget her, fordi de to ofte forveksles under fejlfinding. En regel, der sender markeret trafik til tabel 100, gør intet, hvis tabel 100 ikke har en passende rute, og en velfyldt tabel er uopnåelig, hvis ingen regel peger på den.

Halvdelen af en standardrute er ikke en standardrute. En enkelt 0.0.0.0/1 dækker den nederste halvdel af IPv4-rummet, så en politik, der vil fange alt, også har brug for den matchende 128.0.0.0/1 eller en ægte default. At læse en fungerende konfiguration og kopiere en af de to halvdele er, hvordan folk ender med en routingløkke, der kun bryder på visse destinationer.

Lad bevidste undtagelser stå for de adresser, der skal blive på LAN'et, og beslut, hvad der sker, når opslaget ikke finder noget i den valgte tabel. En udtrykkelig fallbackrute er lettere at ræsonnere om end en tom tabel, som giver et uopnåeligt resultat og får applikationen til at se i stykker ud snarere end fejlrouet.

Stil opslaget det spørgsmål, din applikation stiller

ip route get opløser en vej; ip route show viser lagrede poster, og de to kan være uenige, uden at nogen af dem er forkert. Tag kildekonteksten med, fordi kildbaserede regler kun matcher, når opslaget bærer en kilde.

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

Den første kommando stiller spørgsmålet fra værten. Den anden tilføjer et indgående interface, hvilket er tættere på det, videresendt trafik oplever, og svaret peger ofte på en anden tabel. Ingen af destinationerne er en livetesttjeneste; 198.51.100.23 er en dokumentationsadresse, så erstat den med en vært, du må sondere.

Selv et korrekt opslag beviser kun, at en vej blev valgt. Det siger intet om, hvorvidt den anden side accepterer trafikken, eller om svaret kan vende tilbage gennem samme ræsonnement.

Hvor sammenligningen tipper

Værttrafik og videresendt trafik tager ikke bare forskellige opslag; de møder forskellige filtre på vejen tilbage. Linux anvender reverse-path-validering med den strengeste af indstillingerne for alle interfaces og for det modtagende interface, så en ændring af ét interfaces værdi måske ingen synlig effekt har. Mærkebaseret routing tilføjer relationen src_valid_mark, hvor mærket skal stemme, for at en kilde anses for gyldig.

Hvis svar forsvinder, mens den udgående routing ser rigtig ud, skal du læse de effektive værdier, før du rører dem, og kun ændre dem med en angivet politikbegrundelse.

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

Vælg mellem de to design på bevis: hvis applikationen binder til PPP-adressen, er en kilderegel plus en tabel med peer-ruten nok. Hvis boksen videresender for et LAN bagved, skal du også have, at indgangskonteksten og returvejen er enige. Når de ikke er det, skal du rette ejerskabet af ruten i stedet for at lempe valideringen for hele maskinen.