OpenVPN pull-filter treffer mer enn ruten du mente

Du legger til én linje for å beholde den lokale standardruten, og etter det når ikke tunnelen den interne DNS-serveren lenger. Linjen var pull-filter ignore "route", som ikke betyr "ignorer denne ruten". Det betyr "slipp hver pushet opsjon hvis tekst begynner med de fem bokstavene", og på en vanlig server omfatter det route-gateway, route-metric og route-ipv6 sammen med selve rutene. Sjekklisten nedenfor er det jeg går gjennom før jeg rører en profil som noen andre må bruke.

Filteret gjelder bare pushede opsjoner

pull-filter virker bare på opsjonslinjene serveren sender etter at tunnelen er etablert, og på ingenting annet. Opsjoner skrevet i din lokale fil påvirkes ikke av det, og applikasjonstrafikk heller ikke. Hvis du håpet å hindre en prosess i å bruke tunnelen, er dette helt feil verktøy, og ingen kombinasjon av filtre vil gjøre det.

Det omfanget er nyttig, fordi det betyr at du kan la serverens konfigurasjon være og likevel avvise en del av den lokalt. Det er også en begrensning som er verdt å notere i saken: et filter endrer hva denne klienten godtar, ikke hva serveren tilbyr. Det har ingen effekt på andre brukere av samme profil. Det overlever heller ikke et bytte til en annen klient som ikke implementerer opsjonen, noe som er verdt å vite før du bygger en arbeidsflyt på det.

Bekreft hva serveren faktisk sender før du skriver mønsteret. Ved høy detaljering skriver klienten ut den pushede opsjonsstrengen den mottok, og det er den eneste ærlige kilden til den nøyaktige teksten du matcher mot:

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

Les den pushede linjen som en liste med opsjoner atskilt av kommaer, og legg merke til at opsjonsnavn og argumentene deres er atskilt med mellomrom. Filterteksten din sammenlignes med den strømmen, derfor betyr mellomrom så mye i neste trinn.

Sammenligningen er et prefiks, så mellomrom avgjør alt

Sammenligningen er et strengprefiks, ikke et tolket opsjonsnavn. Derfor treffer "route" både route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 og route-metric 100. Ett mellomrom til slutt snevrer det inn til familien du sannsynligvis mente, og det fulle prefikset snevrer det ytterligere inn til en bestemt destinasjon.

Den siste raden er den som fanger folk under split-tunnel-arbeid. Å beholde sin egen resolver er et legitimt valg, og det betyr at hvert internt navn nå avhenger av en resolver som ikke kan se den private sonen. Det er en konsekvens man godtar med vilje, ikke en bivirkning man oppdager i produksjon.

Prefiksmatching betyr også at en regel senere kan utvide seg lydløst. Når serveren legger til en ny opsjon som begynner med teksten din, begynner filteret ditt å gjelde for den uten at noen redigerer profilen din. Det er feilmodusen man må designe mot, og avbøtingen er å matche så mye av opsjonen som mulig i stedet for så lite som mulig.

Tre verb med tre ulike utfall

accept, ignore og reject er ikke tre stavemåter av samme idé. De skiller seg i hva klienten gjør med en treff og i om noen får vite det.

ignore slipper den matchende opsjonen stille, noe du vil ha for en innstilling du bevisst har erstattet. reject slipper den og får klienten til å klage, noe du vil ha når fraværet skal vises i en logg i stedet for å oppdages senere. accept er den positive formen, brukt når du bygger en tillatelsesliste i stedet for å fjerne enkeltopsjoner.

Uansett hvilket verb du bruker, brukes filtrene i den rekkefølgen de vises, så to overlappende regler gir et rekkefølgeavhengig resultat som er svært vanskelig å gjennomgå. Hold én regel per hensikt, og sett den mest spesifikke teksten i hver. Hvis du trenger en tillatelsesliste, foretrekk noen få accept-regler fremfor en haug med ignore-regler som summerer til det samme. Da kan gjennomgåere lese filen ovenfra og ned og forutsi resultatet, og det er den eneste testen som skalerer.

Sjekk den brukte ruten og resolveren, ikke profilen

Et filter som ser riktig ut i filen, kan fortsatt la deg sitte igjen med en tunnel som ikke ruter noe nyttig. Verifiser effekten på det kjørende systemet, der pushede opsjoner allerede er anvendt eller sluppet:

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 linjene forteller deg om den pushede standardruten kom frem og hvor mange statiske oppføringer som overlevde. Resolver-spørringen viser hvilken server tunnelgrensesnittet faktisk bruker, og det er vanligvis der en DNS-overraskelse dukker opp. Den siste linjen svarer på det eneste spørsmålet som betyr noe for en bruker.

Test begge retninger mens du er der. En regel som holder det lokale internettet i gang, men lydløst ødelegger intern navneoppslag, består en overfladisk sjekk og feiler på den første virkelige oppgaven, så ta med én intern ressurs og ett offentlig nettsted i samme test.

Skriv ned unntaket og hvem som eier det

Et filter er et unntak fra operatørens design, så skriv det ned med en begrunnelse og et gjennomgangspunkt. "Ignorerer pushede ruter for å beholde den lokale standarden" er gjennomgåelig; en bar linje i en profil er det ikke, og neste person vil slette den eller utvide den ved gjetting.

Versjonen betyr noe her også. Matcheatferden og den nøyaktige aksepterte syntaksen er blitt finpusset gjennom OpenVPN 2.4, 2.5 og 2.6, så bekreft mønsteret mot håndboken for bygget du leverer, og ikke mot et foruminnlegg om en eldre versjon. OpenVPN 2.6-håndboken dokumenterer opsjonen og matcheregelen.

Til slutt, avtal unntaket med den som driver serveren. Et klientsidefilter som motsier en bevisst serverpolicy, er en supporthendelse som venter på neste revisjon, og det er mye billigere å avklare det før profilen sendes ut enn etter at noen har lagt merke til at rutene mangler.