El teu túnel dividit arriba a l’aplicació però no al seu servidor DNS
Un túnel dividit pot encaminar la subxarxa de l’aplicació i tot i així deixar caure el resolutor del costat. Afegeix la ruta de l’amfitrió i després comprova quin servidor tria realment el Windows.
Encaminar la subxarxa de l’aplicació és la part òbvia d’un túnel dividit, i no és tota la feina. El resolutor sovint se situa en una adreça diferent de l’aplicació a què serveix, de manera que un túnel que funciona pot deixar la consulta fora. Un perfil que porta 10.80.0.0/16 i res més envia la consulta de 10.90.0.53 per la interfície local, on no existeix cap zona privada. Afegeix el camí del resolutor i després mira l’altra meitat del problema: quin servidor tria realment el client.
El mite: una ruta cobreix tot el servei
Un túnel dividit és una llista de destinacions que passen per la connexió, no una descripció d’un servei. La subxarxa de l’aplicació i l’adreça del resolutor són dues destinacions, i un perfil pot portar-ne una sense l’altra. Quan passa això, l’aplicació és accessible per adreça mentre el seu nom falla, cosa que sembla una fallada de DNS més que no pas un buit d’encaminament.
La subxarxa que envolta el resolutor tampoc no queda coberta automàticament. Una ruta d’amfitrió a una sola adreça n’hi ha prou per a aquell resolutor i no obre els seus veïns. Aquest és el sentit d’una ruta d’amfitrió: estreta per disseny i fàcil d’oblidar quan el servei següent apareix a la mateixa subxarxa.
Tres coses s’han de complir perquè la consulta funcioni: el client encamina l’adreça del resolutor pel túnel, la passarel·la admet i reenvia aquesta petició, i el resolutor accepta la font que rep. La resposta també ha de tornar pel camí acordat. Si en falta una, el símptoma és idèntic, i per això val la pena escriure la taula d’adreces abans de tocar cap configuració.
Determineu quines adreces ha de portar el perfil
Llista les destinacions per ordre: la xarxa de l’aplicació, l’adreça del resolutor i el punt final públic que acaba el túnel mateix. La tercera no s’ha d’encaminar mai dins del túnel, perquè la connexió exterior necessita un camí que existeixi abans que el túnel.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Inclou tant UDP com TCP per al DNS, ja que s’espera que les implementacions admetin TCP a més d’UDP, i un camí TCP bloquejat produeix fallades lentes i parcials en lloc de netes. Si la zona privada també se serveix per IPv6, l’excepció d’amfitrió equivalent fa servir una adreça i un prefix IPv6 i és una entrada a part.
Anota què cobreix ja el perfil abans d’afegir res. Una ruta duplicada és inofensiva, però una ruta existent inesperada et diu que el perfil es va dissenyar per a un pla d’adreces diferent del que t’han donat.
Afegeix la ruta d’amfitrió a través del propietari de la connexió
En un perfil natiu del Windows gestionat localment, la ruta pertany a la connexió i no a la taula d’encaminament global de la màquina. Previsualitza primer l’addició i després aplica-la amb el mateix abast que fa servir el perfil.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
La primera ordre previsualitza el canvi sense instal·lar res, i la segona llista les rutes que el perfil porta ara. La referència d’Add-VpnConnectionRoute de Microsoft documenta els àmbits per usuari i per a tots els usuaris; un perfil per a tots els usuaris necessita el seu propi paràmetre d’àmbit, i una ordre per usuari contra un perfil per a tots els usuaris falla o acaba al lloc equivocat.
Quan el perfil és gestionat o prové d’un client de proveïdor, el canvi pertany a aquell propietari. Apilar una ruta de sistema permanent sobre una política de connexió funciona fins que la política es torna a aplicar i la ruta desapareix, cosa que sol passar durant una trucada de suport i no durant les proves. Aquesta fallada és silenciosa: la ruta desapareix, el nom deixa de resoldre’s i ningú no relaciona els dos fets. Posa el canvi al registre propi del propietari perquè la propera reaplicació el porti en lloc d’esborrar-lo.
Després d’aplicar-lo, torna a connectar el perfil en lloc de suposar que la ruta ha pres efecte. Els canvis de ruta en una connexió activa no sempre es recullen, i tornar a connectar també reprodueix l’estat que els teus usuaris tindran realment.
Comprova quin resolutor ha fet servir realment el client
Una ruta controla els paquets adreçats al resolutor. No decideix quins noms s’hi han d’enviar, i aquesta selecció és un mecanisme a part. Al Windows, les regles efectives d’espai de noms poden triar un resolutor per domini, mentre que la configuració DNS del perfil en dona un de predeterminat. Aquestes dues capes es poden contradir sense produir cap error, i per això una consulta directa només és la meitat de la prova.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
La primera ordre imprimeix la política d’espai de noms vigent, i la segona demana directament al resolutor privat el nom de l’aplicació. Una resposta directa demostra que el camí i el resolutor funcionen; no demostra que la consulta pròpia de l’aplicació hagi triat aquell servidor. Compara-la amb una consulta normal del mateix nom i amb la resposta que rep l’aplicació.
Tingues en compte les memòries cau i el DNS segur del navegador, que pot saltar-se del tot el resolutor del sistema per als noms que ha escrit un usuari. Un sufix de cerca és una altra pista falsa: amplia un nom curt a un de completament qualificat i no té res a veure amb quin servidor respon.
Acaba tornant a connectar i repetint la consulta normal, i després confirma que la navegació ordinària encara segueix la política aprovada. Substituir el resolutor privat per un de públic perquè resolgui un nom no relacionat no és cap solució, i mou en silenci les consultes privades allà on mai no havien d’anar.