route-gateway er ikkje redirect-gateway: kva som faktisk endrar seg

Tunnelen din kjem opp, det private subnettet svarar, og vanleg nettlesing forsvinn framleis inn i VPN-en sjølv om nokon har sletta gateway-linja frå profilen. Den kombinasjonen er fingeravtrykket til den gale direktivet som vart redigert. Det som vart fjerna, gav klienten eit neste hopp for rutene han installerer; det som heldt fram med å fanga trafikk, kom frå ein annan stad og vart skyvd av tenaren. Dekking og neste hopp er separate oppgåver, og berre éin av dei avgjer om offentlege destinasjonar brukar tunnelen.

Linja du fjerna var eit neste hopp, ikkje ein policy-brytar

Kvar rute klienten installerer treng ei gateway-adresse å peike på, og gateway-direktivet er der den adressa kjem frå når ei rute ikkje sjølv namngjev ei. Slett det, og desse rutene har ingenting å hengje på, så dei vert anten ikkje installerte eller hamnar på ein veg som ikkje fører nokon stad. Det private subnettet er nettopp det ei slik rute bar.

I mellomtida har åtferda som overlevde ein annan forfattar: eit omdirigeringsalternativ i den skyvde blokka, som flyttar vanleg utgåande trafikk inn i tunnelen etter flagga sine. Å fjerna gatewayen deaktiverer eller svekkjer han ikkje. Resultatet er det verste av begge tilstandar, med offentleg trafikk framleis fanga og den private destinasjonen som rettferdiggjorde tunnelen no utilgjengeleg. Derfor endrar den andre redigeringa, gjord i same ånd, heller ingenting.

Fire spakar, fire ulike oppgåver

Fire direktiv vert siterte om kvarandre i denne diskusjonen, og berre eitt av dei styrer dekning, altså kva destinasjonar som i det heile går gjennom tunnelen. Eit andre set det neste hoppet som rutene brukar, eit tredje installerer eitt einskilt prefiks, og eit fjerde kastar bort alt tenaren skyvde, inkludert dei private rutene utrullinga treng. Tabellen sorterer dei etter kva ein administrator prøver å endre, ikkje etter namn, fordi det er namna som skaper forvirringa. Handsame dei som fire separate avgjerder og vel den du faktisk vil reversere.

I praksis kjem alle fire ofte i éi skyvd blokk, linje for linje, noko som får dei til å sjå ut som delar av éi innstilling. Det er dei ikkje, og OpenVPN-referansen dokumenterer dei som ulike mekanismar nettopp derfor. Å finne ut kva avgjerd du reverserer, er jobben; redigeringa er éi linje.

Filtrer den skyvde linja, behald neste hopp

Viss dekninga du protesterer mot kjem som eit skyvt alternativ, er det tronge svaret å ignorere det alternativet ved namn og la resten av den skyvde blokka vere intakt. Skriven som eit filter ser det ut som linja nedanfor, og det høyrer i profilen til den råka klienten, ikkje i tenarkonfigurasjonen.

pull-filter ignore "redirect-gateway"

Trongheit er poenget. Fordi filteret samanliknar eit tekstprefiks, passar eit kortare mønster også på neste-hopp-direktivet, noko som riv bort nøyaktig den informasjonen dei private rutene er avhengige av, og gjer den opphavlege feilen om att i ny drakt. Eit filter verkar også berre på skyvde alternativ, så det rører aldri ei tilsvarande linje skriven lokalt eller påtvinga av ein nettverksansvarleg. Kople til på nytt etterpå, fordi ein levande sesjon ikkje vurderer på nytt det tenaren skyvde.

Les oppslaget, ikkje tabellen

Etter å ha lasta profilen på nytt, spør kjernen kvar to destinasjonar faktisk ville gå: éin inne i det private prefikset og éin på det offentlege internettet. Ein full dump av hovudtabellen er vanskelegare å lese og lettare å lese feil, fordi ei rute kan finnast og likevel tape mot eit meir spesifikt treff. Under policy-ruting høyrer regelen, tabellen og kjeldeadressa også med i kontrollen.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

def1-varianten fortener kjennskap, fordi han lèt den gamle standardoppføringa vere synleg medan eit par halvstandardar vinn oppslaget. Ei 0.0.0.0/0-linje i utdata beviser derfor ingenting i seg sjølv. Oppslaget svarar på spørsmålet som lista berre ser ut til å svare på.

DNS, IPv6 og den private ruta må framleis verke

Å avvise éi IPv4-omdirigering seier ingenting om resolvaren, så eit skyvt DNS-alternativ kan halde fram med å sende spørjingar inn i tunnelen medan rutene ser riktige ut. Ein IPv6-standard kan gjere det same for ein adressefamilie IPv4-kontrollen aldri rørte. Begge treng ei eksplisitt avgjerd i staden for ei antaking. Stadfest deretter at den private tenesta framleis svarar, fordi ein delt tunnel som har mista si private rute ikkje er ein delt tunnel, han er øydelagd.

Eitt breiare verktøy fortener ei åtvaring: route-nopull kastar kvar skyvd rute og kvart skyvt DNS-alternativ, noko som utan tvil stoppar full tunnelen og like utan tvil øydelegg dei private rutene utrullinga er avhengig av, så det er ein langt større hammar enn eit namnefilter retta mot eitt alternativ. Kontroller den private destinasjonen, ein offentleg destinasjon og resolvaren etter kvar endring, og sjå på eit fullført handtrykk som bevis for ingenting anna enn handtrykket.