route-gateway er ikke redirect-gateway: hvad der faktisk ændrer sig

Din tunnel kommer op, det private subnet svarer, og almindelig browsing forsvinder stadig ind i VPN’en, selvom nogen har slettet gateway-linjen fra profilen. Den kombination er fingeraftrykket af den forkerte direktiv, der blev redigeret. Det, der blev fjernet, gav klienten et næste hop til de ruter, den installerer; det, der fortsatte med at fange trafik, kom fra et andet sted og blev skubbet af serveren. Dækning og næste hop er separate opgaver, og kun én af dem afgør, om offentlige destinationer bruger tunnelen.

Linjen, du fjernede, var et næste hop, ikke en policy-kontakt

Hver rute, klienten installerer, har brug for en gateway-adresse at pege på, og gateway-direktivet er, hvor den adresse kommer fra, når en rute ikke selv angiver en. Slet det, og de ruter har intet at hænge på, så de installeres enten ikke eller ender på en vej, der fører ingen steder hen. Det private subnet er netop det, sådan en rute bar.

Imens har den adfærd, der overlevede, en anden forfatter: en omdirigeringsindstilling i den skubbede blok, som flytter almindelig udgående trafik ind i tunnelen efter sine flag. At fjerne gatewayen hverken deaktiverer eller svækker den. Resultatet er det værste af begge tilstande, med offentlig trafik stadig fanget og den private destination, der berettigede tunnelen, nu utilgængelig. Derfor ændrer den anden redigering, lavet i samme ånd, heller intet.

Fire håndtag, fire forskellige opgaver

Fire direktiver citeres i flæng i denne diskussion, og kun ét af dem styrer dækning, altså hvilke destinationer der overhovedet rutes gennem tunnelen. Et andet sætter det næste hop, som ruter bruger, et tredje installerer et enkelt præfiks, og et fjerde kaster alt væk, som serveren skubbede, inklusive de private ruter, som udrulningen har brug for. Tabellen sorterer dem efter, hvad en administrator prøver at ændre, snarere end efter navn, fordi det er navnene, der skaber forvirringen. Behandl dem som fire separate beslutninger, og vælg den, du faktisk vil rulle tilbage.

I praksis ankommer alle fire ofte i én skubbet blok, linje efter linje, hvilket får dem til at ligne dele af én indstilling. Det er de ikke, og OpenVPN-referenceværket dokumenterer dem netop derfor som forskellige mekanismer. At finde ud af, hvilken beslutning du ruller tilbage, er opgaven; redigeringen er én linje.

Filtrer den skubbede linje, behold næste hop

Hvis den dækning, du har indvendinger imod, ankommer som en skubbet indstilling, er det snævre svar at ignorere den indstilling ved navn og lade resten af den skubbede blok være intakt. Skrevet som et filter ser det ud som linjen nedenfor, og det hører i profilen for den berørte klient, ikke i serverkonfigurationen.

pull-filter ignore "redirect-gateway"

Snæverhed er pointen. Fordi filteret sammenligner et tekstpræfiks, matcher et kortere mønster også næste-hop-direktivet, hvilket fjerner præcis den information, som de private ruter afhænger af, og gentager den oprindelige fejl i ny klædedragt. Et filter virker også kun på skubbede indstillinger, så det rører aldrig en tilsvarende linje, der er skrevet lokalt eller påtvunget af en netværksadministrator. Genopret forbindelsen bagefter, fordi en levende session ikke genvurderer, hvad serveren skubbede.

Læs opslaget, ikke tabellen

Efter at have genindlæst profilen, spørg kernen, hvor to destinationer faktisk ville gå hen: én inde i det private præfiks og én på det offentlige internet. Et fuldt dump af hovedtabellen er sværere at læse og lettere at læse forkert, fordi en rute kan findes og alligevel tabe til et mere specifikt match. Under policy routing hører reglen, 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 fortrolighed, fordi den lader den gamle standardpost være synlig, mens et par halv-standarder vinder opslaget. En 0.0.0.0/0-linje i outputtet beviser derfor intet i sig selv. Opslaget besvarer det spørgsmål, som listen kun ser ud til at besvare.

DNS, IPv6 og den private rute skal stadig virke

At afvise én IPv4-omdirigering siger intet om resolveren, så en skubbet DNS-indstilling kan fortsætte med at sende forespørgsler ind i tunnelen, mens ruterne ser rigtige ud. En IPv6-standard kan gøre det samme for en adressefamilie, som IPv4-kontrollen aldrig rørte. Begge kræver en eksplicit beslutning i stedet for en antagelse. Bekræft derefter, at den private tjeneste stadig svarer, fordi en split tunnel, der har mistet sin private rute, ikke er en split tunnel, men en brudt en.

Et bredere værktøj fortjener en advarsel: route-nopull smider hver skubbet rute og hver skubbet DNS-indstilling væk, hvilket afgjort stopper full tunnelen og lige så afgjort brækker de private ruter, som udrulningen afhænger af, så det er en langt større hammer end et navnefilter rettet mod én indstilling. Kontroller den private destination, en offentlig destination og resolveren efter enhver ændring, og betragt et fuldført håndtryk som bevis på intet andet end håndtrykket.