Pse kërkimet e emrave dështojnë përmes një tuneli OpenVPN të rrugëtuar

Një host përgjigjet ndaj ping-ut sipas adresës dhe dështon në çdo kërkim sipas emrit. Tuneli është lart dhe rruga ekziston, prandaj përfundimi i natyrshëm është që VPN-ja është konfiguruar gabim. Një përfundim më i dobishëm është që kërkimi nuk ishte kurrë i rrugëtueshëm: një tunel i rrugëtuar mbart unicast IP, ndërsa kërkesa ishte një transmetim që kërkonte një segment që nuk ekziston në anën tjetër. Pasi mospërputhja e shtresave bëhet e dukshme, rregullimet renditen vetë sipas kostos.

Miti: tuneli është i prishur sepse dështojnë emrat

Simptomi është bindës sepse gjithçka mbi shtresën e emrave funksionon. Adresat rrugëtohen, ndërfaqja është lart dhe partneri përgjigjet ndaj ping-ut. Ajo që dështoi është një mekanizëm zbulimi që nuk kishte kurrë rrugë përmes një lidhjeje pikë-për-pikë, dhe ky është një pohim tjetër nga një tunel i prishur. Ndarja e këtyre dy pohimeve është pjesa më e madhe e diagnozës.

Trajtimi si defekt tuneli të çon në ndryshime profili që nuk mund të ndihmojnë. Shtimi i opsioneve, ndryshimi i kriptimit ose riinstalimi i klientit e lë transmetimin saktësisht aty ku ishte.

Emërto mekanizmin që dështoi përpara se të emërtojë rregullimin. Një kërkim që përdor transmetimin ka nevojë për një segment, ndërsa një kërkim që përdor një zgjidhës ka nevojë për një adresë për të pyetur.

Çfarë mbart TUN dhe çfarë jo

Një pajisje TUN është një ndërfaqe IP, dhe kjo është ajo që e bën të rrugëtueshme. OpenVPN i jep klientit një adresë dhe një grup rrugësh, dhe prej aty klienti dërgon datagrame te partneri. Asgjë në atë model nuk krijon një lidhje të përbashkët ku çdo host dëgjon çdo kornizë.

Trafiku i zbulimit nuk përshtatet fare me atë model. Kërkesat e vjetra të emrave në Windows, njoftimet SSDP dhe kërkesat mDNS dërgohen te të gjithë në një segment në vend të një destinacioni të vetëm. Një lidhje e rrugëtuar nuk ka asnjë «të gjithë» ku të dërgojë. Secili prej këtyre mekanizmave supozon një medium të përbashkët.

Prandaj tuneli mund të jetë i shëndetshëm ndërsa zbulimi dështon plotësisht. Është pikërisht ajo fjali që duhet mbajtur kur dikush raporton se VPN-ja ka rënë.

Ura funksionon duke hequr kufirin

Një pajisje TAP mbart korniza, dhe një urë e lidh atë me një segment LAN të vërtetë. Klienti atëherë mban një adresë në atë segment dhe dëgjon trafikun e tij të transmetimit. Kjo është arsyeja pse ura duket se shëron problemin e emrave. Ajo gjithashtu e bën klientin të varur nga ai segment për adresimin.

Shërimi është heqja e kufirit të rrugëtimit, jo ndonjë aftësi e re emërtimi brenda tunelit. Gjithçka që segmenti transmeton tani kalon edhe lidhjen.

Për një laborator të vogël ky është një shkëmbim i drejtë. Në një fuqi punëtore të shpërndarë rrallë është.

Shtyrja e DNS dhe WINS është rregullimi më i ngushtë

Jepini klientit një vend të caktuar për të pyetur. dhcp-option DNS dhe dhcp-option DOMAIN i drejtojnë emrat e brendshëm te një server që e njeh zonën, dhe një klient Windows që ende mbështetet te NetBIOS mund të marrë një server WINS në të njëjtën mënyrë. Tuneli mbetet i rrugëtuar dhe segmenti mbetet aty ku i takon.

Dy kushte vendosin nëse kjo funksionon. Serveri i përmendur duhet të përgjigjet për zonën, dhe kërkesa duhet të lejohet përmes tunelit.

Testoni zgjidhësin nga klienti dhe jo nga shell-i i vetë serverit. Një zgjidhës që funksionon lokalisht nuk thotë asgjë për atë që mbart tuneli.

Zbuloni cila shtresë dështoi

Fillimisht bëni ping adresës, pastaj zgjidhni emrin dhe lexoni cili server u përgjigj. Një përgjigje negative nga një server që nuk e strehon zonën duket ndryshe nga një kërkesë që nuk doli kurrë nga makina. Një emër që zgjidhet por refuzon lidhjet është një problem i tretë krejt i veçantë.

Multicast qëndron pas të njëjtit mur. Një grup si 224.0.0.251 nuk përcillet përmes një tuneli të rrugëtuar si parazgjedhje, dhe një rrugë për grupin nuk mjafton pa një shteg që kupton multicast ose një pasqyrues në LAN.