PPP-peeradresse kontra VPN-endepunkt: hvilken skal stå i via

Én linje på et PPP-grensesnitt avgjør det meste av rutingsdiskusjonen på en VPN-boks: den indre adressen og peeren som står ved siden av. Les paret som et lite subnett, og du vil lete etter en gateway som ikke finnes. Les det som de to endene av én enkelt lenke, og neste hopp blir åpenbart. Sammenligningen her står mellom de to lesningene, fordi hver tabell du bygger etterpå arver den du valgte. Ingenting om det ytre VPN-endepunktet avgjøres av noen av dem.

To lesninger av én grensesnittlinje

Ta en sesjon der grensesnittet rapporterer inet 10.64.3.9 peer 10.64.3.1/32. Subnettlesningen behandler 10.64.3.9 som en enslig vert på en /32-øy og leter deretter etter en ruter for å nå noe utenfor den. Siden den eneste andre adressen på linjen er peeren, ender den lesningen med å foreslå 10.64.3.9 selv som gateway, noe som er sirkelresonnement.

Endepunktlesningen er den dokumenterte. På et punkt-til-punkt-grensesnitt navngir peer den fjerne enden av den ene lenken, så 10.64.3.1 er neste hopp som kan brukes, og 10.64.3.9 er alltid bare en kildeadresse.

Den forskjellen styrer hva som kan stå i via. Skriver man den lokale adressen der, gir det en rute som kjernen ikke kan løse opp til en nabo, så oppføringen feiler i valideringen eller sluker trafikk mens den ser helt sunn ut i en liste. Peeren virker fordi den er en ekte destinasjon på lenken. Begge lesningene er enige om det ytre VPN-endepunktet, som er en helt egen identitet: det nås via underlaget, ikke via tunnelen det avslutter.

Hva sesjonen allerede har installert

Før du skriver noen egen tabell, skriv ut det som fulgte med lenken. En støttet PPP-integrasjon installerer vanligvis en enhetsrute og en peer-rute under oppsett av sesjonen, og de to oppføringene koder allerede den riktige lesningen.

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

En enhetsrute som 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 har ingen gateway fordi grensesnittet selv er veien. En rute som navngir peeren med via, er et annet objekt med en annen levetid, og den forsvinner når sesjonen faller. Å kopiere en av de to formene til en vedvarende tabell uten å kontrollere hvordan den installeres på nytt, er den vanlige grunnen til at en fungerende tunnel mister ruten etter en gjenoppkobling.

Sammenlign de to listene i stedet for å stole på hukommelsen. Hvis peer-ruten finnes i main, men den ekstra tabellen din er tom, har du lært noe adresselinjen aldri fortalte deg.

En regel og en tabell er separate beslutninger

Å velge en tabell og å fylle den er uavhengige trinn, og sammenligningen betyr noe her fordi de to ofte forveksles under feilsøking. En regel som sender merket trafikk til tabell 100, gjør ingenting hvis tabell 100 ikke har en passende rute, og en godt fylt tabell er uoppnåelig hvis ingen regel peker på den.

Halvparten av en standardrute er ikke en standardrute. En enkelt 0.0.0.0/1 dekker den nedre halvdelen av IPv4-rommet, så en policy som vil fange alt, trenger også den matchende 128.0.0.0/1, eller en ekte default. Å lese en fungerende konfigurasjon og kopiere en av de to halvdelene er hvordan folk ender med en rutingsløyfe som bare bryter på visse destinasjoner.

La bevisste unntak stå for adressene som må bli på LAN-et, og bestem hva som skjer når oppslaget ikke finner noe i den valgte tabellen. En uttrykkelig reserverute er lettere å resonnere om enn en tom tabell, som gir et uoppnåelig resultat og får applikasjonen til å se ødelagt ut snarere enn feilrutet.

Still oppslaget spørsmålet applikasjonen din stiller

ip route get løser opp en vei; ip route show viser lagrede oppføringer, og de to kan være uenige uten at noen av dem er feil. Ta med kildekonteksten, fordi kildbaserte regler bare matcher når oppslaget 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 kommandoen stiller spørsmålet fra verten. Den andre legger til et inngående grensesnitt, som er nærmere det videresendt trafikk opplever, og svaret peker ofte på en annen tabell. Ingen av destinasjonene er en livetesttjeneste; 198.51.100.23 er en dokumentasjonsadresse, så bytt den ut med en vert du har lov til å sondere.

Selv et korrekt oppslag beviser bare at en vei ble valgt. Det sier ingenting om hvorvidt den andre siden godtar trafikken, eller om svaret kan komme tilbake gjennom samme resonnement.

Der sammenligningen vipper

Vertstrafikk og videresendt trafikk tar ikke bare forskjellige oppslag; de møter forskjellige filtre på veien tilbake. Linux bruker reverse-path-validering med den strengeste av innstillingene for alle grensesnitt og for det mottakende grensesnittet, så en endring av verdien til ett grensesnitt kan ha ingen synlig effekt. Merkebasert ruting legger til relasjonen src_valid_mark, der merket må stemme for at en kilde skal regnes som gyldig.

Hvis svar forsvinner mens den utgående rutingen ser riktig ut, les de effektive verdiene før du rører dem, og endre dem bare med en oppgitt policygrunn.

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

Velg mellom de to designene på bevis: hvis applikasjonen binder til PPP-adressen, er en kilderegel pluss en tabell med peer-ruten nok. Hvis boksen videresender for et LAN bak seg, trenger du også at inngangskonteksten og returveien er enige. Når de ikke er det, retter du eierskapet til ruten i stedet for å lempe på valideringen for hele maskinen.