Prečo odpoveď DNS zlyháva na bezstavovom okrajovom firewalle VPN

Tunel je nadviazaný, klienti sa dostanú k hostiteľovi VPN a hostiteľ nedokáže nič preložiť. Jeho vlastné odchádzajúce dopyty čisto opúšťajú rozhranie, takže porucha je na spiatočnej ceste: na nadradenom okraji, ktorý filtruje prichádzajúcu premávku bez toho, aby si pamätal, čo hostiteľ práve odoslal. Povolenie portu tunela ten výmenný tok vôbec neopisuje. Odpoveď na dotaz DNS je samostatný tok, a ak je okraj bezstavový, nič jej nedalo oprávnenie vrátiť sa.

Obe výmeny nie sú tá istá výmena

Zapíšte si ntice a chyba bude zrejmá. Cieľový port požiadavky sa stane zdrojovým portom odpovede, čo je opak toho, čo si väčšina ľudí predstaví, keď pridáva prichádzajúce pravidlo pre port 53:

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

Prichádzajúce pravidlo, ktoré vyžaduje cieľový port 53, opisuje premávku adresovanú počúvajúcej službe DNS na hostiteľovi, a to je úplne iná služba. Tie adresy sú dokumentačné príklady a zdrojový port volí klient pre každý dotaz, takže to nie je hodnota, ktorú by ste mohli skopírovať do pravidla a čakať, že bude ďalej fungovať.

Bezstavový okraj verzus stavový firewall hostiteľa

Bezstavový okrajový filter vyhodnocuje každý prichádzajúci paket podľa svojho zoznamu pravidiel bez akejkoľvek tabuľky spojení za sebou. Odchádzajúci dotaz, ktorý úspešne odišiel, nevytvára žiadne oprávnenie pre svoju prichádzajúcu odpoveď, pretože zariadenie nemá záznam, že by k nejakému dotazu kedy došlo. Stavový firewall hostiteľa je opak: jeho sledovanie spojení rozpozná spätnú premávku povolenej výmeny a prepustí ju bez pravidla pre odpoveď. Obe hranice existujú v typickej ceste, a obe musia povoliť zamýšľaný paket.

Porovnanie je dôležité, pretože obe zariadenia zlyhávajú rôzne. Stavový firewall, ktorý odpoveď odmietne, zapíše zahodenie; bezstavový okraj ju odmietne ticho, a preto hostiteľ jednoducho vyprší.

Stavajte povolenie okolo protokolu, nie okolo čísla portu

Obmedzte pravidlo na skutočné adresy resolvera, cieľového hostiteľa a politiku prijímacieho portu, ktorú produkt podporuje. Majte na pamäti aj cestu TCP pre DNS, pretože veľká odpoveď alebo návrat pri skrátení presúva výmenu na TCP a pravidlo len pre UDP ju nepokryje. Ak okraj podporuje stavovú inšpekciu pre definovaný tok, dajte jej prednosť pred ručne napísaným pravidlom pre odpoveď, pretože stavová cesta automaticky sleduje porty zvolené klientom.

Potom overte, ktorý produkt v ceste premávku skutočne filtruje. Dokumentovaný rozsah okraja pre IPv4 nezakladá politiku IPv6 a premávka vnútri poskytovateľa nemusí týmto filtrom nikdy prejsť.

Prečo povolenie ľubovoľného zdrojového portu 53 nie je oprava

Pravidlo, ktoré prijme čokoľvek, čo tvrdí, že má zdrojový port 53, je pravidlo, ktoré prijme to, čo odosielateľ napíše do poľa hlavičky. Číslo portu neoveruje odosielateľa a nedokazuje, že užitočné zaťaženie je platná odpoveď, takže pravidlo rozširuje vystavenie hostiteľa bez toho, aby preklad urobilo spoľahlivejším. Zachovajte obmedzenia zdroja aj vlastné kontroly odpovedí na strane klienta, vrátane randomizácie zdrojového portu, namiesto toho, aby ste ich vypínali kvôli zjednodušeniu prístupového zoznamu.

Ak je resolver služba, ktorú ovládate, obmedzenie na jeho adresy stačí. Ak je to verejný resolver, obmedzte sa na adresy, ktoré ste schválili, a poznamenajte ich do komentára pravidla.

Overujte na správnej hranici a správnym smerom

Zachyťte na hostiteľovi aj na okraji rovnaký dotaz a porovnajte ntice, nie počty paketov. Dotaz viditeľný na oboch stranách bez odpovede viditeľnej na strane hostiteľa ukazuje na prichádzajúci filter; dotaz viditeľný len na strane hostiteľa ukazuje na smerovanie alebo na samotný resolver. Zopakujte to s dotazom TCP, ak máte povolenie len pre UDP, pretože to je medzera, ktorú prvý test nevidí.

Oprava tohto dokončí výmenu DNS, ktorú hostiteľ skutočne potrebuje. Neurobí z hostiteľa verejný resolver, nepovolí preposielané toky VPN ani nedokáže, že DNS bol príčinou nejakého nesúvisiaceho problému s tunelom.