OpenVPN se pull-filter pas meer as net die roete wat jy in gedagte het
pull-filter vergelyk jou teks as 'n voorvoegsel teen gestuurde opsies, so route vang ook route-gateway en route-ipv6. Kyk eers na die werkwoorde, dan na die roetes.
Jy voeg een reël by om jou plaaslike verstekroete te behou, en daarna bereik die tonnel nie meer die interne DNS-bediener nie. Die reël was pull-filter ignore "route", wat nie "ignoreer hierdie roete" beteken nie. Dit beteken "laat vaar elke gestuurde opsie wie se teks met daardie vyf letters begin", en op 'n normale bediener sluit dit route-gateway, route-metric en route-ipv6 saam met die roetes self in. Die kontrolelys hieronder is wat ek loop voordat ek aan 'n profiel raak wat iemand anders moet gebruik.
Die filter geld net vir gestuurde opsies
pull-filter werk op die opsiereëls wat die bediener stuur nadat die tonnel gevestig is, en op niks anders nie. Opsies wat in jou plaaslike lêer geskryf is, word nie daardeur geraak nie, en toepassingverkeer ook nie. As jy gehoop het om 'n proses te keer om die tonnel te gebruik, is dit heeltemal die verkeerde instrument en geen kombinasie van filters sal dit regkry nie.
Daardie omvang is nuttig, want dit beteken jy kan die bediener se konfigurasie alleen los en tog 'n deel daarvan plaaslik weier. Dit is ook 'n beperking wat die moeite werd is om in die kaartjie te noem: 'n filter verander wat hierdie kliënt aanvaar, nie wat die bediener bied nie. Dit het geen uitwerking op ander gebruikers van dieselfde profiel nie. Dit oorleef ook nie 'n oorskuif na 'n ander kliënt wat die opsie nie implementeer nie, wat die moeite werd is om te weet voordat jy 'n werkvloei daarop bou.
Bevestig wat die bediener werklik stuur voordat jy die patroon skryf. By 'n hoë breedsprakigheid druk die kliënt die gestuurde opsiereël wat hy ontvang het, en dit is die enigste eerlike bron vir die presiese teks waarteen jy pas:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn
Lees die gestuurde reël as 'n lys opsies wat deur kommas geskei word, en let op dat opsiename en hul argumente deur spasies geskei word. Jou filterteks word teen daardie stroom vergelyk, en daarom maak witruimte so baie saak in die volgende stap.
Passing is 'n voorvoegsel, so witruimte is die hele speletjie
Die vergelyking is 'n stringvoorvoegsel, nie 'n ontlede opsienaam nie. "route" pas dus op route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 en route-metric 100. Een bykomende spasie agteraan vernou dit tot die familie wat jy waarskynlik bedoel het, en die volle voorvoegsel vernou dit verder tot 'n spesifieke bestemming.
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
Die laaste ry is die een wat mense tydens split-tonnel-werk vang. Om jou eie oplosser te hou is 'n wettige keuse, en dit beteken elke interne naam hang nou van 'n oplosser af wat nie die private sone kan sien nie. Dit is 'n gevolg om doelbewus te aanvaar, nie 'n newe-effek om in produksie te ontdek nie.
Voorvoegselpassing beteken ook dat 'n reël later stilweg kan verbreed. Wanneer die bediener 'n nuwe opsie byvoeg wat met jou teks begin, begin jou filter daarop toe te pas sonder dat iemand jou profiel wysig. Dit is die foutmodus waarteen jy moet ontwerp, en die versagting is om so veel van die opsie as moontlik te pas eerder as so min as moontlik.
Drie werkwoorde met drie verskillende uitkomste
accept, ignore en reject is nie drie spellings van dieselfde idee nie. Hulle verskil in wat die kliënt met 'n passing doen en in of iemand dit ooit uitvind.
ignore laat vaar die passende opsie stilweg, wat is wat jy wil hê vir 'n instelling wat jy doelbewus vervang het. reject laat vaar dit en laat die kliënt kla, wat is wat jy wil hê wanneer die afwesigheid daarvan in 'n log sigbaar moet wees eerder as om later ontdek te word. accept is die positiewe vorm, gebruik wanneer jy 'n toelaatlys opbou eerder as om individuele opsies te verwyder.
Watter werkwoord jy ook al gebruik, die filters word toegepas in die orde waarin hulle verskyn, so twee oorvleuelende reëls lewer 'n orde-afhanklike resultaat wat baie moeilik is om na te gaan. Hou een reël per bedoeling en sit die mees spesifieke teks in elkeen. As jy 'n toelaatlys nodig het, verkies 'n klein aantal accept-reëls bo 'n hoop ignore-reëls wat op dieselfde neerkom. Resensente kan dan die lêer van bo na onder lees en die resultaat voorspel, en dit is die enigste toets wat skaal.
Kontroleer die toegepaste roete en oplosser, nie die profiel nie
'n Filter wat in die lêer korrek lyk, kan jou steeds met 'n tonnel laat wat niks nuttigs routeer nie. Verifieer die uitwerking op die lopende stelsel, waar gestuurde opsies reeds toegepas of laat vaar is:
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/
Die eerste twee reëls vertel jou of die gestuurde verstekroete aangekom het en hoeveel statiese inskrywings oorleef het. Die oplosser-navraag wys watter bediener die tonnelkoppelvlak werklik gebruik, en dit is gewoonlik waar 'n DNS-verrassing opduik. Die laaste reël antwoord die enigste vraag wat vir 'n gebruiker saak maak.
Toets albei rigtings terwyl jy daar is. 'n Reël wat jou plaaslike internet laat werk maar stilweg interne naamoplossing breek, slaag 'n oppervlakkige toets en faal die eerste regte taak, so sluit een interne hulpbron en een openbare werf in dieselfde toets in.
Teken die uitsondering op en wie dit besit
'n Filter is 'n uitsondering op die operateur se ontwerp, so skryf dit neer met 'n rede en 'n hersieningspunt. "Ignoreer gestuurde roetes om plaaslike verstek te behou" is hersienbaar; 'n kaal reël in 'n profiel is nie, en die volgende persoon sal dit uitvee of met raaiskote uitbrei.
Weergawe maak hier ook saak. Die passinggedrag en die presiese aanvaarde sintaksis is verfyn oor OpenVPN 2.4, 2.5 en 2.6, so bevestig die patroon teen die handleiding vir die bou wat jy verskeep, eerder as teen 'n forumplasing oor 'n ouer weergawe. Die OpenVPN 2.6-handleiding dokumenteer die opsie en sy passingreël.
Laastens, stem die uitsondering saam met wie ook al die bediener bestuur. 'n Kliëntkant-filter wat 'n doelbewuste bedienerbeleid weerspreek, is 'n ondersteuningsvoorval wat op die volgende oudit wag, en dit is baie goedkoper om dit te besleg voordat die profiel verskeep word as nadat iemand agterkom die roetes ontbreek.