Kial privataj DNS-nomoj malsukcesas ĉe VPN-klientoj kaj kie kontroli

Vi malfermas tekkomputilon en hotelĉambro, startigas la klienton, tajpas la nomon de la interna dosier-servilo kaj ricevas nenion. La tunelo raportas konektite, kaj ping al adreso en la sama subreto ankoraŭ respondas, do la transporto mem estas en ordo. Nur la nomo malsukcesas, kaj tiu manko mallarĝigas la problemon al du lokoj: kiun solvilon la kliento demandis kaj ĉu la respondo, kiun ĝi ricevis, povas reveni tra la tunelo. Riparu unu kaj preterlasu la alian, kaj la difekto simple translokiĝas.

Antaŭ ol redakti ajnan profilon, kontrolu, kion la kliento faras kun la nomo. En Linukso, resolvectl query files.corp.example montras, kiun ligon kaj kiun solvilon produktis la respondon. En Vindozo, Resolve-DnsName files.corp.example montras la servilon, kiu respondis, kaj la adreson, kiun ĝi resendis.

Legu la respondon antaŭ ol ŝanĝi ion

Se la nomo revenas kiel NXDOMAIN en kelkaj milisekundoj, la peto neniam atingis vian zonon kaj anstataŭe respondis ia publika aŭ hotela solvilo. Se ĝi revenas post longa paŭzo, io forĵetas UDP-porton 53 survoje kaj la kliento finfine faligis sin al rezervo. Se ĝi respondas per la ĝusta adreso sed la konekto ankoraŭ haltas, la serĉado estas en ordo kaj via problemo estas la enkursigado aŭ la servo mem.

Tiu divido en tri ŝparas horon da konjektado. Ĝi ankaŭ diras al vi, ĉu eĉ tuŝi la VPN-on: nomo, kiu solviĝas al la ĝusta privata adreso, jam pruvis la solvilan vojon, do la restanta laboro estas sur la datena vojo.

Disdonu la solvilon el la interno de la tunelo

Klientoj dividiĝas en du grupojn. Al unu la servilo povas doni solvilon dum la establado de la konekto; la alia tenas la agordon en loka dosiero, kiun neniu enirejo povas ŝanĝi malproksime.

OpenVPN apartenas al la unua grupo. En la servilo, push "dhcp-option DNS 10.8.0.53" kaj push "dhcp-option DOMAIN corp.example" vojaĝas laŭ la regkanalo, sed nur se la klienta agordo ankoraŭ havas pull ŝaltita. Mane redaktita kliento portanta pull-filter ignore "dhcp-option" neniam vidos ilin, kaj tiu sola linio klarigas surprize multajn kazojn de „la servilo pelas ĝin, sed mia tekkomputilo malkonsentas“.

WireGuard apartenas al la dua grupo, ĉar la protokolo tute ne havas opcian intertraktadon. La solvilo kaj la serĉa domajno iras en la propran [Interface] blokon de la kliento kiel DNS = 10.8.0.53, corp.example. wg-quick aplikas tion per resolvconf aŭ systemd-resolved, kaj en Vindozo la oficiala kliento instalas NRPT-regulojn, kiuj ekzistas nur dum la tunelo staras: Get-DnsClientNrptPolicy listigas ilin, kio faras ĝin rapida maniero vidi, ĉu la kliento iam ajn aplikis vian dosieron.

IPsec/IKEv2 staras intere. La attr-kromaĵo de strongSwan povas redoni DNS-servilon prenitan el baseno, kaj Vindoza kliento normale akceptas ĝin, sed profilo, kiu fiksas sian propran nomservilon, venkas super ĉio, kion la enirejo ofertas. Ĉe Linuksa kliento la ekvivalenta mana paŝo estas resolvectl dns wg0 10.8.0.53 sekvata de resolvectl domain wg0 '~corp.example'; ambaŭ malaperas kune kun la interfaco, kio estas ĝuste tio, kion vi volas por tunel-limigita agordo.

Limigu la sufikson anstataŭ engluti ĉiun peton

Direkti la tutan solvilan liston de la kliento al via interna servilo estas facila kaj kutime malĝusta. Tiam ĉiu publika nomo solviĝas el la eliro de via datencentro, CDN-oj redonas malproksimajn adresojn, kaj unu paneo de la solvilo kunportas la retumadon de la uzanto.

