OpenVPN pull-filter matcht meer dan de route die je bedoelde

Je voegt één regel toe om je lokale standaardroute te behouden, en daarna bereikt de tunnel de interne DNS-server niet meer. De regel was pull-filter ignore "route", wat niet betekent "negeer deze route". Het betekent "gooi elke gepushte optie weg waarvan de tekst met die vijf letters begint", en op een normale server omvat dat route-gateway, route-metric en route-ipv6 samen met de routes zelf. De checklist hieronder is wat ik doorloop voordat ik een profiel aanraak dat iemand anders moet gebruiken.

Het filter geldt alleen voor gepushte opties

pull-filter werkt alleen op de optieregels die de server stuurt nadat de tunnel tot stand is gebracht, en op niets anders. Opties die in je lokale bestand staan worden er niet door beïnvloed, en applicatieverkeer ook niet. Als je hoopte een proces ervan te weerhouden de tunnel te gebruiken, is dit volledig het verkeerde gereedschap en geen enkele combinatie van filters zal dat doen.

Die reikwijdte is nuttig, want het betekent dat je de configuratie van de server met rust kunt laten en toch een deel ervan lokaal kunt weigeren. Het is ook een beperking die het waard is in de ticket te noteren: een filter verandert wat deze client accepteert, niet wat de server aanbiedt. Het heeft geen effect op andere gebruikers van hetzelfde profiel. Het overleeft ook geen overstap naar een andere client die de optie niet implementeert, wat het waard is om te weten voordat je er een workflow op bouwt.

Bevestig wat de server werkelijk stuurt voordat je het patroon schrijft. Bij hoge verbositeit print de client de gepushte optiestring die hij heeft ontvangen, en dat is de enige eerlijke bron voor de exacte tekst waarmee je vergelijkt:

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

Lees de gepushte regel als een lijst opties gescheiden door komma's, en let op dat optienamen en hun argumenten door spaties worden gescheiden. Je filtertekst wordt met die stroom vergeleken, daarom zijn spaties in de volgende stap zo belangrijk.

Overeenkomst is een prefix, dus spaties bepalen alles

De vergelijking is een tekenreeksprefix, geen geparseerde optienaam. Daarom matcht "route" zowel route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 als route-metric 100. Eén spatie aan het eind vernauwt het tot de familie die je waarschijnlijk bedoelde, en de volledige prefix vernauwt het verder tot een specifieke bestemming.

De laatste rij is degene die mensen tijdens split-tunnelwerk vangt. Je eigen resolver houden is een legitieme keuze, en het betekent dat elke interne naam nu afhangt van een resolver die de privézone niet kan zien. Dat is een gevolg dat je bewust accepteert, geen bijwerking die je in productie ontdekt.

Prefixmatching betekent ook dat een regel zich later stil kan uitbreiden. Wanneer de server een nieuwe optie toevoegt die met jouw tekst begint, begint je filter daarop van toepassing te worden zonder dat iemand je profiel bewerkt. Dat is de faalmodus waarop je moet ontwerpen, en de mitigatie is zoveel mogelijk van de optie matchen in plaats van zo weinig mogelijk.

Drie werkwoorden met drie verschillende uitkomsten

accept, ignore en reject zijn geen drie spellingen van hetzelfde idee. Ze verschillen in wat de client met een match doet en in of iemand erachter komt.

ignore gooit de matchende optie stil weg, wat je wilt voor een instelling die je bewust hebt vervangen. reject gooit hem weg en laat de client klagen, wat je wilt wanneer de afwezigheid in een log zichtbaar moet zijn in plaats van later ontdekt te worden. accept is de positieve vorm, gebruikt wanneer je een toelatingslijst opbouwt in plaats van afzonderlijke opties te verwijderen.

Welk werkwoord je ook gebruikt, de filters worden toegepast in de volgorde waarin ze verschijnen, dus twee overlappende regels geven een volgordeafhankelijk resultaat dat zeer moeilijk te beoordelen is. Houd één regel per bedoeling en zet de meest specifieke tekst in elk. Als je een toelatingslijst nodig hebt, geef dan de voorkeur aan een paar accept-regels boven een berg ignore-regels die op hetzelfde neerkomen. Dan kunnen beoordelaars het bestand van boven naar beneden lezen en het resultaat voorspellen, en dat is de enige test die schaalt.

Controleer de toegepaste route en resolver, niet het profiel

Een filter dat er in het bestand correct uitziet, kan je nog steeds achterlaten met een tunnel die niets nuttigs routeert. Verifieer het effect op het draaiende systeem, waar gepushte opties al zijn toegepast of weggegooid:

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 eerste twee regels vertellen je of de gepushte standaardroute is aangekomen en hoeveel statische vermeldingen het hebben overleefd. De resolver-query laat zien welke server de tunnelinterface werkelijk gebruikt, en daar duikt meestal een DNS-verrassing op. De laatste regel beantwoordt de enige vraag die voor een gebruiker telt.

Test beide richtingen terwijl je er bent. Een regel die je lokale internet laat werken maar stilletjes de interne naamresolutie breekt, slaagt voor een oppervlakkige controle en faalt bij de eerste echte taak, dus neem één interne bron en één openbare site op in dezelfde test.

Leg de uitzondering vast en wie hem bezit

Een filter is een uitzondering op het ontwerp van de operator, dus schrijf hem op met een reden en een beoordelingspunt. "Negeert gepushte routes om de lokale standaard te behouden" is beoordeelbaar; een kale regel in een profiel niet, en de volgende persoon zal hem verwijderen of met giswerk uitbreiden.

De versie telt hier ook. Het matchgedrag en de exacte geaccepteerde syntaxis zijn verfijnd in OpenVPN 2.4, 2.5 en 2.6, dus bevestig het patroon aan de hand van de handleiding van de build die je levert en niet aan de hand van een forumbericht over een oudere versie. De OpenVPN 2.6-handleiding documenteert de optie en de matchregel.

Ten slotte, stem de uitzondering af met degene die de server beheert. Een filter aan de clientzijde dat een bewust serverbeleid tegenspreekt, is een supportincident dat op de volgende audit wacht, en het is veel goedkoper om het te regelen voordat het profiel uitgaat dan nadat iemand merkt dat de routes ontbreken.