Tuneli juaj i ndarë arrin aplikacionin, por jo serverin e tij DNS

Rrugëzimi i nënrrjetit të aplikacionit është pjesa e dukshme e një tuneli të ndarë, dhe nuk është e gjithë puna. Zgjidhësi shpesh qëndron në një adresë tjetër nga aplikacioni që shërben, kështu që një tunel që funksionon mund ta lërë kërkimin jashtë tij. Një profil që mbart 10.80.0.0/16 dhe asgjë tjetër e dërgon pyetësin për 10.90.0.53 përmes ndërfaqes lokale, ku nuk ekziston asnjë zonë private. Shto rrugën e zgjidhësit, më pas shiko gjysmën e dytë të problemit: cilin server zgjedh në të vërtetë klienti.

Miti: një rrugë mbulon të gjithë shërbimin

Një tunel i ndarë është një listë destinacionesh që kalojnë përmes lidhjes, jo një përshkrim i një shërbimi. Nënrrjeti i aplikacionit dhe adresa e zgjidhësit janë dy destinacione, dhe një profil mund të mbajë njërin pa tjetrin. Kur ndodh kjo, aplikacioni është i arritshëm me adresë ndërsa emri i tij dështon, gjë që duket si defekt DNS dhe jo si boshllëk në rrugëzim.

As nënrrjeti përreth zgjidhësit nuk mbulohet automatikisht. Një rrugë hosti drejt një adrese të vetme mjafton për atë zgjidhës dhe nuk i hap fqinjët e tij. Ky është kuptimi i një rrugë hosti: e ngushtë nga projekti, dhe e lehtë për t'u harruar kur shërbimi tjetër shfaqet në të njëjtin nënrrjet.

Tri gjëra duhet të jenë të vërteta që kërkimi të funksionojë: klienti e rrugëzon adresën e zgjidhësit përmes tunelit, porta e pranon dhe e përcjell atë kërkesë, dhe zgjidhësi pranon burimin që merr. Përgjigja gjithashtu duhet të kthehet në rrugën e rënë dakord. Nëse mungon njëra prej tyre, simptoma është e njëjtë, prandaj ia vlen të shkruhet tabela e adresave përpara se të prekësh një konfigurim.

Përcakto cilat adresa duhet të mbajë profili

Rendit destinacionet sipas radhës: rrjeti i aplikacionit, adresa e zgjidhësit dhe pika përfundimtare publike që përfundon vetë tunelin. E treta nuk duhet të rrugëzohet kurrë brenda tunelit, sepse lidhja e jashtme ka nevojë për një rrugë që ekziston para tunelit.

Përfshi si UDP ashtu edhe TCP për DNS, pasi nga implementimet pritet të mbështesin TCP krahas UDP, dhe një rrugë TCP e bllokuar prodhon dështime të ngadalta e të pjesshme në vend të atyre të pastra. Nëse zona private shërbehet edhe përmes IPv6, përjashtimi ekuivalent i hostit përdor një adresë dhe një prefiks IPv6 dhe është një zë i veçantë.

Shkruaj çfarë mbulon tashmë profili përpara se të shtosh diçka. Një rrugë e dyfishuar është e padëmshme, por një rrugë ekzistuese e papritur të thotë se profili u projektua për një plan adresash të ndryshëm nga ai që të dhanë.

Shto rrugën e hostit përmes pronarit të lidhjes

Për një profil Windows vendas të administruar lokalisht, rruga i përket lidhjes dhe jo tabelës globale të rrugëzimit të makinës. Shiko shtesën së pari në parapamje, më pas zbatoje me të njëjtin shtrirje që përdor profili.

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

Komanda e parë tregon ndryshimin në parapamje pa instaluar asgjë, dhe e dyta rendit rrugët që profili mban tani. Referenca e Add-VpnConnectionRoute nga Microsoft dokumenton shtrirjet për çdo përdorues dhe për të gjithë përdoruesit; një profil për të gjithë përdoruesit ka nevojë për parametrin e vet të shtrirjes, dhe një komandë për çdo përdorues kundër një profili për të gjithë përdoruesit dështon ose përfundon në vendin e gabuar.

Kur profili administrohet ose vjen nga një klient furnizuesi, ndryshimi i përket atij pronari. Vendosja e një rruge të përhershme sistemi mbi një politikë lidhjeje funksionon derisa politika të zbatohet përsëri dhe rruga të zhduket, gjë që ndodh zakonisht gjatë një telefonate suporti dhe jo gjatë testimit. Ai defekt është i heshtur: rruga zhduket, emri ndalon së zgjidhuri dhe askush nuk i lidh dy ngjarjet. Vendos ndryshimin në regjistrin e vetë pronarit, që rizbatimi i radhës ta mbajë atë në vend që ta fshijë.

Pas zbatimit, rilidh profilin në vend që të supozosh se rruga ka hyrë në fuqi. Ndryshimet e rrugës në një lidhje të gjallë nuk kapen gjithmonë, dhe rilidhja riprodhon gjithashtu gjendjen që përdoruesit e tu do të kenë në të vërtetë.

Kontrollo cilin zgjidhës ka përdorur në të vërtetë klienti

Një rrugë kontrollon paketat e adresuara drejt zgjidhësit. Ajo nuk vendos cilat emra duhet të dërgohen atje, dhe ai përzgjedhje është një mekanizëm i veçantë. Në Windows, rregullat efektive të hapësirës së emrave mund të zgjedhin një zgjidhës për çdo domen, ndërsa cilësimet DNS të profilit japin një vlerë të paracaktuar. Këto dy shtresa mund të mospajtohen pa prodhuar asnjë gabim, prandaj një pyetës i drejtpërdrejtë është vetëm gjysma e provës.

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

Komanda e parë shtyp politikën e hapësirës së emrave në fuqi, dhe e dyta pyet drejtpërdrejt zgjidhësin privat për emrin e aplikacionit. Një përgjigje e drejtpërdrejtë vërteton se rruga dhe zgjidhësi funksionojnë; nuk vërteton se kërkimi i vetë aplikacionit zgjodhi atë server. Krahasoje me një kërkim normal të të njëjtit emër dhe me përgjigjen që merr aplikacioni.

Merr parasysh memorjet e përkohshme dhe DNS-në e sigurt në nivel shfletuesi, që mund të anashkalojë plotësisht zgjidhësin e sistemit për emrat që ka shkruar një përdorues. Prapashtesa e kërkimit është një gjurmë tjetër e rreme: zgjeron një emër të shkurtër në një të kualifikuar plotësisht dhe nuk ka asnjë lidhje me atë se cili server përgjigjet.

Përfundo duke u rilidhur dhe duke përsëritur kërkimin normal, më pas konfirmo se shfletimi i zakonshëm vazhdon të ndjekë politikën e tij të miratuar. Zëvendësimi i zgjidhësit privat me një publik që një emër i palidhur të zgjidhet nuk është rregullim, dhe i zhvendos në heshtje pyetësit privatë atje ku nuk duhej të kishin shkuar kurrë.