Jo split-tunnel berikt de app, mar net har DNS-tsjinner
In split-tunnel kin it subnet fan de app routearje en dochs de resolver dernjonken falle litte. Foegje de hostrûte ta en kontrolearje dan hokker tsjinner Windows eins kiest.
It subnet fan de applikaasje routearje is it fanselssprekkende part fan in split-tunnel, en it is net it hiele wurk. De resolver sit faak op in oar adres as de applikaasje dy't er tsjinnet, sadat in wurkjende tunnel it sykjen der noch bûten litte kin. In profyl dat 10.80.0.0/16 draacht en fierders neat stjoert de fraach foar 10.90.0.53 oer de lokale ynterface, dêr't gjin priveesône bestiet. Foegje de rûte fan de resolver ta en besjoch dan de twadde helte fan it probleem: hokker tsjinner de klient eins kiest.
De myte: ien rûte dekt de hiele tsjinst
In split-tunnel is in list fan bestimmingen dy't troch de ferbining geane, gjin beskriuwing fan in tsjinst. It subnet fan de applikaasje en it adres fan de resolver binne twa bestimmingen, en in profyl kin de iene sûnder de oare drage. As dat bart, is de applikaasje berikber op adres wylst har namme mislearret, wat earder op in DNS-flater as op in rûtegat liket.
It subnet om de resolver hinne is ek net automatysk dekt. In hostrûte nei ien adres is genôch foar dy resolver en iepenet syn buorlju net. Dat is it punt fan in hostrûte: smal fan ûntwerp, en maklik te ferjitten as de folgjende tsjinst op itselde subnet ferskynt.
Trije dingen moatte jilde om it sykjen wurkje te litten: de klient routearret it adres fan de resolver troch de tunnel, de gateway lit dat fersyk ta en stjoert it troch, en de resolver akseptearret de boarne dy't er krijt. In antwurd moat ek weromkomme oer it ôfsprutsen paad. Mist ien fan dy, dan is it symptoom itselde, dêrom is it de muoite wurdich de adrestabel op te skriuwen foardat jo in konfiguraasje oanreitsje.
Bepale hokker adressen it profyl drage moat
Lis de bestimmingen yn folchoarder op: it netwurk fan de applikaasje, it adres fan de resolver en it iepenbiere einpunt dat de tunnel sels einige. De tredde mei nea de tunnel ynrûte wurde, want de bûtenferbining hat in paad nedich dat bestiet foardat de tunnel dat docht.
| 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 |
Nim sawol UDP as TCP foar DNS op, mei't fan ymplemintaasjes ferwachte wurdt dat se TCP njonken UDP stypje, en in blokkearre TCP-paad jout stadige, dielbere flaters ynstee fan skjinne. Wurdt de priveesône ek oer IPv6 betsjinne, dan brûkt de ekwivalinte hostútsûndering in IPv6-adres en -prefix en is it in aparte ynfier.
Skriuw op wat it profyl al dekt foardat jo eat tafoegje. In dûbele rûte is harmless, mar in ûnferwachte besteande rûte seit dat it profyl ûntwurpen is foar in oar adresplan as dat jo krigen hawwe.
Foegje de hostrûte ta fia de eigner fan de ferbining
Foar in lokaal beheard nasjonaal Windows-profyl heart de rûte by de ferbining ynstee fan by de globale rûtetabel fan de masine. Besjoch de tafoeging earst foarôf en pas dy dan ta mei deselde omfang dy't it profyl brûkt.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
It earste kommando lit de feroaring foarôf sjen sûnder eat te ynstallearjen, en it twadde listet de rûtes op dy't it profyl op dit stuit draacht. De referinsje fan Add-VpnConnectionRoute fan Microsoft dokumintearret de omfangen per brûker en foar alle brûkers; in profyl foar alle brûkers hat syn eigen omfangsparameter nedich, en in kommando per brûker tsjin in profyl foar alle brûkers mislearret of bedarret op it ferkearde plak.
As it profyl beheard wurdt of fan in leveransiersklient komt, heart de feroaring by dy eigner. In permaninte systeemrûte op in ferbiningsbelied stapelje wurket oant it belied opnij tapast wurdt en de rûte fuort is, wat meastentiids by in stipe-oprop bart en net by testen. Dy flater is stil: de rûte ferdwynt, de namme hâldt op mei oplossen, en nimmen ferbynt de twa barren. Set de feroaring yn it eigen record fan de eigner, sadat de folgjende weromtapassing it draacht ynstee fan it wisket.
Meitsje nei it tapassen de ferbining opnij oan ynstee fan oan te nimmen dat de rûte wurking hie. Rûteferoarings op in libbene ferbining wurde net altyd oppakt, en opnij ferbinen reproduzet ek de tastân dy't jo brûkers eins hawwe sille.
Kontrolearje hokker resolver de klient eins brûkt hat
In rûte regelet pakketten dy't oan de resolver adressearre binne. It beslút net hokker nammen dêr hinne stjoerd moatte wurde, en dy seleksje is in apart meganisme. Op Windows kinne effektive nammerûmteregels in resolver per domein kieze, wylst de DNS-ynstellingen fan it profyl in standert leverje. Dy twa lagen kinne fan elkoar ôfwike sûnder ien flater te meitsjen, dêrom is in direkte fraach mar de helte fan it bewiis.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
It earste kommando prints it jildende nammerûmbelied, en it twadde freget de priveeresolver direkt om de namme fan de applikaasje. In direkt antwurd bewissiget dat it paad en de resolver wurkje; it bewissiget net dat it eigen sykjen fan de applikaasje dy tsjinner keas. Fergelykje it mei in normaal sykjen fan deselde namme en mei it antwurd dat de applikaasje krijt.
Hâld rekken mei caches en mei feilich DNS op browsernivo, dat de systeemresolver hielendal foarby gean kin foar nammen dy't in brûker typt hat. In sykstafix is in oare falske oanwizing: it wreidet in koarte namme út ta in folslein kwalifisearre ien en hat neat te meitsjen mei hokker tsjinner antwurdet.
Einigje mei opnij ferbinen en it normale sykjen te werheljen, en befêstigje dan dat gewoan browsen noch altyd syn goedkarde belied folget. De priveeresolver ferfange troch in iepenbiere om in net besibbe namme oplosse te litten is gjin reparaasje, en it ferpleatst priveefragen stil nei in plak dêr't se nea bedoeld wiene.