Kāpēc DNS atbilde neizdodas bezstāvokļa VPN malas ugunsmūrī

Tunelis ir aktīvs, klienti sasniedz VPN resursdatoru, bet resursdators neko nevar atrisināt. Tā paša izejošie vaicājumi tīri atstāj saskarni, tāpēc kļūme ir atpakaļceļā: augstākā malā, kas filtrē ienākošo datplūsmu, neatceroties, ko resursdators tikko nosūtīja. Tuneļa porta atļaušana šo apmaiņu nemaz neapraksta. Atbilde uz DNS vaicājumu ir atsevišķa plūsma, un, ja mala ir bezstāvokļa, nekas tai nav devis atļauju atgriezties.

Abas apmaiņas nav viena un tā pati apmaiņa

Pierakstiet kortēžus, un kļūda kļūst acīmredzama. Pieprasījuma mērķa ports kļūst par atbildes avota portu, kas ir pretējs tam, ko vairums iedomājas, pievienojot ienākošo noteikumu portam 53:

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

Ienākošais noteikums, kas pieprasa mērķa portu 53, apraksta datplūsmu, kas adresēta DNS klausītājam, kurš darbojas resursdatorā, un tā ir pavisam cita pakalpojuma. Šīs adreses ir dokumentācijas piemēri, un avota portu klienta izvēlas katram vaicājumam, tāpēc tas nav lielums, ko varētu nokopēt noteikumā un sagaidīt, ka tas turpinās darboties.

Bezstāvokļa mala pret stāvokļa resursdatora ugunsmūri

Bezstāvokļa malas filtrs novērtē katru ienākošo paketi pret savu noteikumu sarakstu bez savienojumu tabulas aiz tā. Izejošais vaicājums, kas veiksmīgi izgāja, nerada nekādu atļauju savai ienākošajai atbildei, jo ierīcei nav ieraksta, ka vaicājums kādreiz ir noticis. Stāvokļa resursdatora ugunsmūris ir pretējs: tā savienojumu izsekošana atpazīst atļautas apmaiņas atgriešanās datplūsmu un palaiž to garām bez noteikuma atbildei. Abas robežas pastāv tipiskā ceļā, un abām ir jāatļauj paredzētais pakets.

Salīdzinājums ir svarīgs, jo abas ierīces nokļūst kļūmē dažādi. Stāvokļa ugunsmūris, kas atsaka atbildi, reģistrē nomešanu; bezstāvokļa mala to atsaka klusi, tāpēc resursdators vienkārši nonāk līdz taimautam.

Veidojiet atļauju ap protokolu, nevis porta numuru

Ierobežojiet noteikumu ar īstajām atrisinātāja adresēm, mērķa resursdatoru un produkta atbalstīto uztveršanas porta politiku. Paturiet prātā arī DNS TCP ceļu, jo liela atbilde vai atkāpšanās saīsināšanas dēļ pārvieto apmaiņu uz TCP, un noteikums tikai UDP to neaptvers. Ja mala atbalsta stāvokļa pārbaudi noteiktai plūsmai, dodiet tai priekšroku pret roku rakstītu atbildes noteikumu, jo stāvokļa ceļš automātiski seko klienta izvēlētajiem portiem.

Pēc tam pārliecinieties, kurš produkts ceļā faktiski filtrē datplūsmu. Dokumentēts IPv4 malas apjoms nenosaka IPv6 politiku, un pakalpojumu sniedzēja iekšējā datplūsma, iespējams, nekad nešķērso to pašu filtru.

Kāpēc jebkura avota porta 53 atļaušana nav labojums

Noteikums, kas pieņem visu, kas apgalvo, ka tam ir avota ports 53, ir noteikums, kas pieņem to, ko sūtītājs ieraksta galvenes laukā. Porta numurs neautentificē sūtītāju un nepierāda, ka lietderīgā slodze ir derīga atbilde, tāpēc noteikums paplašina resursdatora pakļautību, nepadarot atrisināšanu uzticamāku. Saglabājiet avota ierobežojumus un paša klienta atbildes pārbaudes, tostarp avota porta randomizāciju, tā vietā, lai tās izslēgtu piekļuves saraksta vienkāršošanai.

Ja atrisinātājs ir jūsu kontrolēts pakalpojums, pietiek ar ierobežošanu uz tā adresēm. Ja tas ir publisks atrisinātājs, ierobežojiet ar apstiprinātajām adresēm un pierakstiet tās noteikuma komentārā.

Pārbaudiet pareizajā robežā, pareizajā virzienā

Uztveriet resursdatorā un malā to pašu vaicājumu un salīdziniet kortēžus, nevis pakešu skaitu. Vaicājums, kas redzams abās pusēs bez atbildes resursdatora pusē, norāda uz ienākošo filtru; vaicājums, kas redzams tikai resursdatora pusē, norāda uz maršrutēšanu vai pašu atrisinātāju. Atkārtojiet ar TCP vaicājumu, ja jums ir atļauja tikai UDP, jo tieši tā ir plaisa, ko pirmais tests nevar saskatīt.

Šī labošana pabeidz DNS apmaiņu, kas resursdatoram patiešām nepieciešama. Tas nepadara resursdatoru par publisku atrisinātāju, neļauj pārsūtītas VPN plūsmas un nepierāda, ka DNS bija kādas nesaistītas tuneļa problēmas cēlonis.