Зашто DNS одговор не успева на безстатежном ивичном фајерволу VPN-а

Тунел је активан, клијенти стижу до VPN домаћина, а домаћин не може ништа да реши. Његови сопствени одлазни упити чисто напуштају интерфејс, па је квар на повратном путу: на узводној ивици која филтрира долазни саобраћај без икаквог памћења шта је домаћин управо послао. Дозвола за порт тунела уопште не описује ту размену. Одговор на DNS упит је засебан ток, и ако је ивица без стања, ништа му није дало дозволу да се врати.

Две размене нису иста размена

Запишите торке и грешка постаје очигледна. Одредишни порт захтева постаје изворни порт одговора, што је супротно од онога што већина замишља када додаје долазно правило за порт 53:

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

Долазно правило које захтева одредишни порт 53 описује саобраћај упућен DNS слушаоцу који ради на домаћину, а то је потпуно друга услуга. Те адресе су документациони примери, а изворни порт клијент бира за сваки упит, тако да то није вредност коју можете копирати у правило и очекивати да ће наставити да ради.

Безстатежна ивица наспрам статежног фајерфола домаћина

Безстатежни ивични филтер процењује сваки долазни пакет према својој листи правила без икакве табеле веза иза себе. Одлазни упит који је успешно изашао не ствара никакву дозволу за свој долазни одговор, јер уређај нема запис да је упит икада постојао. Статежни фајерфол домаћина је супротност: његово праћење веза препознаје повратни саобраћај дозвољене размене и пропушта га без правила за одговор. Обе границе постоје на типичном путу, и обе морају да пропусте предвиђени пакет.

Поређење је важно јер два уређаја не успевају на различит начин. Статежни фајерфол који одбије одговор бележи одбацивање; безстатежна ивица га одбија тихо, зато домаћин једноставно дочека истек времена.

Градите дозволу око протокола, а не броја порта

Ограничите правило на стварне адресе резолвера, одредишни домаћин и политику пријемног порта коју производ подржава. Имајте на уму и TCP пут DNS-а, јер велики одговор или враћање због скраћивања премешта размену на TCP и правило само за UDP то неће покрити. Ако ивица подржава статежни преглед за дефинисан ток, дајте му предност над ручно написаним правилом за одговор, јер статежни пут аутоматски следи портове које је клијент изабрао.

Затим потврдите који производ на путу стварно филтрира саобраћај. Документовани опсег ивице за IPv4 не успоставља политику за IPv6, а саобраћај унутар провајдера можда никада не прође кроз исти филтер.

Зашто дозвола било ког изворног порта 53 није поправка

Правило које прихвата све што тврди да има изворни порт 53 је правило које прихвата оно што пошиљалац напише у поље заглавља. Број порта не аутентификује пошиљаоца и не доказује да је корисни терет важећи одговор, па правило шири изложеност домаћина без тога да решавање учини поузданијим. Задржите ограничења извора и задржите клијентове сопствене провере одговора, укључујући случајност изворног порта, уместо да их искључите ради поједностављења листе приступа.

Ако је резолвер услуга коју контролишете, ограничење на његове адресе је довољно. Ако је јавни резолвер, ограничите на адресе које сте одобрили и запишите их у коментар правила.

Проверавајте на правој граници, у правом смеру

Снимите на домаћину и на ивици исти упит и упоредите торке, а не бројеве пакета. Упит видљив на обе стране без одговора видљивог на страни домаћина упућује на долазни филтер; упит видљив само на страни домаћина упућује на рутирање или сам резолвер. Поновите са TCP упитом ако имате дозволу само за UDP, јер то је празнина коју први тест не може да види.

Поправка овога довршава DNS размену која домаћину заиста треба. Она не претвара домаћин у јавни резолвер, не одобрава прослеђене VPN токове и не доказује да је DNS био узрок неке неповезане проблема са тунелом.