Permesi DNS nur tra via VPN-resolvilo: paŝa traktado

Sekvu unu nomserĉon de la momento, kiam vi tajpas ĝin. La retumilo demandas la operaciumon, la operaciumo demandas la resolvilon elektitan de sia politiko, kaj la demando forlasas la aparaton tra iu interfaco kun iu transporto. Via VPN-projekto diras, ke la respondo devas veni de difinita resolvilo laŭ difinita vojo. La breĉo inter tiuj du asertoj estas tio, kion vi agordas kaj poste devigas.

Paŝo 1: nomu la resolvilon kaj la vojon

Skribu tri aferojn antaŭ ol tuŝi fajroŝirmilon: la adreson de la resolvilo, la protokolon kaj pordon, kiujn vi atendas, kaj la interfacon, tra kiu la demando devas eliri. Sen tiu listo regulo estas konjekto pri trafiko, ne plenumo de decido. VPN povas porti aplikajn datumojn dum DNS sekvas apartan aranĝon, kaj tio mem ne estas eraro. Ĝi estas tio, kio okazas, kiam neniu diris al la kliento alion.

Antaŭe nomi la vojon estas la diferenco inter projekto kaj hazardo. Ĝi ankaŭ donas al vi ion por testi poste, ĉar ĉiu observo estas komparebla kun skribita atendo. Konservu tiun liston en la ŝanĝa bileto, ne en ies kapo.

Paŝo 2: starigu la politikon tie, kie ĝi vere loĝas

La elekto de resolvilo apartenas al la kliento: la reta agordo de la operaciumo, la propraj agordoj de la VPN-kliento aŭ administrata retumila politiko. Starigu ĝin unue tie, per la mekanismo, kiun la platformo subtenas, ĉar fajroŝirmilo ne povas devigi klienton elekti resolvilon, pri kiu ĝi neniam aŭdis. Ĉe kliento kun dividita tunelo, diru eksplicite, kiuj domajnoj iras al la interna resolvilo. En administrata aro, retumila politiko ofte estas la sola levilo por DoH, ĉar la retumilo povas elekti sian propran ĉifritan resolvilon sendepende de la sistema agordo.

Se vi preterlasos tion kaj iros rekte al la fajroŝirmilo, vi ricevos regulon, kiu permesas la ĝustan resolvilon, plus klienton, kiu neniam uzas ĝin. La regulo ŝajnas ĝusta kaj la protokoloj de la resolvilo restas malplenaj, konfuza paro por sencimigado. Agordu unue la elekton, poste devigu ĝin.

Paŝo 3: devigu la vojon mallarĝe

Nun aldonu la retan permeson por la permesata vojo: la adreson de la resolvilo, la protokolon kaj pordon, kaj la interfacon, tra kiu ĝi devas eliri. Tenu la regulon limigita al tiu resolvilo anstataŭ permesi ĉiun eliran DNS. La tri vojoj sube estas tiuj, kiujn moderna kliento povas preni, kaj nur la unuan kovras regulo por pordo 53.

Bloki DoH kaj DoT estas legitime; supozi, ke regulo por pordo 53 jam blokis ilin, ne estas. Retumilo uzanta DoH solvas nomojn laŭ vojo, kiun via regulo neniam priskribis, kaj aplikaĵo kun propra resolvilo faras la samon. Skribu ĉiun vojon, kiun vi intencas permesi, kaj ĉiun, kiun vi intencas rifuzi. Regulo, kiu ne nomas vojon, ne decidis pri ĝi.

Paŝo 4: sekvu privatajn kaj publikajn nomojn

Dividita DNS intence sendas nur privatajn nomspacojn al interna resolvilo dum publikaj nomoj iras aliloken, do pli ol unu resolvilo en la projekto ne estas liko. Liko estas demando, kiu devintus iri al via resolvilo kaj aperas aliloke, aŭ neatingebla celita vojo, kiu igas la klienton silente retropaŝi. Tiuj du kazoj estas tion, kion vi serĉu. Sekvu internan kaj publikan nomon laŭ la celita politiko kaj notu, kiu resolvilo respondis al ĉiu.

Testejo, kiu raportas vian resolvilon, estas signo, ne pruvo, ĉar ĝi vidas nur la demandojn, kiuj atingis ĝin. Kaptu la demandon ĉe la klienta flanko, kiam vi bezonas scii, kiun vojon ĝi efektive prenis, kaj komparu ambaŭ observojn. Kiam ili malkongruas, vi trovis retropaŝon, kiun neniu dokumentis.

Se la adreso de la resolvilo estas ĝusta sed neatingebla, la problemo estas en enkursigo aŭ filtrado, ne en la politiko. Spuru la demandon al tiu adreso kaj konfirmu, ke la respondo revenas per la atendata interfaco antaŭ ol ŝanĝi ajnan agordon de la resolvilo.

Paŝo 5: konservu vojon reen

Antaŭ ol streĉi la DNS-aliron ĉe la enirejo, konfirmu metodon de restaŭro, kiu ne dependas de nomresolvado. Rompita resolvilo malfaciligas atingi ĉiun riparilon, inkluzive tiujn, per kiuj vi malfarus la ŝanĝon. Tenu lokan konzolon aŭ eksterbandan vojon malfermita ĝis la nova politiko estos pruvita. Forigu ĝin nur post kiam la politiko travivis rekonekton.

Post rekonekto aŭ ĝisdatigo de retumila politiko, denove inspektu la efektivan staton, ĉar ambaŭ povas ŝanĝi la resolvilon sen ŝanĝi vian regulon. La postulo estas konata ricevanto kaj protektita vojo por la demandoj, ne trankviliga etikedo de resolvilo en unu ekrankopio. La RFC 8484 specifoj pri DNS over HTTPS estas la referenco por la ĉifrita vojo, kiun via porda regulo ne vidas.