Waarom naamopzoekingen mislukken over een gerouteerde OpenVPN-tunnel

Een host antwoordt op ping via het adres en faalt bij elke zoekactie op naam. De tunnel staat en de route bestaat, dus de natuurlijke conclusie is dat de VPN verkeerd is geconfigureerd. Een nuttiger conclusie is dat de zoekactie nooit routeerbaar was: een gerouteerde tunnel vervoert unicast-IP, terwijl de query een broadcast was die zocht naar een segment dat er aan de andere kant niet is. Zodra de laagmismatch zichtbaar is, sorteren de oplossingen zichzelf op kosten.

Mythe: de tunnel is stuk omdat namen falen

Het symptoom is overtuigend omdat alles boven de naamlaag werkt. Adressen worden gerouteerd, de interface staat, en de peer antwoordt op een ping. Wat faalde is een ontdekkingsmechanisme dat nooit een pad over een punt-naar-punt-verbinding had, en dat is een andere uitspraak dan een kapotte tunnel. Die twee uitspraken scheiden is het grootste deel van de diagnose.

Het als een tunnelfout behandelen leidt tot profielwijzigingen die niet kunnen helpen. Opties toevoegen, de versleuteling wijzigen of de client opnieuw installeren laat de broadcast precies waar die was.

Benoem het mechanisme dat faalde voordat je de oplossing benoemt. Een zoekactie via broadcast heeft een segment nodig, terwijl een zoekactie via een resolver een adres nodig heeft om te vragen.

Wat TUN vervoert en wat niet

Een TUN-apparaat is een IP-interface, en dat is wat het routeerbaar maakt. OpenVPN geeft de client een adres en een reeks routes, en vanaf dat moment stuurt de client datagrammen naar een peer. Niets in dat model creëert een gedeelde verbinding waar elke host elk frame hoort.

Ontdekkingsverkeer past helemaal niet in dat model. Oudere Windows-naamquery's, SSDP-aankondigingen en mDNS-verzoeken worden naar iedereen op een segment gestuurd in plaats van naar één bestemming. Een gerouteerde verbinding heeft geen «iedereen» om naartoe te sturen. Elk van die mechanismen veronderstelt een gedeeld medium.

De tunnel kan dus gezond zijn terwijl ontdekking volledig faalt. Die zin is degene om aan vast te houden wanneer iemand meldt dat de VPN plat ligt.

Bridging werkt door de grens weg te halen

Een TAP-apparaat vervoert frames, en een bridge koppelt het aan een echt LAN-segment. De client heeft dan een adres op dat segment en hoort het broadcastverkeer ervan. Daarom lijkt bridging het naamprobleem te genezen. Het maakt de client ook afhankelijk van dat segment voor adressering.

De genezing is het weghalen van de routeringsgrens, niet een nieuwe naamcapaciteit in de tunnel. Alles wat het segment broadcast, steekt nu ook de verbinding over.

Voor een klein lab is dat een eerlijke ruil. Over een verspreide beroepsbevolking zelden.

DNS en WINS pushen is de smallere reparatie

Geef de client een concrete plek om te vragen. dhcp-option DNS en dhcp-option DOMAIN wijzen interne namen naar een server die de zone kent, en een Windows-client die nog op NetBIOS vertrouwt kan op dezelfde manier een WINS-server krijgen. De tunnel blijft gerouteerd en het segment blijft waar het hoort.

Twee voorwaarden bepalen of dat werkt. De genoemde server moet voor de zone antwoorden, en de query moet door de tunnel zijn toegestaan.

Test de resolver vanaf de client en niet vanuit de shell van de server zelf. Een resolver die lokaal werkt zegt niets over wat de tunnel vervoert.

Zoek uit welke laag faalde

Ping eerst het adres, los dan de naam op en lees welke server antwoordde. Een negatief antwoord van een server die de zone niet host, ziet er anders uit dan een query die de machine nooit heeft verlaten. Een naam die wel oplost maar verbindingen weigert, is een heel derde probleem.

Multicast staat achter dezelfde muur. Een groep zoals 224.0.0.251 wordt standaard niet doorgestuurd over een gerouteerde tunnel, en een route voor de groep is niet genoeg zonder een multicast-bewust pad of een reflector op de LAN.