Split-tunelo ekskludas la retumilon, ne ĝiajn DNS-demandojn

Retumilo ekskludita el la tunelo, paĝo de publika IP konfirmas, ke ĝia trafiko eliras per la hejma konekto, kaj la interna vikio tamen ne malfermiĝas. Nomrezolucio iris aliloken, kaj tiu aliloke estas kutime la solvilo, kiun agordis la VPN. Datapado kaj solvilpado estas apartaj decidoj en la plej multaj split-tunelaj dezajnoj. Kontrolu, kiun la retumilo efektive uzis, antaŭ ol nomi la ekskludon difektita.

Datapado kaj solvilpado disiĝas

Ekskludo forigas la pakaĵojn de aplikaĵo el la tunelo, kio estas decido pri enkursigo kaj fajroŝirmilo sur la datapado. Nomrezolucio estas alia serĉo: procezo demandas la solvilon de la sistemo, kaj tiu solvilo decidas, kiun servilon ricevas la demando.

Ambaŭ povas esti intencaj kaj malsamaj. Labora deplojo povas teni internajn nomspacojn ĉe la kompania solvilo dum ĝi sendas elektitan publikan retumadon ekster la tunelon, ĝuste ĉar internaj nomoj ne solviĝas aliloke. La konfuza kazo estas la malo: publika retejo fiaskas ĉar la retumilo neniam demandis la solvilon, kiun la deplojo atendis. Notu la padon kaj la solvilon aparte, kaj duono de la argumentoj malaperas.

Trovu, kiu procezo faras la demandon

Retumilo povas uzi la solvilon de la sistemo, sian propran ĉifritan DNS-servon, aŭ solvilon, kiun la operaciumo atribuas por reto. La unua sekvas la platforman regulon, la dua tute preterpasas tiun regulon, kaj la tria dependas de tio, al kiu ligilo la demando estas enkursigita.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Legu la validan agordon antaŭ testado: kiuj ligiloj portas DNS-servilojn, kiujn nomspacojn ili pretendas, kaj ĉu regulo por unuopa nomo superas la defaŭlton. En Linux split DNS uzas enkursigajn domajnojn; en Windows la tabelo de nomrezolucia regulo faras la saman taskon por nomspacoj. Neniu el ili videblas el paĝo de lika testo.

Decidu, kiu solvilo vidas kiun nomon

Skribu la celatan mapadon antaŭ ol ŝanĝi ion: internaj nomoj al la kompania solvilo, publikaj nomoj al tiu servo, kiun la regulo permesas, kaj esceptoj kun posedanto. Sen tiu listo, ĉiu etikedo de la lika testo fariĝas regula disputo, kiun neniu povas fini.

Poste kontrolu la propran agordon de la retumilo, ĉar ĉifrita DNS en retumilo aplikiĝas antaŭ ol la operaciumo ricevas la demandon. Uzanto, kiu ŝaltis ĝin por ĉirkaŭiri kaptan portalon, silente superis la solvilon, kiun elektis la deplojo. Tio estas decido pri agordo, ne liko, kaj ĝi meritas decidon anstataŭ bloka listo.

Ne reskribu ĉiun DNS-kampon por igi unu testan etikedon verda. La etikedo priskribas unu demandon de unu procezo en unu momento.

Kontrolu demandon kaj konekton aparte

Testu la du padojn sendepende. La konekta testo montras la datapadon, kaj la solvila testo montras, kiu ricevis la nomon.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Demandu ankaŭ eksplicite la solvilon, por ke fiasko atribuu al la servilo, ne al la pado. Poste restartigu la retumilon kaj ripetu, ĉar aplikaĵoj kaŝmemoras negativajn respondojn kaj malnova fiasko ŝajnas daŭra.

Post aprobita ŝanĝo, notu la datapadon kaj la ricevanton de la solvilo kiel du apartajn liniojn kun la dato. Se la konduto revenos ĉe la sekva rekonekto, la profilo, kiu ĝin provizas, estas tio, kion oni riparu, ne la retumilo.