OpenVPN pull-filter treff fleire enn ruta du meinte

Du legg til éi linje for å halde den lokale standardruta, og etter det når ikkje tunnelen den interne DNS-tenaren lenger. Linja var pull-filter ignore "route", som ikkje tyder "ignorer denne ruta". Det tyder "slepp kvar pusha opsjon der teksten byrjar med dei fem bokstavane", og på ein vanleg tenar omfattar det route-gateway, route-metric og route-ipv6 saman med sjølve rutene. Sjekklista nedanfor er det eg går gjennom før eg rører ein profil som nokon andre må bruke.

Filteret gjeld berre pusha opsjonar

pull-filter verkar berre på opsjonslinjene tenaren sender etter at tunnelen er etablert, og på ingenting anna. Opsjonar skrivne i den lokale fila di vert ikkje påverka av det, og applikasjonstrafikk heller ikkje. Viss du håpa å hindre ein prosess i å bruke tunnelen, er dette heilt feil verkty og ingen kombinasjon av filter vil gjere det.

Det omfanget er nyttig, fordi det tyder at du kan la konfigurasjonen til tenaren vere og likevel avvise ein del av han lokalt. Det er òg ei avgrensing som er verd å notere i saka: eit filter endrar kva denne klienten godtek, ikkje kva tenaren tilbyr. Det har ingen effekt på andre brukarar av same profil. Det overlever heller ikkje eit byte til ein annan klient som ikkje implementerer opsjonen, noko som er verd å vite før du byggjer ein arbeidsflyt på det.

Stadfest kva tenaren faktisk sender før du skriv mønsteret. Ved høg detaljering skriv klienten ut den pusha opsjonsstrengen han fekk, og det er den einaste ærlege kjelda til den nøyaktige teksten du matchar mot:

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

Les den pusha linja som ei liste med opsjonar skilde av komma, og legg merke til at opsjonsnamn og argumenta deira er skilde av mellomrom. Filterteksten din vert samanlikna med den straumen, difor betyr mellomrom så mykje i neste steg.

Samanlikninga er eit prefiks, så mellomrom avgjer alt

Samanlikninga er eit strengprefiks, ikkje eit tolka opsjonsnamn. Difor treff "route" både route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 og route-metric 100. Eitt mellomrom til slutt snevrar det inn til familien du truleg meinte, og det fulle prefikset snevrar det ytterlegare inn til ein bestemt destinasjon.

Den siste rada er den som fangar folk under split-tunnel-arbeid. Å halde sin eigen resolver er eit legitimt val, og det tyder at kvart internt namn no er avhengig av ein resolver som ikkje kan sjå den private sona. Det er ein konsekvens ein godtek med vilje, ikkje ein biverknad ein oppdagar i produksjon.

Prefiksmatching tyder òg at ei regel seinare kan utvide seg lydlaust. Når tenaren legg til ein ny opsjon som byrjar med teksten din, byrjar filteret ditt å gjelde for han utan at nokon redigerer profilen din. Det er feilmodusen ein må designe mot, og avbøtinga er å matche så mykje av opsjonen som mogleg i staden for så lite som mogleg.

Tre verb med tre ulike utfall

accept, ignore og reject er ikkje tre stavemåtar av same idé. Dei skil seg i kva klienten gjer med ein treff og i om nokon får vite det.

ignore slepp den matchande opsjonen stille, noko du vil ha for ei innstilling du med vilje har erstatta. reject slepp han og får klienten til å klage, noko du vil ha når fråværet skal visast i ein logg i staden for å oppdagast seinare. accept er den positive forma, brukt når du byggjer ei tillatingsliste i staden for å fjerne einskildopsjonar.

Kva verb du enn brukar, vert filtra brukte i den rekkjefølgja dei viser seg, så to overlappande reglar gir eit rekkjefølgjeavhengig resultat som er svært vanskeleg å gjennomgå. Hald éi regel per føremål, og set den mest spesifikke teksten i kvar. Viss du treng ei tillatingsliste, føretrekk nokre få accept-reglar framfor ein haug med ignore-reglar som summerer til det same. Då kan gjennomgåarane lese fila ovanfrå og ned og føreseie resultatet, og det er den einaste testen som skalerer.

Sjekk den brukte ruta og resolveren, ikkje profilen

Eit filter som ser rett ut i fila, kan framleis la deg sitje att med ein tunnel som ikkje ruter noko nyttig. Stadfest effekten på det køyrande systemet, der pusha opsjonar alt er brukte eller sleppte:

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/

Dei to første linjene fortel deg om den pusha standardruta kom fram og kor mange statiske oppføringar som overlevde. Resolver-spurnaden viser kva tenar tunnelgrensesnittet faktisk brukar, og det er vanlegvis der ei DNS-overrasking dukkar opp. Den siste linja svarar på det einaste spørsmålet som betyr noko for ein brukar.

Test begge retningar medan du er der. Ei regel som held det lokale internettet i gang, men lydlaust øydelegg intern namneoppslag, går gjennom ein overflatisk sjekk og feilar på den første verkelege oppgåva, så ta med éin intern ressurs og eitt offentleg nettstad i same test.

Skriv ned unntaket og kven som eig det

Eit filter er eit unntak frå designet til operatøren, så skriv det ned med ei grunngiving og eit gjennomgangspunkt. "Ignorerer pusha ruter for å halde den lokale standarden" er gjennomgåeleg; ei bar linje i ein profil er det ikkje, og neste person vil slette ho eller utvide ho ved gjetting.

Versjonen betyr noko her òg. Matcheåtferda og den nøyaktige aksepterte syntaksen er blitt finpussa gjennom OpenVPN 2.4, 2.5 og 2.6, så stadfest mønsteret mot handboka for bygget du leverer, og ikkje mot eit foruminnlegg om ein eldre versjon. OpenVPN 2.6-handboka dokumenterer opsjonen og matcheregelen.

Til slutt, avtal unntaket med den som driv tenaren. Eit klientsidefilter som motseler ein medviten tenarpolicy, er ei støttehending som ventar på neste revisjon, og det er mykje billegare å avklare det før profilen vert send ut enn etter at nokon har lagt merke til at rutene manglar.