Tunelul tău divizat ajunge la aplicație, dar nu la serverul ei DNS

Rutarea subrețelei aplicației este partea evidentă a unui tunel divizat și nu este toată munca. Resolverul stă adesea la o altă adresă decât aplicația pe care o deservește, așa că un tunel funcțional poate lăsa căutarea în afara lui. Un profil care transportă 10.80.0.0/16 și nimic altceva trimite interogarea pentru 10.90.0.53 prin interfața locală, unde nu există nicio zonă privată. Adaugă calea către resolver, apoi uită-te la a doua jumătate a problemei: ce server alege de fapt clientul.

Mitul: o singură rută acoperă tot serviciul

Un tunel divizat este o listă de destinații care trec prin conexiune, nu o descriere a unui serviciu. Subrețeaua aplicației și adresa resolverului sunt două destinații, iar un profil poate purta una fără cealaltă. Când se întâmplă asta, aplicația este accesibilă prin adresă în timp ce numele ei eșuează, ceea ce arată ca o defecțiune DNS, nu ca o lipsă de rutare.

Nici subrețeaua din jurul resolverului nu este acoperită automat. O rută către gazdă pentru o singură adresă este suficientă pentru acel resolver și nu deschide vecinii săi. Acesta este sensul unei rute către gazdă: îngustă prin proiectare și ușor de uitat când următorul serviciu apare în aceeași subrețea.

Trei lucruri trebuie să fie valabile pentru ca căutarea să funcționeze: clientul rutează adresa resolverului prin tunel, gateway-ul acceptă și transmite acea cerere, iar resolverul acceptă sursa pe care o primește. Și răspunsul trebuie să se întoarcă pe calea convenită. Dacă lipsește oricare, simptomul este identic, de aceea merită să scrii tabelul de adrese înainte de a atinge o configurație.

Stabilește ce adrese trebuie să transporte profilul

Enumeră destinațiile în ordine: rețeaua aplicației, adresa resolverului și punctul final public care încheie tunelul însuși. Al treilea nu trebuie niciodată rutat în tunel, pentru că conexiunea exterioară are nevoie de o cale care există înainte de tunel.

Include atât UDP, cât și TCP pentru DNS, fiindcă de la implementări se așteaptă să suporte TCP pe lângă UDP, iar o cale TCP blocată produce eșecuri lente și parțiale în loc de unele curate. Dacă zona privată este deservită și prin IPv6, excepția de gazdă echivalentă folosește o adresă și un prefix IPv6 și este o intrare separată.

Notează ce acoperă deja profilul înainte de a adăuga ceva. O rută duplicată este inofensivă, dar o rută existentă neașteptată îți spune că profilul a fost proiectat pentru un alt plan de adrese decât cel primit.

Adaugă ruta către gazdă prin proprietarul conexiunii

Pentru un profil Windows nativ administrat local, ruta aparține conexiunii și nu tabelului de rutare global al mașinii. Previzualizează mai întâi adăugarea, apoi aplică-o cu același domeniu de aplicare pe care îl folosește profilul.

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

Prima comandă previzualizează schimbarea fără a instala nimic, iar a doua listează rutele pe care profilul le transportă acum. Referința Add-VpnConnectionRoute de la Microsoft documentează domeniile pentru un singur utilizator și pentru toți utilizatorii; un profil pentru toți utilizatorii are nevoie de propriul parametru de domeniu, iar o comandă pentru un singur utilizator împotriva unui profil pentru toți utilizatorii eșuează sau ajunge în locul greșit.

Când profilul este administrat sau provine de la un client al furnizorului, schimbarea aparține acelui proprietar. Suprapunerea unei rute de sistem permanente peste o politică de conexiune funcționează până când politica este reaplicată și ruta dispare, ceea ce se întâmplă de obicei în timpul unui apel de suport, nu în timpul testelor. Acea defecțiune este silențioasă: ruta dispare, numele nu mai este rezolvat și nimeni nu leagă cele două evenimente. Pune schimbarea în înregistrarea proprie a proprietarului, ca reaplicarea următoare să o poarte în loc să o șteargă.

După aplicare, reconectează profilul în loc să presupui că ruta a intrat în vigoare. Modificările de rută pe o conexiune activă nu sunt întotdeauna preluate, iar reconectarea reproduce și starea pe care utilizatorii tăi o vor avea cu adevărat.

Verifică ce resolver a folosit de fapt clientul

O rută controlează pachetele adresate resolverului. Nu decide ce nume trebuie trimise acolo, iar acea selecție este un mecanism separat. În Windows, regulile efective de spațiu de nume pot alege un resolver pe domeniu, în timp ce setările DNS ale profilului oferă o valoare implicită. Aceste două straturi pot fi în dezacord fără a produce nicio eroare, de aceea o interogare directă este doar jumătate din dovadă.

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

Prima comandă afișează politica de spațiu de nume în vigoare, iar a doua întreabă resolverul privat direct despre numele aplicației. Un răspuns direct dovedește că calea și resolverul funcționează; nu dovedește că interogarea aplicației însăși a ales acel server. Compară-l cu o interogare normală a aceluiași nume și cu răspunsul pe care îl primește aplicația.

Ia în calcul cache-urile și DNS-ul securizat la nivel de browser, care poate ocoli complet resolverul sistemului pentru numele tastate de un utilizator. Un sufix de căutare este un alt indiciu fals: extinde un nume scurt într-unul complet calificat și nu are legătură cu ce server răspunde.

Încheie reconectând și repetând interogarea normală, apoi confirmă că navigarea obișnuită urmează în continuare politica aprobată. Înlocuirea resolverului privat cu unul public ca să se rezolve un nume nelegat nu este o remediere și mută în liniște interogările private acolo unde nu ar fi trebuit să ajungă niciodată.