Behoud privéroutes en laat de omleiding vallen: OpenVPN gesplitste tunnel

De tunnel komt op, de toepassing laadt, en dan begint al het andere op de laptop zich vreemd te gedragen. Dat is de gebruikelijke vorm van een beleid alleen voor privénetwerken dat is uitgevoerd door één regel te verwijderen. Een gepushte standaardroute verwijderen verandert wel waar het verkeer heen gaat, maar het zegt niet waar het verkeer in plaats daarvan heen moet, en het raakt naamresolutie helemaal niet. Een beleid heeft twee positieve helften nodig voordat het te testen is.

De omleiding verwijderen is maar de helft van de wijziging

Een omleiding van de volledige tunnel en een beleid alleen voor privénetwerken verschillen in wat ze over de wereld beweren. De omleiding claimt elke bestemming, terwijl het privébeleid een lijst claimt en de rest met rust laat. Het claimen verwijderen zonder de lijst te schrijven levert een client op die niets buiten het LAN bereikt, wat op een routeringsfout lijkt in plaats van op een gat in het beleid. Schrijf de lijst voordat je de claim verwijdert, en dan doet de volgorde van die twee stappen er niet meer toe.

Beide helften zijn vereisten en geen standaardwaarden. Privéprefixen moeten de tunnel in, en gewone bestemmingen moeten het pad houden dat ze voor de verbinding hadden.

Als een organisatie de volledige tunnel verplicht stelt, geldt niets hiervan. Het ontwerp alleen voor privénetwerken hoort bij implementaties waar gesplitste routering is goedgekeurd.

pull-filter is een overeenkomst, geen schakelaar

De richtlijn pull-filter verwijdert gepushte opties waarvan de namen met een prefix overeenkomen, en dat is alles wat het doet. De omleiding negeren laat elke andere gepushte optie staan, wat meestal is wat je wilt: routes, DNS-instellingen en de waarde van de route-gateway komen nog steeds aan. Het kan ook geen richtlijn verwijderen die in het lokale profiel staat, omdat filteren geldt voor wat de server pusht.

Weersta de verleiding om elke optie die met route begint te negeren. Dat patroon gooit ook de privéroutes weg die de verbinding nodig heeft, en het kan gateway-informatie verliezen waarvan de tunnel afhankelijk is.

route-nopull is een bredere beslissing dan het lijkt. Het weerhoudt de client ervan gepushte routes en DHCP-achtige opties als groep te accepteren, wat een ander beleid is dan één optie eruit filteren.

Schrijf de routelijst van de toepassing naar buiten

Begin bij wat de gebruiker werkelijk opent, en voeg dan de ondersteunende delen toe. Een toepassing op 10.60.20.15 impliceert het eigen subnet 10.60.0.0/16, en een privénaam impliceert de resolver die erop antwoordt. Een gebruiker die één toepassing vroeg heeft dus twee bestemmingen en één DNS-beslissing nodig. Alles voorbij die lijst valt door de opzet buiten scope, en dat is wat het beleid controleerbaar houdt.

Op een samenwerkende server worden dat twee gepushte routes, en geen van beide is een omleiding. Behoud de tunneltopologie en de waarden van de route-gateway die de bestaande dienst levert.

Als alleen sommige gebruikers dit beleid nodig hebben, pas het dan per client of per groep toe. Het routeren van iedereen aanpassen om de eis van één team op te lossen is de manier waarop een gesplitste tunnel een storing wordt.

Laat DNS hetzelfde pad volgen

Een route naar de resolver is geen resolverbeleid. Op een systemd-resolved-client is het semantische resultaat een routeringsdomein voor de privénaamruimte dat naar de interne resolver wijst, en dat is wat ervoor zorgt dat alleen die namen hem gebruiken. Een Windows-client heeft in plaats daarvan zijn eigen mechanisme voor naamruimtebeleid nodig. Een DNS-serverregel in het profiel installeert geen van beide vanzelf.

Controleer wat het besturingssysteem heeft gekozen in plaats van wat het profiel heeft gevraagd. Op Linux toont resolvectl status het domein en de server per verbinding; op Windows is de naamruimtebeleidstabel het gelijkwaardige bewijs.

Houd de resolver bereikbaar via de tunnel, anders wijst het beleid naar een adres dat niet kan worden bevraagd. Een resolveradres dat de tunnel niet bereikt, verandert een werkend beleid in een time-out.

Verifieer beide helften bij een herverbinding

Verbind de client opnieuw na de wijziging en bekijk de effectieve route naar een privéadres en naar een openbaar adres. Los daarna een privénaam en een openbare naam op en bevestig dat elk de bedoelde resolver gebruikte. Dat een openbare website laadt, bewijst alleen de tweede helft, en dat is de helft die meestal per ongeluk werkt.

Leg het afgeronde beleid in één zin vast: deze prefixen en namen gebruiken deze verbinding, al het andere volgt het lokale pad. Houd het dan in het profiel in plaats van na elke aanmelding adapterinstellingen te repareren.