Cila lidhje përgjigjet: domenet e rrugëtimit për DNS-në e një VPN me tunel të ndarë

Mbajeni shfletimin e zakonshëm në lidhjen lokale ndërsa emrat e kompanisë zgjidhen përmes serverit DNS që ofron tuneli. Fikja e rrugës së parazgjedhur të VPN-së ju jep gjysmën e parë dhe lë gjysmën e dytë të pandërtuar. Më pas vijnë cilësimi që mungon, pikësimi që ndryshon kuptimin e tij dhe komanda e vetme që tregon cila lidhje përgjigjet në të vërtetë. NetworkManager dhe systemd-resolved supozohen gjatë gjithë tekstit, sepse pikërisht ky çift është vendi ku fillon zakonisht konfuzioni.

Hapi i parë: ndani rrugën nga zgjidhësi

ipv4.never-default përgjigjet një pyetjeje rrugëtimi dhe e pengon NetworkManager të instalojë këtë lidhje si rrugën për gjithë trafikun IPv4. Një domen rrugëtimi DNS përgjigjet një pyetjeje tjetër: cilët servera emrash të cilës lidhje marrin një kërkesë për një prapashtesë që përputhet. Asnjëri nuk nënkupton tjetrin, dhe një profil mund të mbajë njërin për vite ndërsa tjetri mungon. Vetëm rruga do të thotë që tuneli mbart nënrrjetet e kompanisë dhe zgjidhësi i tij përgjigjet emrave të kompanisë, ndërsa gjithçka tjetër lihet e paprekur.

Vendosni vetëm vetinë e rrugës dhe emrat e brendshëm dështojnë, zakonisht me një afat kohor që tingëllon si tunel i thyer. Vendosni vetëm domenin dhe keni shtuar në heshtje një prapashtesë kërkimi për çdo emër të shkurtër në makinë. Të dyja gabimet e dërgojnë tiketën te serveri VPN, i cili rrallë është pjesa që është e gabuar.

Hapi i dytë: shtoni një domen vetëm-rrugëtimi te profili

Supozoni se lidhja quhet corp-vpn, prapashtesa e kompanisë është internal.example dhe zgjidhësi i tunelit është tashmë i arritshëm. Lexoni fillimisht vlerat aktuale, sepse komandat më poshtë ndryshojnë veti që mund të kenë tashmë zëra.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Zëvendësoni me emrin tuaj të lidhjes dhe prapashtesën tuaj, sepse vlerat më sipër janë ilustruese. Shenja plus ka më shumë rëndësi sesa duket: me të vlera i shtohet listës ekzistuese, ndërsa pa të vetia zëvendësohet dhe domenet e palidhura zhduken nga një profil që funksiononte dje. Tilda ndryshon sjelljen, jo stilin, dhe paragrafi më poshtë shpjegon çfarë zgjedh ajo. Mbani leximin para shkrimit, që forma e zëvendësimit të mos ju befasojë kurrë.

Një tildë fillestare shënon një domen vetëm-rrugëtimi, kështu që kërkesat që përputhen shkojnë te serverat e kësaj lidhjeje dhe prapashtesa nuk u shtohet emrave të shkurtër. Hiqni tildën dhe i njëjti varg bëhet edhe prapashtesë kërkimi, një rezultat tjetër që njerëzit rrallë e synojnë. Të dyja cilësimet më sipër janë IPv4, prandaj një profil me dy stiva ka nevojë për ipv6.never-default dhe të njëjtin domen rrugëtimi në ipv6.dns-search, përndryshe ana IPv6 vazhdon të përdorë rrugën e parazgjedhur dhe emrat e brendshëm dështojnë atje.

Hapi i tretë: pyesni resolvectl cila lidhje përgjigjet

Ekzekutoni resolvectl status dhe lexoni serverat DNS e domenet e çdo lidhjeje, më pas ekzekutoni resolvectl query host.internal.example ndaj një emri të vërtetë të brendshëm që ju lejohet ta pyesni. Komanda e dytë është prova e vetme e drejtpërdrejtë se domeni i rrugëtimit po bën punën e vet, sepse emërton lidhjen që u përgjigj. Vetëm lista e statusit vërteton konfigurimin; kërkesa vërteton zgjidhjen.

systemd-resolved zgjedh domenin e rrugëtimit që përputhet më mirë, kështu që një domen më specifik në një lidhje tjetër mund ta fitojë ende garën. Nëse kërkesa kthehet nga një lidhje që nuk e prisnit, lexoni listat e domeneve përpara se të prekni serverin DNS të VPN-së. Një domen rrënjë ~. përputhet me gjithçka, dhe nëse është tashmë i pranishëm domeni juaj specifik fiton përsëri për emrat e vet, ndërsa lidhja përgjigjet shumë më tepër sesa kërkuat. Hiqni ose ngushtoni atë zë rrënjë kur qëllimi ishte vetëm emrat e kompanisë.

Nëse lidhja VPN nuk rendit fare një server DNS, klienti nuk ka regjistruar kurrë një. Një domen rrugëtimi pa server pas tij dështon ndryshe nga një domen që mungon, prandaj rregulloni fillimisht regjistrimin.

Hapi i katërt: kur emri zgjidhet, por shërbimi jo

Një përgjigje e saktë vërteton vetëm se zgjidhja funksionoi, dhe aplikacionit i duhet ende një rrugë drejt adresës që mori. Ajo rrugë duhet t'i mbijetojë rrugës së parazgjedhur të ndarë që sapo konfiguruat, prandaj kontrollojeni para se ta fajësoni përsëri DNS-në. Më pas kontrolloni arritshmërinë në portin e shërbimit, sepse një ndarje skedarësh ose një shërbim drejtorie dështon në zgjidhje, rrugëtim ose vërtetim dhe jep mesazhe shumë të ngjashme në çdo rast. Mbani ato tre shtresa të ndara kur raportoni rezultatin, përndryshe personi tjetër rikontrollon një DNS që ishte tashmë i saktë.

Ndryshimi në Samba që qarkullon pranë kësaj pyetjeje ka të bëjë me shtresën e aksesit, jo me zgjedhjen e DNS-së. Zbatimi i tij në një defekt të zgjidhjes së emrave është mënyra se si një problem i vogël merr një të dytë.

Hapi i pestë: mos e zëvendësoni zgjidhësin për të rregulluar një domen që mungon

Këshilla që mbishkruan skedarin e zgjidhësit ose instalon një menaxher tjetër zgjidhësi zgjidh një problem tjetër. Ato janë ndryshime të integrimit të sistemit me mënyrat e tyre të dështimit, dhe asnjëra nuk shton një domen rrugëtimi që nuk është konfiguruar kurrë. Përcaktoni cili komponent zotëron zgjidhjen e emrave në makinë përpara se ta zëvendësoni, sepse në një desktop NetworkManager me systemd-resolved ai pronësi është tashmë e përcaktuar. Të luftosh kundër saj është mënyra se si një konfigurim që funksionon bëhet diçka që askush nuk mund ta riprodhojë.

Rendi i punës: konfirmoni që tuneli ofron një zgjidhës, shtoni domenin vetëm-rrugëtimi, rilidhuni përmes kontrolleve të profilit, verifikoni lidhjen që përgjigjet, më pas provoni shërbimin në portin e tij. Ai sekuencë lë një rezultat që mund t'ia dorëzoni personit tjetër pa një intervistë të dytë.