Зошто 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 бил причина за некаков неповрзан проблем со тунелот.