route-gateway er ikke redirect-gateway: hva som faktisk endres

Tunnelen din kommer opp, det private subnettet svarer, og vanlig nettlesing forsvinner fortsatt inn i VPN-en selv om noen har slettet gateway-linjen fra profilen. Den kombinasjonen er fingeravtrykket til det feil direktivet som ble redigert. Det som ble fjernet, ga klienten et neste hopp for rutene den installerer; det som fortsatte å fange trafikk, kom fra et annet sted og ble skjøvet av serveren. Dekning og neste hopp er separate oppgaver, og bare én av dem avgjør om offentlige destinasjoner bruker tunnelen.

Linjen du fjernet var et neste hopp, ikke en policy-bryter

Hver rute klienten installerer trenger en gateway-adresse å peke på, og gateway-direktivet er der den adressen kommer fra når en rute ikke selv navngir en. Slett det, og disse rutene har ingenting å henge på, så de installeres enten ikke eller havner på en vei som ikke fører noe sted. Det private subnettet er nettopp det en slik rute bar.

I mellomtiden har atferden som overlevde en annen forfatter: et omdirigeringsalternativ i den skjøvede blokken, som flytter vanlig utgående trafikk inn i tunnelen etter flaggene sine. Å fjerne gatewayen deaktiverer eller svekker den ikke. Resultatet er det verste av begge tilstander, med offentlig trafikk fortsatt fanget og den private destinasjonen som rettferdiggjorde tunnelen nå utilgjengelig. Derfor endrer den andre redigeringen, gjort i samme ånd, heller ingenting.

Fire spaker, fire forskjellige oppgaver

Fire direktiver siteres om hverandre i denne diskusjonen, og bare ett av dem styrer dekning, altså hvilke destinasjoner som i det hele tatt rutes gjennom tunnelen. Et andre angir neste hopp som rutene bruker, et tredje installerer ett enkelt prefiks, og et fjerde kaster bort alt serveren skjøv, inkludert de private rutene utrullingen trenger. Tabellen sorterer dem etter hva en administrator prøver å endre, ikke etter navn, fordi det er navnene som skaper forvirringen. Behandle dem som fire separate beslutninger og velg den du faktisk vil reversere.

I praksis kommer alle fire ofte i én skjøvet blokk, linje for linje, noe som får dem til å se ut som deler av én innstilling. Det er de ikke, og OpenVPN-referansen dokumenterer dem som ulike mekanismer nettopp derfor. Å finne ut hvilken beslutning du reverserer, er jobben; redigeringen er én linje.

Filtrer den skjøvede linjen, behold neste hopp

Hvis dekningen du protesterer mot kommer som et skjøvet alternativ, er det snevre svaret å ignorere det alternativet ved navn og la resten av den skjøvede blokken være intakt. Skrevet som et filter ser det ut som linjen nedenfor, og det hører i profilen til den berørte klienten, ikke i serverkonfigurasjonen.

pull-filter ignore "redirect-gateway"

Snevhet er poenget. Fordi filteret sammenligner et tekstprefiks, passer et kortere mønster også på neste-hopp-direktivet, noe som river bort nøyaktig informasjonen de private rutene er avhengige av, og gjentar den opprinnelige feilen i ny drakt. Et filter virker også bare på skjøvede alternativer, så det berører aldri en tilsvarende linje skrevet lokalt eller påtvunget av en nettverksansvarlig. Koble til på nytt etterpå, fordi en levende sesjon ikke vurderer på nytt det serveren skjøv.

Les oppslaget, ikke tabellen

Etter å ha lastet profilen på nytt, spør kjernen hvor to destinasjoner faktisk ville gå: én inne i det private prefikset og én på det offentlige internettet. En full dump av hovedtabellen er vanskeligere å lese og lettere å lese feil, fordi en rute kan finnes og likevel tape mot en mer spesifikk treff. Under policy-ruting hører regelen, tabellen og kildeadressen også med i kontrollen.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

def1-varianten fortjener kjennskap, fordi den lar den gamle standardoppføringen være synlig mens et par halvstandarder vinner oppslaget. En 0.0.0.0/0-linje i utdata beviser derfor ingenting i seg selv. Oppslaget svarer på spørsmålet som listen bare ser ut til å svare på.

DNS, IPv6 og den private ruten må fortsatt virke

Å avvise én IPv4-omdirigering sier ingenting om resolveren, så et skjøvet DNS-alternativ kan fortsette å sende spørringer inn i tunnelen mens rutene ser riktige ut. En IPv6-standard kan gjøre det samme for en adressefamilie IPv4-kontrollen aldri rørte. Begge trenger en eksplisitt beslutning i stedet for en antakelse. Bekreft deretter at den private tjenesten fortsatt svarer, fordi en delt tunnel som har mistet sin private rute ikke er en delt tunnel, den er ødelagt.

Ett bredere verktøy fortjener en advarsel: route-nopull kaster hver skjøvet rute og hvert skjøvet DNS-alternativ, noe som utvilsomt stopper full tunnelen og like utvilsomt ødelegger de private rutene utrullingen er avhengig av, så det er en langt større hammer enn et navnefilter rettet mot ett alternativ. Kontroller den private destinasjonen, en offentlig destinasjon og resolveren etter enhver endring, og betrakt et fullført håndtrykk som bevis for ingenting annet enn håndtrykket.