Sendu enen nur la privatan sufikson. En systemd-resolved, domajno komenciĝanta per ~ estas nur enkursigada, do ~corp.example signifas, ke petoj sub tiu sufikso iras al la serviloj de tiu ligo, dum ĉio alia daŭre uzas la fizikan reton. Vindozo faras la samon per NRPT-reguloj limigitaj al nomspaco, kaj macOS per plia solvila dosiero sub /etc/resolver/.

Multicast-nomoj meritigas propran respondon. .local nomoj estas link-local laŭkonstrue (RFC 6762) kaj punkt-al-punkta tun-interfaco ne portas tiun multicast-grupon, do aldoni publikan solvilon ne publikigos ilin, kaj demandi internan unicast-solvilon pri ili redonas NXDOMAIN. Reflektoro kiel avahi en reflektora reĝimo povas ponti du segmentojn, sed tio estas decido ĉe la servila flanko, kiun neniu kliento povas postuli. Se printilo aŭ NAS devas esti atingebla per nomo, donu al ĝi anstataŭe A-rikordon en via zono.

Pruvu, ke la respondo povas reveni

Ĝusta respondo montranta al neatingebla adreso aspektas ĝuste kiel solvila problemo ĝis vi kontrolas la itineron. Demandu la kernon, kien la respondo irus: ip route get 10.20.5.20 nomas la interfacon kaj, pli utile, la fontadreson, kiun ĝi uzus.

Observu la solvilan adreson mem. Kliento kun DNS = 10.8.0.53 apud AllowedIPs = 10.20.0.0/16 sendas siajn petojn tra la fizika retkarto, kie ili silente mortas, ĉar la solvilo ne kuŝas en iu ajn prefikso, kiun la tunelo postulas. Tiu malkongruo estas la plej ofta unu-kaŭza fiasko en tiu ĉi tuta kampo, kaj ĝi restas nevidebla se vi ne komparas la DNS-agordon kun la permesitaj prefiksoj linio post linio.

Interkovrantaj gamoj kaŭzas la kontraŭan fiaskon. La respondo estas ĝusta, la itinero ekzistas, kaj ĝi montras al la malĝusta gastiganto, ĉar 192.168.0.0/24 hejme estas pli specifa ol la tunela itinero al la sama gamo. Renumeru unu flankon aŭ pelu pli mallarĝan itineron, poste konfirmu la fajroŝirmilon kaj la reiran vojon de la servogastiganto; la notoj de strongSwan pri plusendado kovras la sysctl-flankon de tiu vojo.

Atestiloj estas aparta identec-kontrolo, kiun homoj publikigas al DNS. Se la retumilo raportas nom-miskongruon anstataŭ solvan eraron, la serĉado jam funkciis kaj la SAN en la atestilo estas tio, kion oni riparu. Testu HTTPS kontraŭ la nomo, neniam kontraŭ la nuda IP.

Retestu de la kliento, ne de la enirejo

Testu ene de la aplikaĵo, pri kiu plendas la uzanto, ĉar serĉado en la komandlinio ne pruvas, ke la retumilo sekvas la saman vojon. La sekura DNS de Chrome kaj network.trr.mode de Firefox povas tute preterpasi la sistem-solvilon, kaj kiam ili tion faras, privata nomo aŭ malsukcesas aŭ likas al publika solvilo. Kompari resolvectl query kun mane lanĉita dig @10.8.0.53 files.corp.example diras al vi, kiu el la du okazis.

Poste malkonektu kaj rekonektu antaŭ ol nomi ĝin riparita. Agordoj mane metitaj al interfaco malaperas kune kun la interfaco, kaj profilo, kiu aspektis ĝusta nur pro resta loka ŝanĝo, fiaskos ĉe la sekva ŝargado.

Mallonga kontrol-listo por la sekva maŝino: la nomo solviĝas per la tunela solvilo, la sufikso estas limigita anstataŭ tutmonda, la solvila adreso kuŝas ene de la permesitaj prefiksoj, la gastiganto el la respondo respondas sur la serva pordo, kaj la atestilo kovras la nomon, kiun la uzanto tajpis.