Zure split tunelak aplikazioa iristen du, baina ez bere DNS zerbitzaria

Aplikazioaren azpisarea bideratzea split tunel baten zati begi-bistakoa da, eta ez da lan guztia. Ebazlea sarritan zerbitzatzen duen aplikazioaren helbide ezberdinean egoten da, beraz tunel funtzional batek bilaketa hartatik kanpo utz dezake. 10.80.0.0/16 eta besterik ezer eramaten duen profil batek 10.90.0.53-ren kontsulta interfaze lokaletik bidaltzen du, non ez baitago zona pribaturik. Gehitu ebazlearen bidea, eta gero begiratu arazoaren bigarren erdia: zein zerbitzari aukeratzen duen bezeroak benetan.

Mitoa: bide batek zerbitzu osoa estaltzen du

Split tunel bat konexiotik igarotzen diren helmugen zerrenda bat da, ez zerbitzu baten deskribapena. Aplikazioaren azpisarea eta ebazlearen helbidea bi helmuga dira, eta profil batek bat eraman dezake bestea gabe. Hori gertatzen denean, aplikazioa helbidez irisgarria da, baina bere izenak huts egiten du, eta hori DNS akats gisa ikusten da, bideratze hutsune gisa baino.

Ebazlearen inguruko azpisarea ere ez dago automatikoki estalita. Helbide bakarrera doan ostalariaren bideak nahikoa du ebazle horretarako eta ez ditu bere bizilagunak irekitzen. Horixe da ostalariaren bidearen zentzua: diseinuz estua, eta erraza ahazteko hurrengo zerbitzua azpisare berean agertzen denean.

Hiru gauzak bete behar dira bilaketak funtziona dezan: bezeroak ebazlearen helbidea tuneletik bideratzen du, atebideak eskaera hori onartu eta birbidaltzen du, eta ebazleak jasotzen duen iturria onartzen du. Erantzunak ere adostutako bidetik itzuli behar du. Horietako bat falta bada, sintoma berdina da, eta horregatik merezi du helbide taula idaztea konfigurazioari ukitu aurretik.

Zehaztu profilek zein helbide eraman behar dituen

Zerrendatu helmugak ordenan: aplikazioaren sarea, ebazlearen helbidea eta tunela bera amaitzen duen amaiera publikoa. Hirugarrena ez da inoiz tunelean bideratu behar, kanpoko konexioak tunela existitu aurretik existitzen den bide bat behar baitu.

Sartu UDP eta TCP biak DNSarentzat, inplementazioek UDP-rekin batera TCP onartzea espero baita, eta TCP bide blokeatuak huts egite motel eta partzialak sortzen baititu garbiak beharrean. Zona pribatua IPv6 bidez ere zerbitzatzen bada, baliokidea den ostalariaren salbuespenak IPv6 helbidea eta aurrizkia erabiltzen ditu eta bereizitako sarrera da.

Idatzi profilak jada zer estaltzen duen ezer gehitu aurretik. Bide bikoiztua kaltegabea da, baina existitzen den bide ustekabeko batek esaten dizu profila eman dizuten helbide planaz bestelako baterako diseinatu zela.

Gehitu ostalariaren bidea konexioaren jabearen bidez

Tokian kudeatutako Windows profil natibo batean, bidea konexioarena da, ez makinaren bideratze taula orokorrarena. Aurreikusi gehikuntza lehenik, eta gero aplikatu profilek erabiltzen duen irismen berarekin.

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

Lehen komandoak aldaketa aurreikusten du ezer instalatu gabe, eta bigarrenak profilek gaur egun daramatzan bideak zerrendatzen ditu. Microsoft-en Add-VpnConnectionRoute-ren erreferentzia dokumentuak erabiltzaile bakarreko eta erabiltzaile guztietako irismenak jasotzen ditu; erabiltzaile guztietako profilek bere irismen parametroa behar du, eta erabiltzaile bakarrerako komandoa erabiltzaile guztietako profil baten aurka huts egiten du edo leku okerrean amaitzen du.

Profila kudeatua denean edo hornitzaile baten bezerotik datorrenean, aldaketa jabe horrena da. Bide iraunkor bat konexio politika baten gainean pilatzeak funtzionatzen du politika berriro aplikatu eta bidea desagertu arte, eta hori normalean laguntza dei batean gertatzen da, probetan ez. Akats hori isila da: bidea desagertu egiten da, izenak ebatzi egiten du eta inork ez ditu bi gertaerak lotzen. Jarri aldaketa jabearen erregistro propioan, hurrengo berraplikazioak eramango dezan ezabatu beharrean.

Aplikatu ondoren, berriz konektatu profila, bidea indarrean sartu dela suposatu beharrean. Konexio bizian egindako bide aldaketak ez dira beti jasotzen, eta berriz konektatzeak zure erabiltzaileek benetan izango duten egoera ere birsortzen du.

Egiaztatu bezeroak benetan zein ebazle erabili zuen

Bide batek ebazlera zuzendutako paketeak kontrolatzen ditu. Ez du erabakitzen zein izen bidali behar diren hara, eta hautapen hori mekanismo bereizi bat da. Windows-en, espazio izenaren arau eraginkorrek domeinuko ebazlea aukera dezakete, profilearen DNS ezarpenek lehenetsitako bat ematen duten bitartean. Bi geruza horiek ados ez egon daitezke akatsik sortu gabe, eta horregatik kontakizun zuzen bat froga erdia baino ez da.

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

Lehen komandoak indarrean dagoen espazio izenaren politika inprimatzen du, eta bigarrenak ebazle pribatuari zuzenean galdetzen dio aplikazioaren izenaren berri. Erantzun zuzenak bidea eta ebazlea funtzionatzen dutela frogatzen du; ez du frogatzen aplikazioaren bilaketak berak zerbitzari hori aukeratu zuenik. Konparatu ezazu izen bereko bilaketa normal batekin eta aplikazioak jasotzen duen erantzunarekin.

Hartu kontuan cacheak eta nabigatzaile mailako DNS segurua, erabiltzaileak idatzitako izenentzat sistemaren ebazlea erabat saihestu baitezake. Bilaketa atzizkia beste arrasto faltsu bat da: izen laburra erabat gaitutako izen bihurtzen du eta ez du zerikusirik zein zerbitzarik erantzuten duen.

Amaitu berriz konektatuz eta ohiko bilaketa errepikatuz, eta gero egiaztatu ohiko nabigazioak oraindik bere politika onartua jarraitzen duela. Ebazle pribatua publiko batekin ordeztea erlaziorik gabeko izen bat ebazteko ez da konponketa, eta isilik eramaten ditu kontsulta pribatuak inoiz egon behar ez zuten tokira.