Wat OpenVPN route-nopull de server echt verhindert te pushen

Je zette route-nopull in een cliëntprofiel om te voorkomen dat de tunnel je standaardroute opslokt, en nu is het kantoorsubnet onbereikbaar terwijl de cliënt nog steeds zegt dat hij verbonden is. Beide waarnemingen kloppen, en er is niets misgegaan. De vlag vertelt de cliënt de routes en DHCP-vermeldingen over te slaan die de server pusht, een smallere opdracht dan de meeste mensen verwachten als ze hem toevoegen. Wat overblijft is een werkende tunnel zonder mening over welke bestemmingen hem moeten gebruiken.

Die kloof is de hele beslissing waarover dit artikel gaat. Ofwel de server beschrijft het netwerk, ofwel de cliënt doet dat, en de vlag geeft die taak aan de cliënt zonder er iets van voor je te doen.

Wat de vlag uitschakelt bij het verbinden

Een OpenVPN-cliënt die trekt, neemt na authenticatie normaal een pakket van de server over: routes, een omleiding van de standaardgateway, DNS-servers en een paar afstemmingsrichtlijnen. Met route-nopull van kracht accepteert de cliënt nog steeds de sessie, verifieert nog steeds certificaten, onderhandelt nog steeds over cijfers en keepalives, en brengt nog steeds de interface omhoog. Wat hij laat vallen is de toepassing van gepushte route-regels en gepushte dhcp-option-regels, DNS inbegrepen.

De verwarring komt van een groene indicator naast een dode toepassing. De tunnel bestaat; de toewijzing van bestemmingen aan die tunnel niet. Niets in het statuspaneel van de cliënt onderscheidt ‘verbonden en routerend’ van ‘verbonden en inactief’, omdat beide vanuit de tunnel bezien dezelfde toestand zijn.

Waarom een levende tunnel toch niets kan routeren

De interface verschijnt met zijn eigen adres en heeft op een punt-tot-puntverbinding vaak niets specifieker dan een hostroute naar de peer. Een privésubnet wordt pas bereikbaar als een of andere route met de juiste prefix naar die interface wijst, en met pushen uitgeschakeld komt die route nooit aan. Het gedownloade profiel kan meestal ook niet helpen, omdat het is geschreven in de veronderstelling dat de server precies deze informatie zou leveren. Daarom kan de interface gezond lijken terwijl het subnet donker blijft.

Het profiel lezen bewijst dus heel weinig. Lees in plaats daarvan de actieve toestand, op de verbonden machine:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Een adres zonder subnetroute in het tweede commando is de signatuur van dit probleem. Het derde commando beantwoordt dan de vraag die gebruikers werkelijk aangaat, omdat het de interface meldt die de kernel voor een bepaalde bestemming zou kiezen in plaats van de lijst waarvan je hoopte dat hij die zou gebruiken. Als het via je fysieke verbinding antwoordt, zit de tunnel helemaal niet in het pad.

Naamresolutie mislukt om een verwante reden, niet om een aparte. Gepushte dhcp-option DNS-vermeldingen worden door dezelfde vlag overgeslagen, dus zoekopdrachten naar interne hosts gaan naar welke resolver het lokale netwerk ook heeft geleverd. Die resolver heeft geen zone voor het kantoor, dus de zoekopdracht mislukt of geeft een openbaar antwoord, en de storing lijkt een serverprobleem terwijl het een cliëntconfiguratieprobleem is. Een adres vóór een naam testen is wat de twee scheidt.

Kiezen tussen de vlag en een prefixfilter

De twee opties lossen verschillende vormen van dezelfde klacht op, en een slechte keuze is wat de toestand verbonden-maar-nutteloos oplevert. De ene vervangt het gepushte beleid volledig, de andere bewerkt het per prefix. De tabel geeft de korte versie, en de alinea erna behandelt het deel dat mensen verrast.

pull-filter is een prefixvergelijker met drie werkwoorden, dus hij kan een familie regels accepteren, ze stil negeren of de verbinding ronduit weigeren wanneer een prefix opduikt. Dat laatste gedrag is het weten waard: een weigeringsregel maakt van een beleidsmeningsverschil een mislukte handshake in plaats van een stille weglating. De OpenVPN 2.6-handleiding somt de geaccepteerde prefixen en de exacte betekenis van elk werkwoord op.

Een gebruikelijke middenweg is alleen redirect-gateway te weigeren en de kantoerroutes en DNS zoals bedoeld te laten aankomen. Dat houdt het pushen werkend voor de delen die de server beter begrijpt dan jij, terwijl het de ene regel voorkomt die je standaardroute zou overnemen.

Routes en een resolver met de hand toevoegen

Als je de vlag houdt, moet het profiel zeggen wat de server gezegd zou hebben. Cliëntzijde-route-richtlijnen worden toegepast nadat de verbinding tot stand is gebracht, dus ze werken naast de vlag in plaats van erdoor te worden geblokkeerd. Zet ze in het profiel, niet in een interactieve opdrachtregel, anders reproduceert de volgende herverbinding de werkende toestand niet.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

De DNS-regel staat op een ongemakkelijke plek: het is een cliëntzijde-richtlijn, maar sommige cliënten passen hem alleen toe via de DNS-integratie van het platform, die hem kan overschrijven wanneer de verbinding verandert. Op een systemd-host is het voorspelbaarder om de resolver rechtstreeks op de tunnelinterface te zetten dan te hopen dat de cliënt de prioriteitsstrijd wint:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Het routeringsdomein is even belangrijk als het adres. Zonder dat kunnen zoekopdrachten naar openbare namen ook naar de interne resolver gaan, en elke interne resolver die recursie weigert, breekt het browsen terwijl de privézone blijft werken. Met dat domein worden alleen namen onder dat achtervoegsel naar de tunnelresolver gerouteerd en volgt al het andere de fysieke verbinding.

Het resultaat controleren: adres, naam en het buitenpad

Drie tests scheiden de mogelijke storingen. Haal het privéadres op via IP, dan dezelfde host via naam, dan een gewone openbare site. Een werkende IP met een mislukkende naam wijst op de resolver; een mislukkende IP met een werkende naam wijst op routering; falen beide, dan zit de tunnel meestal niet in het pad.

Kijk daarna naar buiten in plaats van naar binnen. De eigen route van het tunneleindpunt moet de verandering overleven, en elke blokkerende storing moet tot de tunnel beperkt blijven zonder het eindpunt te vangen. Een cliënt die blijft browsen nadat de tunnel wegvalt, is een beleidsprobleem, geen routeringsprobleem, en het zal in geen van de drie tests hierboven opduiken.

Schrijf de definitieve lijst in de documentatie van het profiel: de routes, de resolver, de domeinen en de reden waarom elk bestaat. Een herverbinding die dezelfde tabel reproduceert, is het enige bewijs dat het lokale beleid compleet is. Als toepassingen nog steeds falen terwijl de tunnel staat en alle drie de tests slagen, is de volgende plek om te kijken de klasse van verbonden-maar-offline-problemen in plaats van certificaten die al zijn geverifieerd.