Jou split-tonnel bereik die app, maar nie sy DNS-bediener nie

Om die toepassing se subnet te roeteer is die ooglopende deel van 'n split-tonnel, en dit is nie die hele taak nie. Die resolver sit dikwels op 'n ander adres as die toepassing wat dit bedien, so 'n werkende tonnel kan die opsoek steeds buite dit laat. 'n Profiel wat 10.80.0.0/16 en niks anders dra nie, stuur die navraag vir 10.90.0.53 uit die plaaslike koppelvlak, waar geen private sone bestaan nie. Voeg die resolver-roete by en kyk dan na die tweede helfte van die probleem: watter bediener die kliënt werklik kies.

Die mite: een roete dek die hele diens

'n Split-tonnel is 'n lys bestemmings wat deur die verbinding gaan, nie 'n beskrywing van 'n diens nie. Die toepassingsubnet en die resolver-adres is twee bestemmings, en 'n profiel kan die een sonder die ander dra. Wanneer dit gebeur, is die toepassing per adres bereikbaar terwyl sy naam misluk, wat soos 'n DNS-fout eerder as 'n roete-gaping lyk.

Die subnet rondom die resolver is ook nie outomaties gedek nie. 'n Host-roete na 'n enkele adres is genoeg vir daardie resolver en maak nie sy bure oop nie. Dit is die punt van 'n host-roete: smal van ontwerp, en maklik om te vergeet wanneer die volgende diens op dieselfde subnet verskyn.

Drie dinge moet geld vir die opsoek om te werk: die kliënt roeteer die resolver-adres deur die tonnel, die gateway laat daardie versoek toe en stuur dit aan, en die resolver aanvaar die bron wat dit ontvang. 'n Antwoord moet ook langs die ooreengekome pad terugkom. Mis enige een daarvan en die simptoom is identies, daarom is dit die moeite werd om die adrestabel neer te skryf voordat jy aan 'n konfigurasie raak.

Bepaal watter adresse die profiel moet dra

Lys die bestemmings in volgorde: die toepassingsnetwerk, die resolver-adres en die publieke eindpunt wat die tonnel self termineer. Die derde een moet nooit in die tonnel gerouteer word nie, want die buitenste verbinding het 'n pad nodig wat bestaan voordat die tonnel dit doen.

Sluit beide UDP en TCP vir DNS in, want daar word van implementasies verwag om TCP sowel as UDP te ondersteun, en 'n geblokkeerde TCP-pad lewer stadige, gedeeltelike foute eerder as skoon foute. As die private sone ook oor IPv6 bedien word, gebruik die ekwivalente host-uitsondering 'n IPv6-adres en -voorvoegsel en is dit 'n aparte inskrywing.

Teken aan wat die profiel reeds dek voordat jy iets byvoeg. 'n Duplikaat-roete is onskadelik, maar 'n onverwagte bestaande roete sê vir jou die profiel is vir 'n ander adresplan ontwerp as dié wat jy gekry het.

Voeg die host-roete by deur die eienaar van die verbinding

Vir 'n plaaslik bestuurde inheemse Windows-profiel hoort die roete by die verbinding eerder as by die masjien se globale roetetabel. Voorskou eers die byvoeging en pas dit dan toe met dieselfde omvang wat die profiel gebruik.

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

Die eerste opdrag voorskou die verandering sonder om iets te installeer, en die tweede lys die roetes wat die profiel tans dra. Microsoft se verwysing na Add-VpnConnectionRoute dokumenteer die per-gebruiker- en alle-gebruikers-omvange; 'n alle-gebruikersprofiel het sy eie omvangparameter nodig, en 'n per-gebruiker-opdrag teen 'n alle-gebruikersprofiel misluk of beland op die verkeerde plek.

Wanneer die profiel bestuur word of van 'n verskaffer-kliënt kom, hoort die verandering by daardie eienaar. Om 'n permanente stelselroete bo-op 'n verbindingsbeleid te stapel, werk totdat die beleid weer toegepas word en die roete weg is, wat gewoonlik tydens 'n ondersteuningsoproep eerder as tydens toetsing gebeur. Daardie fout is stil: die roete verdwyn, die naam hou op om op te los, en niemand verbind die twee gebeurtenisse nie. Sit die verandering in die eienaar se eie rekord sodat die volgende hertoepassing dit dra eerder as om dit uit te wis.

Maak ná die toepassing weer aan die profiel gekoppel eerder as om aan te neem die roete het in werking getree. Roeteveranderinge op 'n lewendige verbinding word nie altyd opgemerk nie, en 'n herkoppeling reproduseer ook die toestand wat jou gebruikers werklik sal hê.

Kontroleer watter resolver die kliënt werklik gebruik het

'n Roete beheer pakkette wat aan die resolver gerig is. Dit besluit nie watter name daarheen gestuur moet word nie, en daardie keuse is 'n aparte meganisme. Op Windows kan effektiewe naamruimte-reëls 'n resolver per domein kies, terwyl die profiel se DNS-instellings 'n verstekwaarde verskaf. Daardie twee lae kan verskil sonder om enige fout te produseer, daarom is 'n direkte navraag net die helfte van die bewyse.

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

Die eerste opdrag druk die naamruimte-beleid wat geld, en die tweede vra die private resolver direk vir die toepassing se naam. 'n Direkte antwoord bewys dat die pad en die resolver werk; dit bewys nie dat die toepassing se eie opsoek daardie bediener gekies het nie. Vergelyk dit met 'n normale opsoek van dieselfde naam en met die antwoord wat die toepassing ontvang.

Hou rekening met buffers en met browser-vlak veilige DNS, wat die stelsel-resolver heeltemal kan omseil vir name wat 'n gebruiker getik het. 'n Soek-agtervoegsel is nog 'n afleiding: dit brei 'n kort naam uit na 'n volledig gekwalifiseerde een en het niks te doen met watter bediener antwoord nie.

Sluit af deur weer te koppel en die normale opsoek te herhaal, en bevestig dan dat gewone blaaiery steeds sy goedgekeurde beleid volg. Om die private resolver met 'n publieke een te vervang sodat 'n onverwante naam oplos, is nie 'n regstelling nie, en dit skuif private navrae stilweg na 'n plek waar hulle nooit bedoel was om te gaan nie.