Waarom DNS stopt met werken nadat OpenVPN verbindt op Windows

De resolver antwoordt nog op een ping terwijl poort 53 nergens heen gaat. Controleer of block-outside-dns filtert en zorg dan voor een resolver die de tunnel kan bereiken.

Een ping naar de resolver van het kantoor krijgt nog antwoord nadat "OpenVPN" verbindt, en toch mislukt elke naamopzoeking. Het adres is bereikbaar terwijl de poort dat niet is, een combinatie die logisch is zodra je weet dat Windows DNS per adapter kan filteren. Met block-outside-dns in het profiel is dat filter de eerste verdachte en de routetabel is de verkeerde plek om te kijken. De twee tests hieronder scheiden de lagen in seconden.

Bereikbaar adres, dode poort

Een geslaagde ping bewijst dat de host draait en dat er een pad bestaat. Over de toestemming om poort 53 te bereiken zegt hij niets, omdat het bewuste filter op een andere laag werkt en aan de adapter hangt. Daarom kan dezelfde machine ICMP beantwoorden en elk verzoek naar hetzelfde adres weigeren. Voer beide tests in dezelfde sessie uit voordat je een configuratie wijzigt.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Dat paar is de diagnose. Gewoon verkeer naar het subnet blijft werken terwijl naamresolutie sterft, en mensen concluderen dat de server stuk is of dat DNS nooit is gepusht. Beide verklaringen zijn duur om te achtervolgen, en het bewijs wijst naar iets smallers. Bevestig het paar voordat je een instelling aanraakt.

De optie is een regel van het filterplatform

De OpenVPN-referentie beschrijft block-outside-dns als een beperking van Windows Filtering Platform die programma's verhindert DNS te bereiken op adapters buiten de tunnel. Ze dekt TCP en UDP poort 53. Omdat het filter in WFP leeft en niet in de gewone firewallregellijst, verandert een toestemmingsregel elders niet noodzakelijk de uitkomst. Daarom blijft het gangbare advies om DNS toe te staan mislukken.

De instelling kan uit het geïmporteerde profiel of van de server komen, en het bestand dat je laatst hebt bewerkt "is geen bewijs van wat de client heeft geladen". Lees de effectieve configuratie en het verbindingslog samen. De optie is ook Windows-specifiek, en haar als overdraagbaar behandelen levert advies op dat niet geldt.

Zoek de clientcomponent die de beperking bezit in plaats van meer regels toe te voegen. De eigenaar is het ding dat haar echt kan verwijderen.

Een filter is geen resolver

Verkeer buiten de tunnel blokkeren installeert geen werkende resolver erbinnen. De optie verwijdert een pad en laat de DNS-configuratie van de tunnel over aan wie het profiel heeft opgezet. Een profiel dat nooit een resolver pushte, heeft er nu helemaal geen.

Loop drie controles in volgorde na. Ten eerste, welke resolver de falende toepassing echt gebruikt. Ten tweede, of de client de VPN-DNS-instellingen heeft toegepast. Ten derde, welke interface het verkeer naar die resolver draagt.

  1. Resolver in gebruik: vergelijk Resolve-DnsName -Server <resolver-ip> <name> met de DNS-servers die ipconfig /all opsomt.
  2. VPN-DNS toegepast: bekijk de DNS-items van de tunneladapter in dezelfde uitvoer van ipconfig /all.
  3. Gebruikte interface: Find-NetRoute -RemoteIPAddress <resolver-ip> noemt de uitgaande interface voor die bestemming.

Een LAN-resolver wordt onder dit beleid ontwerpmatig onbereikbaar, zelfs terwijl ander LAN-verkeer werkt. Dat is de optie die haar werk doet. Als het ontwerp VPN-DNS nodig heeft, herstel dan de resolverregistratie en het tunnelpad; als split DNS met lokale uitzonderingen vereist is, moet de eigenaar van de configuratie die uitzonderingen op een ondersteunde manier uitdrukken.

Wat de optie niet dekt

Poort 53 is niet de hele naamresolutie. DNS over HTTPS en DNS over TLS gebruiken andere transporten, en sommige toepassingen draaien hun eigen resolverlogica ongeacht de systeeminstellingen. Een browser kan namen dus wel oplossen terwijl de opdrachtregel dat niet kan.

Behandel dat verschil als diagnostiek en niet als tegenspraak. Vergelijk de twee voordat je besluit dat de systeemresolver stuk is.

Houd de conclusie smal wanneer je haar opschrijft. Deze optie beperkt één transport op één platform, en de rest van het resolutiepad is een aparte ontwerpvraag met een eigen eigenaar.

Controleer de toestand voor en na het verbreken

Voer dezelfde opzoeking uit tijdens de verbinding en opnieuw nadat de eigenaar-client verbreekt. De eerste hoort te mislukken voor een externe resolver zolang de tunnel staat, en de tweede hoort te slagen zodra het filter is verwijderd. Als het na het verbreken nog steeds mislukt, is het filter niet opgeruimd.

ipconfig /displaydns
nslookup <name> <resolver-ip>

De clientdienst of de machine herstarten ruimt meestal een verouderd filter op. Dat bevestigt de diagnose zonder een blijvende oplossing te bewijzen. Noteer wat je zag, want een filter dat een verbreking overleeft doet het opnieuw, en de notitie is wat een bugrapport rechtvaardigt.

Pas na die controles is het zinvol de resolver te vervangen of het firewallbeleid opnieuw op te bouwen. Beide zijn grotere wijzigingen dan het bewijs ondersteunt.

Gerelateerde artikelen