Jaettu tunnelisi tavoittaa sovelluksen mutta ei sen DNS-palvelinta
Jaettu tunneli voi reitittää sovelluksen aliverkon ja silti pudottaa vieressä olevan ratkaisijan. Lisää isäntäreitti ja tarkista sitten, minkä palvelimen Windows todella valitsee.
Sovelluksen aliverkon reitittäminen on jaetun tunnelin ilmeinen osa, eikä se ole koko työ. Ratkaisija istuu usein eri osoitteessa kuin sovellus, jota se palvelee, joten toimiva tunneli voi silti jättää haun sen ulkopuolelle. Profiili, joka kantaa 10.80.0.0/16 eikä mitään muuta, lähettää 10.90.0.53:n kyselyn paikallisen liitännän kautta, missä yksityistä vyöhykettä ei ole. Lisää ratkaisijan reitti ja katso sitten ongelman toista puolta: minkä palvelimen asiakas todella valitsee.
Myytti: yksi reitti kattaa koko palvelun
Jaettu tunneli on luettelo kohteista, jotka kulkevat yhteyden kautta, ei palvelun kuvaus. Sovelluksen aliverkko ja ratkaisijan osoite ovat kaksi kohdetta, ja profiili voi kantaa toisen ilman toista. Kun näin käy, sovellus on tavoitettavissa osoitteella, mutta sen nimi epäonnistuu, mikä näyttää DNS-vialta eikä reititysaukolta.
Ratkaisijan ympärillä oleva aliverkko ei sekään ole automaattisesti katettu. Isäntäreitti yhteen osoitteeseen riittää kyseiselle ratkaisijalle eikä avaa sen naapureita. Siinä on isäntäreitin idea: kapea suunnittelultaan ja helppo unohtaa, kun seuraava palvelu ilmaantuu samaan aliverkkoon.
Kolmen asian on oltava voimassa, jotta haku toimii: asiakas reitittää ratkaisijan osoitteen tunnelin kautta, yhdyskäytävä hyväksyy ja välittää pyynnön, ja ratkaisija hyväksyy lähteen, jonka se vastaanottaa. Myös vastauksen on palattava sovittua polkua. Jos yksikin puuttuu, oire on sama, joten osoitetaulukko kannattaa kirjoittaa ennen kuin konfiguraatioon koskee.
Selvitä, mitä osoitteita profiilin on kannettava
Luettele kohteet järjestyksessä: sovelluksen verkko, ratkaisijan osoite ja julkinen päätepiste, joka päättää itse tunnelin. Kolmatta ei saa koskaan reitittää tunnelin sisään, koska ulompi yhteys tarvitsee polun, joka on olemassa ennen tunnelia.
| 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 |
Sisällytä DNS:lle sekä UDP että TCP, koska toteutuksilta odotetaan TCP:n tukea UDP:n rinnalla, ja estetty TCP-polku tuottaa hitaita, osittaisia vikoja puhtaiden sijaan. Jos yksityistä vyöhykettä tarjoillaan myös IPv6:n kautta, vastaava isäntäpoikkeus käyttää IPv6-osoitetta ja -etuliitettä ja on erillinen merkintä.
Kirjaa, mitä profiili jo kattaa, ennen kuin lisäät mitään. Kaksinkertainen reitti on vaaraton, mutta odottamaton olemassa oleva reitti kertoo, että profiili suunniteltiin eri osoitesuunnitelmaa varten kuin se, jonka sait.
Lisää isäntäreitti yhteyden omistajan kautta
Paikallisesti hallinnoidussa natiivissa Windows-profiilissa reitti kuuluu yhteydelle eikä koneen yleiseen reititystauluun. Esikatsele lisäystä ensin ja käytä sitä sitten samalla laajuudella, jota profiili käyttää.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Ensimmäinen komento esikatselee muutoksen asentamatta mitään, ja toinen luettelee reitit, joita profiili tällä hetkellä kantaa. Microsoftin viite Add-VpnConnectionRoute-komennosta dokumentoi käyttäjäkohtaiset ja kaikkien käyttäjien laajuudet; kaikkien käyttäjien profiili tarvitsee oman laajuusparametrinsa, ja käyttäjäkohtainen komento kaikkien käyttäjien profiilia vastaan epäonnistuu tai päätyy väärään paikkaan.
Kun profiilia hallinnoidaan tai se tulee toimittajan asiakasohjelmasta, muutos kuuluu sille omistajalle. Pysyvän järjestelmäreitin pinoaminen yhteyskäytännön päälle toimii, kunnes käytäntö otetaan uudelleen käyttöön ja reitti katoaa, mitä tapahtuu yleensä tukipuhelun aikana eikä testauksen aikana. Se vika on äänetön: reitti katoaa, nimi lakkaa ratkeamasta, eikä kukaan yhdistä kahta tapahtumaa. Laita muutos omistajan omaan tietueeseen, jotta seuraava uudelleenkäyttö kantaa sen sen sijaan että pyyhkii sen.
Yhdistä profiili uudelleen soveltamisen jälkeen sen sijaan että olettaisit reitin tulleen voimaan. Reittimuutoksia elävässä yhteydessä ei aina havaita, ja uudelleenyhdistäminen toisintaa myös tilan, joka käyttäjilläsi todella on.
Tarkista, mitä ratkaisijaa asiakas todella käytti
Reitti ohjaa ratkaisijalle osoitettuja paketteja. Se ei päätä, mitkä nimet sinne lähetetään, ja se valinta on erillinen mekanismi. Windowsissa voimassa olevat nimiavaruussäännöt voivat valita ratkaisijan toimialueittain, kun taas profiilin DNS-asetukset antavat oletuksen. Nämä kaksi kerrosta voivat olla eri mieltä tuottamatta mitään virhettä, siksi suora kysely on vain puolet todisteesta.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Ensimmäinen komento tulostaa voimassa olevan nimiavaruuskäytännön, ja toinen kysyy yksityiseltä ratkaisijalta suoraan sovelluksen nimeä. Suora vastaus todistaa, että polku ja ratkaisija toimivat; se ei todista, että sovelluksen oma haku valitsi juuri tuon palvelimen. Vertaa sitä saman nimen tavalliseen hakuun ja vastaukseen, jonka sovellus saa.
Ota huomioon välimuistit ja selaintason suojattu DNS, joka voi ohittaa järjestelmän ratkaisijan kokonaan käyttäjän kirjoittamille nimille. Hakuliite on toinen harhakuva: se laajentaa lyhyen nimen täysin kelpoiseksi eikä liity mitenkään siihen, mikä palvelin vastaa.
Lopuksi yhdistä uudelleen ja toista tavallinen haku, ja varmista sitten, että tavallinen selailu noudattaa edelleen hyväksyttyä käytäntöään. Yksityisen ratkaisijan korvaaminen julkisella, jotta jokin asiaankuulumaton nimi ratkeaisi, ei ole korjaus, ja se siirtää yksityiset kyselyt hiljaa sinne, minne niitä ei koskaan ollut tarkoitettu.