OpenWrt politika enkursigado: la ĉeno, kiu kaptas lokan DNS

Klientoj en la LAN solvas tra la tunelo, kaj la propraj serĉoj de la enkursigilo silente ne faras tion. Paketaj ĝisdatigoj, tempsinkronigo kaj dinamika DNS ĉiuj eliras per la ordinara ligilo, dum ĉiu plusendita demando prenas la VPN-on, kaj nenio en la interfaco sugestas, ke ekzistas du malsamaj vojoj. La klarigo ne estas cimo en la politiko sed demando, kiu hoko vidas la paketon. Du fluoj, unu solva adreso, kaj nur unu el ili transiras la enkursigilon. Apartigi ilin estas la tuta riparo.

Du fluoj, unu solva adreso

La unua fluo estas tiu, kiun homoj imagas. Kliento demandas la solvilon de la enkursigilo, la solvilo plusendas supren, kaj tiu plusendita paketo pasas la enkursigilon survoje eksteren. Tiu paketo videblas al io ajn, kio observas plusenditan trafikon.

La dua fluo neniam alvenas de ie ajn. La enkursigilo kreas ĝin, do estas nek enira paketo nek plusenda paŝo por kongrui.

Ambaŭ povas celi la saman solvan adreson, kaj ĝuste tial la diferenco facile maltrafiĝas. Sama celo, malsama origino, malsama ĉeno. Kiam vi vidos la originon, la resto de la diagnozo sekvas.

Plusenditaj kaj loke kreitaj paketoj eniras malsame

Plusendita trafiko estas taksata kiam ĝi alvenas de alia interfaco. Politik-enkursigaj pakoj elmontras tion kiel prerouting-ĉenon, kaj regulo metita tie vidas ĉiun paketon transirantan la enkursigilon. Tial klientaj serĉoj kondutas ĝuste kiel la politiko priskribas, kaj tial la enkursigilo ignoras ĝin. La regulo ne estas malĝusta, ĝi simple alkroĉiĝas al hoko, kiun la enkursigilo neniam atingas. Movu ĝin, kaj la sama kongruo komencas funkcii.

Loke kreita trafiko estas kreata de procezo sur la enkursigilo kaj eniras la eligan vojon anstataŭe. Ĝin enkursigas la propra decido de la enkursigilo kaj ĝi renkontas politikon nur se la politiko kovras tiun ĉenon. Ne estas enira interfaco por kongrui nek plusenda decido por observi.

Tio estas eco de kie paketoj naskiĝas, ne de iu ajn aparta paketo. Regulo skribita por unu ĉeno simple havas neniun opinion pri la alia. Neniu kvanto de regulagordado tion ŝanĝas.

Elektu la eligan ĉenon, poste mallarĝigu la kongruon

La riparo estas ligi la saman intencon ankaŭ al la eliga ĉeno, aŭ movi la regulon tien kiam la propraj demandoj de la enkursigilo estas tio, kio gravas al vi. En OpenWrt-agordo konstruita sur politik-enkursiga pako, tio signifas elekti output anstataŭ prerouting en la ĉena agordo de la regulo. Konservu ambaŭ regulojn se ambaŭ populacioj bezonas kovron.

Poste mallarĝigu tion, kion la regulo kongruas. Celaj solvaj adresoj sur la pordo, kiun la solvilo efektive uzas, estas multe pli malgranda decido ol sendi ĉion, kion la enkursigilo kreas, en la tunelon.

Tenu la du regulojn eksplicitaj anstataŭ provi skribi unu, kiu kovras ambaŭ ĉenojn. Apartaj reguloj estas pli facile legeblaj, kaj ili ebligas al vi malŝalti la vojon de la enkursigilo sen ĝeni klientan trafikon dum vi sencimigas. Ili ankaŭ igas la nombrilojn signifoplenaj unuope.

Tenu la propran transporton de la tunelo ekster la regulo

La ekstera konekto de la tunelo ankaŭ estas kreata de la enkursigilo. Regulo, kiu sendas ĉiun loke kreitan trafikon en la tunelon, enkursigos la tunelon tra si mem, kaj ĝi tute ne leviĝos.

Administra aliro estas la dua viktimo. Administraj sesioj originitaj de la enkursigilo, aŭ respondoj al ili, povas esti tiritaj en la tunelon per tro larĝa loka regulo kaj fariĝi neatingeblaj de la LAN.

Ekskludu la finpunkton de la tunelo el la kongruo, kaj tenu la regulon limigita al la solvaj adresoj. Tio sufiĉas por la DNS-postulo kaj estas sufiĉe malgranda por pripensi.

Testu ambaŭ populaciojn, ne unu

Observu la enkursigilon fari sian propran demandon kaj notu, kiu interfaco portis ĝin. Ripetu la serĉon de LAN-gastiganto kaj notu la vojon, kiun tiu prenis. Nombriloj sur la politikaj reguloj igas ambaŭ respondojn videblaj sen diveni.

Traktu la rezultojn kiel du trovojn. Kliento, kiu solvas tra la tunelo, diras nenion pri la enkursigilo, kaj enkursigilo, kiu solvas ĝuste, diras nenion pri kliento sur alia aŭskultanto. Skribu ilin kiel apartajn liniojn en la ŝanĝregistro.

Kontrolu ankaŭ la pordon: regulo kongruanta celan pordon 53 maltrafas solvilon atingitan per DNS over TLS sur 853 aŭ HTTPS-finpunkto. Kongruu la transporton, kiun la agordita supra fluo efektive uzas, kaj la liko fermiĝas pro la ĝusta kaŭzo.