VPN-DNS kaptas ĉiun serĉon: ripari dns-priority en NetworkManager

VPN-konekto defaŭlte havas prioritatecon 0 kaj postulas ĉiun domajnon. Starigu negativan prioritatecon por la ordo, poste uzu enkursigajn domajnojn por redoni la reston.

Konektu la oficejan VPN-on kaj subite ĉiu nomserĉo iras al la firmaa resolvilo. Publikaj nomoj ankoraŭ solviĝas, do nenio ŝajnas rompita ĝis loka printila nomo malsukcesas aŭ split-horizon-rikmendo redonas la oficejan adreson. Ĉe iuj Fedora-agordoj okazas la malo: la resolvilo de la provizanto daŭre respondas post kiam la tunelo staras. Ambaŭ estas unu demando — kiu resolvilo posedas ĉi tiun peton — kaj ĉe NetworkManager-sistemoj la respondo loĝas en la DNS-ecoj de ĉiu konekto.

Du konektoj, unu venka resolvilo

Ĉiu konekto deklaras DNS-prioritatecon. Ordinaraj konektoj defaŭlte havas 50 kaj VPN-konektoj 0, kaj la pli malalta valoro venkas. Ĝuste tiu defaŭlto kaŭzas, ke VPN-konekto silente superas la kablan ligilon por ĉiu domajno, kiun ĝi postulas: nulo batas kvindek sen ke iu ajn elektis ĝin.

Prioritateco ordigas la kandidatojn. Ĝi ne limigas, pri kio oni demandas la venkanton. VPN-konekto sen serĉa domajno postulas ĉion, do preferi ĝin ankaŭ sendas publikajn petojn en la tunnelon kaj, en split-tunela dezajno, tien kien la firma resolvilo plusendas.

Prioritateco decidas la ordon, la serĉlisto decidas la posedon

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

La serĉlisto estas la poseddeklaro. Nuda domajno kiel corp.example fariĝas serĉa sufikso kaj enkursiga domajno. La nur-enkursiga formo ~corp.example sendas serĉojn sub tiu sufikso al ĉi tiu konekto sen aldoni la domajnon al mallongaj nomoj. Tiu tildo estas la diferenco inter «demandu ĉi tiun servilon» kaj «demandu ĉi tiun servilon kaj finu mian tajpadon».

Uzu ambaŭ formojn kiam uzantoj tajpas mallongajn gastigantnomojn kaj la rikmendoj ankaŭ adresiĝas per plene kvalifikitaj nomoj. Uzu nur la enkursigan formon kiam vi volas la disigon sen ŝanĝi kiel la resolvilo kompletigas nudan nomon.

Poste faru la preferon eksplicita kaj reaktivigu:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Negativa prioritateco estas la dokumentita maniero diri «preferu ĉi tiun konekton», kaj agordi ambaŭ adresajn familiojn tenas la konduton konsekvenca en gastiganto kun IPv6-konekteco. Ŝanĝi la econ sen reaktivigi la konekton ŝanĝas nenion el tio, kio nun funkcias, tial la sinsekvo finiĝas per eksplicita up.

Lasu systemd-resolved teni la disigon

La defaŭlta dnsmasq-kromaĵo envergŝutas petojn en unu lokan resolvilon, do la apartigo laŭ ligilo restas kruda. systemd-resolved elmontras la disigon laŭ ligilo, kaj resolvectl query nomas la ligilon, kiu respondis.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Post tio la firma ligilo portas corp.example kaj publika resolvilo servas la reston. Kiam serĉo atingas la malĝustan ligilon, la komando nomas la ligilon, kiu respondis al ĝi, kaj scii tion pli valoras ol scii nur la adreson.

Adaptu la DNS-dezajnon al la tunela tipo

Privatecaj dezajnoj, kiuj sendas ĉion tra la tunelo, ne portu disigan liston, ĉar ĝi redonus publikajn nomojn al la loka resolvilo kaj nuligus la intencon. Split-tunelaj dezajnoj bezonas unu: sen ĝi la firma resolvilo vidas ĉiun publikan peton, kaj la agordo rompiĝas en la momento, kiam la tunelo falas.

Poste estas la kill switch, kiu blokas DNS ekster la tunelo. Nomoj solviĝas por la zonoj de la tunelo kaj malsukcesas ĉie alie dum la konekto estas tute sana. La realigeblaj respondoj estas eksplicita permeso por la LAN-resolvilo aŭ loka kaŝmemoro, kiu plusendas nur la firman zonon, kaj ambaŭ estas escepto kun posedanto, ne difekto en la tunelo.

Profilo, kiu reskribas la resolvilan agordon ĉe interfaca starto, kondutas preskaŭ same: post kiam la loka resolvilo estas neatingebla, solviĝos nur la nomoj, kiujn la tunelo konas. Kiun ajn mekanismon aplikiĝas, skribu, kiuj nomoj devas funkcii en ĉiu stato, kaj donu tiun liston al tiu, kiu pritraktas la raportojn.

Kontrolu laŭ ligilo, poste denove post rekonekto

Demandu unu internan kaj unu publikan nomon, kaj rigardu, kien la peto efektive iras. Eskaperkontrola paĝo diras al vi, kiu resolvilo respondis, ne kiun ligilon la sistemo elektis, do ĝi diras nenion pri la ordo, kiun vi ĵus agordis.

Rulu la du petojn denove post malkonekto kaj rekonekto. Prioritatecoj reaplikiĝas kiam konekto aktiviĝas, kaj malnova simbola ligilo povas postvivi ĝisdatigon, kiun neniu memoras. Tion, kion vi volas skribi fine, estas kiu resolvilo posedas kiun sufikson, plus kontrolo, kiu ankoraŭ validas morgaŭ.

Rilataj artikoloj