Jo foegje ien regel ta om jo lokale standertrûte te hâlden, en dêrnei berikt de tunnel de ynterne DNS-tsjinner net mear. De regel wie pull-filter ignore "route", wat net "negearje dizze rûte" betsjut. It betsjut "smyt elke tawiisde opsje fuort wêrfan de tekst mei dy fiif letters begjint", en op in normale tsjinner omfettet dat route-gateway, route-metric en route-ipv6 tegearre mei de rûtes sels. De checklist hjirûnder is wat ik draai foardat ik in profyl oanrekke dat immen oars brûke moat.

It filter jildt allinnich foar tawiisde opsjes

pull-filter wurket op 'e opsjeregels dy't de tsjinner stjoert neidat de tunnel fêststeld is, en op neat oars. Opsjes skreaun yn jo lokale bestân wurde dêr net troch beynfloede, en applikaasjeferkear ek net. As jo hoopje om in proses te stopjen it tunnel te brûken, is dit folslein it ferkearde ark en gjin kombinaasje fan filters sil dat dwaan.

Dat berik is nuttich, want it betsjut dat jo de konfiguraasje fan 'e tsjinner gewurde litte kinne en dochs in part derfan lokaal wegerje. It is ek in beheining dy't de muoite wurdich is om yn 'e ticket te neamen: in filter feroaret wat dizze klient akseptearret, net wat de tsjinner biedt. It hat gjin effekt op oare brûkers fan itselde profyl. It oerlibbet ek gjin oerstap nei in oare klient dy't de opsje net ymplementearret, wat de muoite wurdich is om te witten foardat jo dêr in wurkstream op bouwe.

Kontrolearje wat de tsjinner eins stjoert foardat jo it patroan skriuwe. By hege ferboazens printsjet de klient de tawiisde opsje-string dy't er krige, en dat is de iennige earlike boarne foar de krekte tekst dêr't jo tsjin fergelykje:

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

Lês de tawiisde regel as in list fan opsjes skieden troch komma's, en merkte op dat opsjenammen en har arguminten skieden wurde troch spaasjes. Jo filtertekst wurdt fergelike mei dy stroom, dêrom binne spaasjes sa wichtich yn 'e folgjende stap.

Match is in foarheaksel, dus spaasjes binne it hiele spul

De fergeliking is in stringfoarheaksel, gjin parste opsjenamme. Dêrom matcht "route" sawol route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 as route-metric 100. Ien spaasje oan 'e ein ferneitert it ta de famylje dy't jo wierskynlik bedoelden, en it folsleine foarheaksel ferneitert it fierder ta in konkreet bestimming.

Filter textWhat it actually matchesTypical outcome
"route"Every option beginning with those lettersRoutes, gateway, metric and IPv6 routes all dropped
"route "Route entries only, not the hyphenated siblingsThe routes go, the rest survives
"route 10.60."A single destination rangeThe narrowest rule, and the easiest to audit
"dhcp-option DNS"Pushed DNS settingsResolver stays local, internal names stop resolving

De lêste rige is dejinge dy't minsken by split-tunnelwurk fangt. Jo eigen resolver hâlde is in legitime kar, en it betsjut dat elke ynterne namme no ôfhinklik is fan in resolver dy't de partikuliere sône net sjen kin. Dat is in gefolch dat men bewust akseptearret, gjin byefekt dat men yn produksje ûntdekt.

Foarheakselmatch betsjut ek dat in regel letter stil ferbrede wurde kin. As de tsjinner in nije opsje tafoeget dy't mei jo tekst begjint, begjint jo filter dêrop te jilden sûnder dat immen jo profyl bewurket. Dat is de flatermodus dêr't jo tsjin ûntwerpe moatte, en de mildering is safolle mooglik fan 'e opsje te matchen, net sa min mooglik.

Trije tiidwurden mei trije ferskillende útkomsten

accept, ignore en reject binne net trije staveringen fan itselde idee. Se ferskille yn wat de klient mei in match docht en yn oft immen dat te witten komt.

ignore smyt de oerienkommende opsje stil fuort, wat jo wolle foar in ynstelling dy't jo bewust ferfongen hawwe. reject smyt it fuort en lit de klient kleie, wat jo wolle as de ôfwêzigens derfan yn in log sichtber wêze moat ynstee fan letter ûntdutsen te wurden. accept is de positive foarm, brûkt as jo in talittingslist bouwe ynstee fan yndividuele opsjes fuort te heljen.

Hokker tiidwurd jo ek brûke, de filters wurde tapast yn 'e folchoarder dêr't se ferskine, dus twa oerlaapjende regels jouwe in folchoarderôfhinklik resultaat dat heul dreech nei te sjen is. Hâld ien regel per bedoeling en set de measte spesifike tekst yn elk. As jo in talittingslist nedich binne, foarkom in pear accept-regels boppe in heap ignore-regels dy't op itselde delkomme. Dan kinne beoardielers it bestân fan boppe nei ûnderen lêze en it resultaat foarsizze, en dat is de iennige test dy't skaalet.

Kontrolearje de tapaste rûte en resolver, net it profyl

In filter dat yn it bestân korrekt liket, kin jo noch altyd efterlitte mei in tunnel dy't neat nuttich rûtet. Ferifiearje it effekt op it rinnende systeem, dêr't tawiisde opsjes al tapast of fuortsmyt binne:

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 earste twa regels fertelle jo oft de tawiisde standertrûte oankaam en hoefolle statyske ynfoerings oerlibbe hawwe. De resolver-query lit sjen hokker tsjinner de tunnelinterface eins brûkt, en dêr ferskynt meast in DNS-ferrassing. De lêste regel beantwurdet de iennige fraach dy't foar in brûker fan belang is.

Test beide rjochtingen wylst jo der binne. In regel dy't jo lokale ynternet wurkje lit mar de ynterne namme-oplossing stil brekt, slagget foar in oerflakkige kontrôle en falt by de earste echte taak, dus nim ien ynterne boarne en ien iepenbiere side op yn deselde test.

Skriuw de útsûndering op en wa't der eigner fan is

In filter is in útsûndering op it ûntwerp fan 'e operator, dus skriuw it op mei in reden en in kontrôlepunt. "Negearret tawiisde rûtes om de lokale standert te hâlden" is neisjenber; in bleate regel yn in profyl net, en de folgjende persoan sil it wiskje of mei giswurk útwreidzje.

Ferzje jildt hjir ek. It matchgedrach en de krekte akseptearre syntaksis binne byskave oer OpenVPN 2.4, 2.5 en 2.6, dus befêstigje it patroan tsjin 'e hânlieding foar de build dy't jo leverje, net tsjin in forumberjocht oer in âldere ferzje. De hânlieding fan OpenVPN 2.6 dokumintearret de opsje en syn matchregel.

Ta beslút, stim dy útsûndering ôf mei wa't de tsjinner beheart. In filter oan 'e kliïntkant dat in bewuste tsjinnerbelied tsjinsprekt is in stipe-ynsidint dat op 'e folgjende audit wachtet, en it is folle goedkeaper om it te regeljen foardat it profyl útstjoerd wurdt as neidat immen merkt dat de rûtes misse.

Relatearre artikelen