PPP-peeradresse kontra VPN-endepunkt: kva som høyrer i via

Éi linje på eit PPP-grensesnitt avgjer det meste av rutingsdiskusjonen på ein VPN-boks: den indre adressa og peeren som står ved sida av. Les paret som eit lite subnett, og du vil leite etter ein gateway som ikkje finst. Les det som dei to endane av éi enkelt lenkje, og neste hopp blir openbert. Samanlikninga her står mellom dei to lesingane, fordi kvar tabell du byggjer etterpå arvar den du valde. Ingenting om det ytre VPN-endepunktet blir avgjort av nokon av dei.

To lesingar av éi grensesnittlinje

Ta ein sesjon der grensesnittet rapporterer inet 10.64.3.9 peer 10.64.3.1/32. Subnettlesinga behandlar 10.64.3.9 som ein einsleg vert på ei /32-øy og leitar deretter etter ein ruter for å nå noko utanfor henne. Sidan den einaste andre adressa på linja er peeren, endar den lesinga med å føreslå 10.64.3.9 sjølv som gateway, noko som er sirkelresonnement.

Endepunktlesinga er den dokumenterte. På eit punkt-til-punkt-grensesnitt namngir peer den fjerne enden av den eine lenkja, så 10.64.3.1 er neste hopp som kan brukast, og 10.64.3.9 er alltid berre ei kjeldeadresse.

Den skilnaden styrer kva som kan stå i via. Skriv ein den lokale adressa der, gir det ei rute som kjernen ikkje kan løyse opp til ein nabo, så oppføringa feilar i valideringa eller slukar trafikk medan ho ser heilt sunn ut i ei liste. Peeren verkar fordi han er ein ekte destinasjon på lenkja. Begge lesingane er samde om det ytre VPN-endepunktet, som er ein heilt eigen identitet: det blir nådd via underlaget, ikkje via tunnelen det avsluttar.

Kva sesjonen allereie har installert

Før du skriv nokon eigen tabell, skriv ut det som følgde med lenkja. Ein støtta PPP-integrasjon installerar vanlegvis ei einingrute og ei peer-rute under oppsett av sesjonen, og dei to oppføringane kodar allereie den riktige lesinga.

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

Ei einingrute som 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 har ingen gateway fordi grensesnittet sjølv er vegen. Ei rute som namngir peeren med via, er eit anna objekt med ei anna levetid, og ho forsvinn når sesjonen fell. Å kopiere ein av dei to formene til ein varig tabell utan å kontrollere korleis han blir installert på nytt, er den vanlege grunnen til at ein fungerande tunnel mistar ruta etter ei attoppkopling.

Samanlikn dei to listene i staden for å stole på minnet. Viss peer-ruta finst i main, men den ekstra tabellen din er tom, har du lært noko adresselinja aldri fortalde deg.

Ein regel og ein tabell er separate avgjerder

Å velje ein tabell og å fylle han er uavhengige steg, og samanlikninga betyr noko her fordi dei to ofte blir forveksla under feilsøking. Ein regel som sender merkt trafikk til tabell 100, gjer ingenting viss tabell 100 ikkje har ei passande rute, og ein godt fylt tabell er uoppnåeleg viss ingen regel peikar på han.

Halvparten av ei standardrute er ikkje ei standardrute. Ei enkelt 0.0.0.0/1 dekkjer den nedre halvdelen av IPv4-rommet, så ein policy som vil fange alt, treng også den matchende 128.0.0.0/1, eller ei ekte default. Å lese ein fungerande konfigurasjon og kopiere ein av dei to halvdelane er korleis folk endar med ei rutingsløyfe som berre bryt på visse destinasjonar.

La medvitne unntak stå for adressene som må bli på LAN-et, og avgjer kva som skjer når oppslaget ikkje finn noko i den valde tabellen. Ei uttrykkeleg reserverute er lettare å resonnere om enn ein tom tabell, som gir eit uoppnåeleg resultat og får applikasjonen til å sjå øydelagd ut snarare enn feilruta.

Still oppslaget spørsmålet applikasjonen din stiller

ip route get løyser opp ein veg; ip route show viser lagra oppføringar, og dei to kan vere usamde utan at nokon av dei er feil. Ta med kildekonteksten, fordi kjeldebaserte reglar berre matchar når oppslaget ber med seg ei kjelde.

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 frå verten. Den andre legg til eit inngåande grensesnitt, som er nærare det videresend trafikk opplever, og svaret peikar ofte på ein annan tabell. Ingen av destinasjonane er ein livetestteneste; 198.51.100.23 er ei dokumentasjonsadresse, så byt ho ut med ein vert du har lov til å sondere.

Sjølv eit korrekt oppslag beviser berre at ein veg vart vald. Det seier ingenting om den andre sida godtek trafikken, eller om svaret kan kome tilbake gjennom same resonnement.

Der samanlikninga vippar

Vertstrafikk og videresend trafikk tar ikkje berre forskjellige oppslag; dei møter forskjellige filter på vegen tilbake. Linux brukar reverse-path-validering med den strengaste av innstillingane for alle grensesnitt og for det mottakande grensesnittet, så ei endring av verdien til eitt grensesnitt kan ha ingen synleg effekt. Merkebasert ruting legg til relasjonen src_valid_mark, der merket må stemme for at ei kjelde skal reknast som gyldig.

Viss svar forsvinn medan den utgåande rutinga ser riktig ut, les dei effektive verdiane før du rører dei, og endre dei berre med ein oppgitt policygrunn.

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

Vel mellom dei to designa på bevis: viss applikasjonen bind til PPP-adressa, er ein kjeldereregel pluss ein tabell med peer-ruta nok. Viss boksen videresender for eit LAN bak seg, treng du også at inngangskonteksten og returvegen er samde. Når dei ikkje er det, rettar du eigarskapet til ruta i staden for å lempe på valideringa for heile maskinen.