OpenVPN pull-filter matcher mere end den rute, du havde tænkt på

Du tilføjer én linje for at beholde din lokale standardrute, og derefter når tunnelen ikke længere den interne DNS-server. Linjen var pull-filter ignore "route", hvilket ikke betyder "ignorér denne rute". Det betyder "smid hver skubbet indstilling væk, hvis tekst begynder med de fem bogstaver", og på en normal server omfatter det route-gateway, route-metric og route-ipv6 sammen med selve ruterne. Tjeklisten nedenfor er det, jeg kører, før jeg rører en profil, som en anden skal bruge.

Filteret gælder kun skubbede indstillinger

pull-filter virker på de indstillingslinjer, serveren sender, efter tunnelen er etableret, og på intet andet. Indstillinger skrevet i din lokale fil påvirkes ikke af det, og applikationstrafik gør heller ikke. Hvis du håbede at forhindre en proces i at bruge tunnelen, er dette det helt forkerte værktøj, og ingen kombination af filtre vil gøre det.

Det omfang er nyttigt, fordi det betyder, at du kan lade serverens konfiguration være og alligevel afvise en del af den lokalt. Det er også en begrænsning, der er værd at nævne i billetten: et filter ændrer, hvad denne klient accepterer, ikke hvad serveren tilbyder. Det har ingen effekt på andre brugere af samme profil. Det overlever heller ikke et skift til en anden klient, der ikke implementerer indstillingen, hvilket er værd at vide, før du bygger en arbejdsgang på det.

Bekræft, hvad serveren faktisk sender, før du skriver mønsteret. Ved høj detaljegrad udskriver klienten den skubbede indstillingsstreng, den modtog, og det er den eneste ærlige kilde til den præcise tekst, du matcher imod:

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Læs den skubbede linje som en liste af indstillinger adskilt af kommaer, og bemærk, at indstillingsnavne og deres argumenter er adskilt af mellemrum. Din filtertekst sammenlignes med den strøm, og derfor betyder mellemrum så meget i næste trin.

Matchning er et præfiks, så mellemrum er hele spillet

Sammenligningen er et strengpræfiks, ikke et parset indstillingsnavn. Derfor matcher "route" både route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 og route-metric 100. Ét mellemrum til sidst indsnævrer det til den familie, du sandsynligvis mente, og det fulde præfiks indsnævrer det yderligere til en bestemt destination.

Den sidste række er den, der fanger folk under split-tunnel-arbejde. At beholde sin egen resolver er et legitimt valg, og det betyder, at hvert internt navn nu afhænger af en resolver, der ikke kan se den private zone. Det er en konsekvens, man accepterer med vilje, ikke en bivirkning, man opdager i produktion.

Præfiks-matchning betyder også, at en regel senere kan udvide sig lydløst. Når serveren tilføjer en ny indstilling, der begynder med din tekst, begynder dit filter at gælde for den, uden at nogen redigerer din profil. Det er den fejltilstand, der skal designes imod, og afbødningen er at matche så meget af indstillingen som muligt i stedet for så lidt som muligt.

Tre verber med tre forskellige udfald

accept, ignore og reject er ikke tre stavemåder af den samme idé. De adskiller sig i, hvad klienten gør ved et match, og i om nogen finder ud af det.

ignore dropper den matchende indstilling i stilhed, hvilket er det, du vil have til en indstilling, du bevidst har erstattet. reject dropper den og får klienten til at klage, hvilket er det, du vil have, når dens fravær skal ses i en log i stedet for at blive opdaget senere. accept er den positive form, brugt når du bygger en tilladelsesliste i stedet for at fjerne enkelte indstillinger.

Hvilket verbum du end bruger, anvendes filtrene i den rækkefølge, de optræder, så to overlappende regler giver et rækkefølgeafhængigt resultat, der er meget svært at gennemgå. Hold én regel pr. hensigt, og sæt den mest specifikke tekst i hver. Hvis du har brug for en tilladelsesliste, foretræk få accept-regler frem for en bunke ignore-regler, der giver det samme. Så kan anmeldere læse filen fra top til bund og forudsige resultatet, og det er den eneste test, der skalerer.

Kontrollér den anvendte rute og resolver, ikke profilen

Et filter, der ser korrekt ud i filen, kan stadig efterlade dig med en tunnel, der ikke ruter noget nyttigt. Bekræft virkningen på det kørende system, hvor skubbede indstillinger allerede er anvendt eller droppet:

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

De to første linjer fortæller dig om den skubbede standardrute nåede frem og hvor mange statiske poster, der overlevede. Resolver-forespørgslen viser, hvilken server tunnelinterfacet faktisk bruger, og det er normalt der, en DNS-overraskelse dukker op. Den sidste linje besvarer det eneste spørgsmål, der betyder noget for en bruger.

Test begge retninger, mens du er der. En regel, der holder dit lokale internet kørende, men lydløst ødelægger intern navneopløsning, består en overfladisk kontrol og fejler den første rigtige opgave, så inkludér én intern ressource og ét offentligt websted i samme test.

Notér undtagelsen og hvem der ejer den

Et filter er en undtagelse fra operatørens design, så skriv den ned med en begrundelse og et gennemgangspunkt. "Ignorerer skubbede ruter for at beholde den lokale standard" kan gennemgås; en bar linje i en profil kan ikke, og den næste person vil slette den eller udvide den ved gætteri.

Version betyder også noget her. Matchningsadfærden og den præcise accepterede syntaks er blevet finpudset gennem OpenVPN 2.4, 2.5 og 2.6, så bekræft mønsteret mod manualen til det build, du udruller, i stedet for mod et forumindlæg om en ældre version. OpenVPN 2.6-manualen dokumenterer indstillingen og dens matchningsregel.

Endelig skal du aftale undtagelsen med den, der driver serveren. Et klient-side filter, der modsiger en bevidst serverpolitik, er en supporthændelse, der venter på den næste revision, og det er meget billigere at afgøre det, før profilen udrulles, end efter nogen opdager, at ruterne mangler.