Je split-tunnel bereikt de app, maar niet de DNS-server ervan

Het subnet van de applicatie routeren is het voor de hand liggende deel van een split-tunnel, en het is niet het hele werk. De resolver staat vaak op een ander adres dan de applicatie die hij bedient, dus een werkende tunnel kan de opzoeking er nog buiten laten. Een profiel dat 10.80.0.0/16 en niets anders draagt, stuurt de query voor 10.90.0.53 via de lokale interface naar buiten, waar geen privézone bestaat. Voeg het pad naar de resolver toe en kijk dan naar de tweede helft van het probleem: welke server de client werkelijk kiest.

De mythe: één route dekt de hele dienst

Een split-tunnel is een lijst met bestemmingen die door de verbinding gaan, geen beschrijving van een dienst. Het subnet van de applicatie en het adres van de resolver zijn twee bestemmingen, en een profiel kan de ene zonder de andere dragen. Als dat gebeurt, is de applicatie via het adres bereikbaar terwijl de naam faalt, wat meer op een DNS-storing lijkt dan op een routeringsgat.

Het subnet rond de resolver is ook niet automatisch gedekt. Een hostroute naar één adres is genoeg voor die resolver en opent de buren niet. Dat is het punt van een hostroute: smal van opzet, en makkelijk te vergeten wanneer de volgende dienst op hetzelfde subnet verschijnt.

Drie dingen moeten kloppen wil de opzoeking werken: de client routeert het adres van de resolver door de tunnel, de gateway accepteert en stuurt dat verzoek door, en de resolver accepteert de bron die hij ontvangt. Een antwoord moet ook via de afgesproken weg terugkomen. Ontbreekt één daarvan, dan is het symptoom identiek, en daarom loont het de adrestabel op te schrijven voordat je een configuratie aanraakt.

Bepaal welke adressen het profiel moet dragen

Noem de bestemmingen in volgorde: het netwerk van de applicatie, het adres van de resolver en het openbare eindpunt dat de tunnel zelf beëindigt. De derde mag nooit de tunnel in gerouteerd worden, omdat de buitenste verbinding een pad nodig heeft dat bestaat voordat de tunnel bestaat.

Neem zowel UDP als TCP op voor DNS, omdat van implementaties wordt verwacht dat ze TCP naast UDP ondersteunen, en een geblokkeerd TCP-pad levert trage, gedeeltelijke fouten op in plaats van schone. Wordt de privézone ook via IPv6 bediend, dan gebruikt de gelijkwaardige hostuitzondering een IPv6-adres en -prefix en is het een aparte vermelding.

Noteer wat het profiel al dekt voordat je iets toevoegt. Een dubbele route is onschadelijk, maar een onverwachte bestaande route zegt dat het profiel is ontworpen voor een ander adresplan dan het jouwe.

Voeg de hostroute toe via de eigenaar van de verbinding

Voor een lokaal beheerd native Windows-profiel hoort de route bij de verbinding en niet bij de globale routingtabel van de machine. Bekijk de toevoeging eerst als voorbeeld en pas die daarna toe met dezelfde scope die het profiel gebruikt.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

Het eerste commando toont de wijziging als voorbeeld zonder iets te installeren, en het tweede somt de routes op die het profiel nu draagt. Microsofts referentie voor Add-VpnConnectionRoute documenteert de scopes per gebruiker en voor alle gebruikers; een profiel voor alle gebruikers heeft zijn eigen scopeparameter nodig, en een commando per gebruiker tegen een profiel voor alle gebruikers mislukt of belandt op de verkeerde plek.

Wanneer het profiel wordt beheerd of van een leveranciersclient komt, hoort de wijziging bij die eigenaar. Een permanente systeemroute boven op een verbindingsbeleid stapelen werkt tot het beleid opnieuw wordt toegepast en de route weg is, wat meestal tijdens een supportgesprek gebeurt en niet tijdens het testen. Die fout is stil: de route verdwijnt, de naam lost niet meer op en niemand verbindt de twee gebeurtenissen. Zet de wijziging in het eigen record van de eigenaar, zodat de volgende hertoepassing hem draagt in plaats van wist.

Maak na het toepassen de verbinding opnieuw in plaats van aan te nemen dat de route werkt. Routewijzigingen op een actieve verbinding worden niet altijd opgepikt, en opnieuw verbinden reproduceert ook de toestand die je gebruikers werkelijk zullen hebben.

Controleer welke resolver de client werkelijk heeft gebruikt

Een route bepaalt pakketten die aan de resolver zijn geadresseerd. Hij beslist niet welke namen daarheen moeten, en die selectie is een apart mechanisme. Op Windows kunnen effectieve naamruimteregels per domein een resolver kiezen, terwijl de DNS-instellingen van het profiel een standaard leveren. Die twee lagen kunnen het oneens zijn zonder enige fout te produceren, en daarom is een directe query maar de helft van het bewijs.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

Het eerste commando drukt het geldende naamruimtebeleid af, en het tweede vraagt de privéresolver rechtstreeks naar de naam van de applicatie. Een direct antwoord bewijst dat het pad en de resolver werken; het bewijst niet dat de eigen opzoeking van de applicatie die server koos. Vergelijk het met een normale opzoeking van dezelfde naam en met het antwoord dat de applicatie ontvangt.

Houd rekening met caches en met beveiligde DNS op browserniveau, die de systeemresolver volledig kan omzeilen voor namen die een gebruiker heeft getypt. Een zoeksuffix is een ander dwaalspoor: het breidt een korte naam uit tot een volledig gekwalificeerde en heeft niets te maken met welke server antwoordt.

Sluit af met opnieuw verbinden en de normale opzoeking te herhalen, en bevestig dan dat gewoon browsen nog steeds zijn goedgekeurde beleid volgt. De privéresolver vervangen door een openbare zodat een ongerelateerde naam oplost is geen reparatie, en het verplaatst privéqueries stilletjes naar een plek waar ze nooit hoorden te komen.