Proč odpověď DNS selhává na bezstavovém okrajovém firewallu VPN

Tunel je navázán, klienti se dostanou k hostiteli VPN a hostitel nedokáže nic přeložit. Jeho vlastní odchozí dotazy čistě opouštějí rozhraní, takže porucha je na zpáteční cestě: na nadřazeném okraji, který filtruje příchozí provoz, aniž by si pamatoval, co hostitel právě odeslal. Povolení portu tunelu ten výměnný tok vůbec nepopisuje. Odpověď na dotaz DNS je samostatný tok, a pokud je okraj bezstavový, nic jí nedalo oprávnění vrátit se.

Obě výměny nejsou tatáž výměna

Zapište si ntice a chyba bude zřejmá. Cílový port požadavku se stane zdrojovým portem odpovědi, což je opak toho, co si většina lidí představí, když přidává příchozí pravidlo pro port 53:

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

Příchozí pravidlo, které vyžaduje cílový port 53, popisuje provoz adresovaný naslouchající službě DNS na hostiteli, což je úplně jiná služba. Tyto adresy jsou dokumentační příklady a zdrojový port volí klient pro každý dotaz, takže to není hodnota, kterou byste mohli zkopírovat do pravidla a čekat, že bude dál fungovat.

Bezstavový okraj versus stavový firewall hostitele

Bezstavový okrajový filtr vyhodnocuje každý příchozí paket podle svého seznamu pravidel bez jakékoli tabulky spojení za sebou. Odchozí dotaz, který úspěšně odešel, nevytváří žádné oprávnění pro svou příchozí odpověď, protože zařízení nemá záznam, že by k nějakému dotazu kdy došlo. Stavový firewall hostitele je opak: jeho sledování spojení rozpozná zpětný provoz povolené výměny a propustí ho bez pravidla pro odpověď. Obě hranice existují v typické cestě, a obě musí povolit zamýšlený paket.

Srovnání je důležité, protože obě zařízení selhávají různě. Stavový firewall, který odpověď odmítne, zapíše zahození; bezstavový okraj ji odmítne tiše, a proto hostitel prostě vyprší.

Stavějte povolení kolem protokolu, ne kolem čísla portu

Omezte pravidlo na skutečné adresy resolveru, cílového hostitele a politiku přijímacího portu, kterou produkt podporuje. Mějte na paměti i cestu TCP pro DNS, protože velká odpověď nebo návrat při zkrácení přesouvá výměnu na TCP a pravidlo jen pro UDP ji nepokryje. Pokud okraj podporuje stavovou inspekci pro definovaný tok, dejte jí přednost před ručně psaným pravidlem pro odpověď, protože stavová cesta automaticky sleduje porty zvolené klientem.

Potom ověřte, který produkt v cestě provoz skutečně filtruje. Dokumentovaný rozsah okraje pro IPv4 nezakládá politiku IPv6 a provoz uvnitř poskytovatele nemusí tímto filtrem nikdy projít.

Proč povolení libovolného zdrojového portu 53 není oprava

Pravidlo, které přijme cokoli, co tvrdí, že má zdrojový port 53, je pravidlo, které přijme, co odesílatel napíše do pole hlavičky. Číslo portu neověřuje odesílatele a nedokazuje, že užitečné zatížení je platná odpověď, takže pravidlo rozšiřuje vystavení hostitele, aniž by překlad učinilo spolehlivějším. Zachovejte omezení zdroje i vlastní kontroly odpovědí na straně klienta, včetně randomizace zdrojového portu, místo abyste je vypínali kvůli zjednodušení přístupového seznamu.

Pokud je resolver služba, kterou ovládáte, omezení na jeho adresy stačí. Pokud je to veřejný resolver, omezme se na adresy, které jste schválili, a poznamenejte je do komentáře pravidla.

Ověřujte na správné hranici a správným směrem

Zachyťte na hostiteli i na okraji stejný dotaz a porovnejte ntice, nikoli počty paketů. Dotaz viditelný na obou stranách bez odpovědi viditelné na straně hostitele ukazuje na příchozí filtr; dotaz viditelný jen na straně hostitele ukazuje na směrování nebo na samotný resolver. Zopakujte to s dotazem TCP, pokud máte povolení jen pro UDP, protože to je mezera, kterou první test nevidí.

Oprava tohoto dokončí výměnu DNS, kterou hostitel skutečně potřebuje. Neudělá z hostitele veřejný resolver, nepovolí předávané toky VPN ani nedokáže, že DNS byl příčinou nějakého nesouvisejícího problému s tunelem.