Kial la DNS-respondo malsukcesas ĉe sentatuda VPN-randa fajroŝirmilo

La tunelo estas aktiva, klientoj povas atingi la VPN-gastiganton, kaj la gastiganto povas solvi nenion. Ĝiaj propraj elirantaj demandoj pure forlasas la interfacon, do la paneo estas sur la revena vojo: ĉe supra rando, kiu filtras envenantan trafikon sen ia memoro pri tio, kion la gastiganto ĵus sendis. Permesi la tunelan pordon tute ne priskribas tiun interŝanĝon. La respondo al DNS-demando estas aparta fluo, kaj se la rando estas sentatuda, nenio rajtigis ĝin reveni.

La du interŝanĝoj ne estas la sama interŝanĝo

Notu la opojn kaj la eraro fariĝas evidenta. La cela pordo de la demando fariĝas la fonta pordo de la respondo, kio estas la malo de tio, kion plej multaj imagas, kiam ili aldonas envenantan regulon por pordo 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Envenanta regulo, kiu postulas celan pordon 53, priskribas trafikon adresitan al DNS-auskultanto ruliĝanta sur la gastiganto, kio estas tute alia servo. Tiuj adresoj estas dokumentaj ekzemploj, kaj la fontan pordon elektas la kliento por ĉiu demando, do ĝi ne estas valoro, kiun vi povas kopii en regulon kaj atendi, ke ĝi daŭre funkcios.

Sentatuda rando kontraŭ stattena gastiganta fajroŝirmilo

Sentatuda randa filtrilo pritaksas ĉiun envenantan paketon laŭ sia regullisto sen ia konekta tabelo malantaŭ ĝi. Eliranta demando, kiu sukcese foriris, kreas neniun permeson por sia envenanta respondo, ĉar la aparato havas neniun rikordon, ke demando iam okazis. Stattena gastiganta fajroŝirmilo estas la malo: ĝia konekta spurado rekonas la revenan trafikon de permesita interŝanĝo kaj trapasigas ĝin sen regulo por la respondo. Ambaŭ limoj ekzistas sur tipa vojo, kaj ambaŭ devas permesi la celatan paketon.

La komparo gravas, ĉar la du aparatoj paneas malsame. Stattena fajroŝirmilo, kiu rifuzas la respondon, protokolas forĵeton; sentatuda rando rifuzas ĝin silente, kaj tial la gastiganto simple finiĝas per tempolimo.

Konstruu la permeson ĉirkaŭ la protokolo, ne ĉirkaŭ pordan numeron

Limigu la regulon al la realaj adresoj de la solvilo, al la cela gastiganto kaj al la ricev-porda politiko, kiun la produkto subtenas. Memoru ankaŭ la TCP-vojon de DNS, ĉar granda respondo aŭ retroigo pro tranĉado movas la interŝanĝon al TCP kaj regulo nur por UDP ne kovros ĝin. Se la rando subtenas stattenan inspektadon por difinita fluo, preferu ĝin al mane skribita responda regulo, ĉar la stattena vojo aŭtomate sekvas la pordojn elektitajn de la kliento.

Poste konfirmu, kiu produkto sur la vojo fakte filtras la trafikon. Dokumentita IPv4-randa amplekso ne starigas IPv6-politikon, kaj provizanto-interna trafiko eble neniam trapasas la saman filtrilon.

Kial permesi ajnan fontan pordon 53 ne estas solvo

Regulo, kiu akceptas ion ajn asertantan fontan pordon 53, estas regulo, kiu akceptas tion, kion sendanto skribas en kaplinan kampon. La pordan numeron ne aŭtentikigas la sendanton kaj ne pruvas, ke la utilaĵo estas valida respondo, do la regulo vastigas la elmeton de la gastiganto sen igi la solvadon pli fidinda. Konservu fontajn limigojn kaj konservu la proprajn respondajn kontrolojn de la kliento, inkluzive de fontporda hazardigo, anstataŭ malŝalti ilin por simpligi alirliston.

Se la solvilo estas servo, kiun vi kontrolas, limigi al ĝiaj adresoj sufiĉas. Se ĝi estas publika solvilo, limigu al la adresoj, kiujn vi aprobis, kaj notu ilin en la komento de la regulo.

Kontrolu ĉe la ĝusta limo, en la ĝusta direkto

Kaptu ĉe la gastiganto kaj ĉe la rando la saman demandon, kaj komparu la opojn anstataŭ la paketajn nombrojn. Demando videbla ambaŭflanke sen respondo videbla ĉe la gastiganta flanko indikas la envenantan filtrilon; demando videbla nur ĉe la gastiganta flanko indikas la vojigon aŭ la solvilon mem. Ripetu kun TCP-demando, se vi havas permeson nur por UDP, ĉar tio estas la breĉo, kiun la unua testo ne povas vidi.

Ripari ĉi tion kompletigas DNS-interŝanĝon, kiun la gastiganto vere bezonas. Ĝi ne faras la gastiganton publika solvilo, ne rajtigas plusenditajn VPN-fluojn kaj ne pruvas, ke DNS estis la kaŭzo de iu neligita tunela problemo.