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