Zašto DNS odgovor pada na stateless VPN edge firewallu

Tunel je aktivan, klijenti mogu doći do VPN hosta, a host ne može ništa razriješiti. Njegovi vlastiti odlazni upiti čisto napuštaju interfejs, pa je kvar na povratnom putu: na uzvodnom edgeu koji filtrira dolazni saobraćaj bez ikakvog pamćenja šta je host upravo poslao. Dozvola za port tunela uopšte ne opisuje tu razmjenu. Odgovor na DNS upit je zaseban tok, i ako je edge stateless, ništa mu nije dalo dozvolu da se vrati.

Dvije razmjene nisu ista razmjena

Zapišite tuple i greška postaje očigledna. Odredišni port zahtjeva postaje izvorni port odgovora, što je suprotno od onoga što većina zamisli kada dodaje dolazno pravilo za port 53:

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

Dolazno pravilo koje zahtijeva odredišni port 53 opisuje saobraćaj upućen DNS slušaocu koji radi na hostu, a to je sasvim druga usluga. Te adrese su dokumentacijski primjeri, a izvorni port klijent bira za svaki upit, pa to nije vrijednost koju možete kopirati u pravilo i očekivati da će nastaviti raditi.

Stateless edge nasuprot stateful host firewallu

Stateless edge filter procjenjuje svaki dolazni paket prema svojoj listi pravila bez ikakve tablice veza iza sebe. Odlazni upit koji je uspješno otišao ne stvara nikakvu dozvolu za svoj dolazni odgovor, jer uređaj nema zapis da se upit ikada dogodio. Stateful host firewall je suprotnost: njegovo praćenje veza prepoznaje povratni saobraćaj dozvoljene razmjene i propušta ga bez pravila za odgovor. Obje granice postoje u tipičnom putu, i obje moraju propustiti namjeravani paket.

Poređenje je važno jer dva uređaja padaju na različit način. Stateful firewall koji odbije odgovor bilježi odbacivanje; stateless edge ga odbija tiho, zato host jednostavno dočeka istek vremena.

Gradite dozvolu oko protokola, a ne broja porta

Ograničite pravilo na stvarne adrese resolvera, odredišni host i politiku prijemnog porta koju proizvod podržava. Imajte na umu i DNS-ov TCP put, jer veliki odgovor ili vraćanje na skraćivanje prebacuje razmjenu na TCP i pravilo samo za UDP to neće pokriti. Ako edge podržava stateful inspekciju za definisan tok, dajte joj prednost pred ručno napisanim pravilom za odgovor, jer stateful put automatski slijedi portove koje je klijent odabrao.

Zatim potvrdite koji proizvod na putu stvarno filtrira saobraćaj. Dokumentovan IPv4 edge opseg ne uspostavlja IPv6 politiku, a saobraćaj unutar provajdera možda nikada ne prolazi kroz isti filter.

Zašto dozvola bilo kojeg izvornog porta 53 nije popravka

Pravilo koje prihvata sve što tvrdi da ima izvorni port 53 je pravilo koje prihvata šta god pošiljalac napiše u polje zaglavlja. Broj porta ne autentifikuje pošiljaoca i ne dokazuje da je sadržaj valjan odgovor, pa pravilo širi izloženost hosta bez toga da razrješavanje učini pouzdanijim. Zadržite ograničenja izvora i klijentove vlastite provjere odgovora, uključujući randomizaciju izvornog porta, umjesto da ih isključite radi pojednostavljenja pristupne liste.

Ako je resolver usluga koju kontrolišete, ograničavanje na njegove adrese je dovoljno. Ako je javni resolver, ograničite na adrese koje ste odobrili i navedite ih u komentaru pravila.

Provjeravajte na pravoj granici, u pravom smjeru

Snimite na hostu i na edgeu za isti upit, i uporedite tuple, a ne brojeve paketa. Upit vidljiv na obje strane bez odgovora vidljivog na strani hosta ukazuje na dolazni filter; upit vidljiv samo na strani hosta ukazuje na rutiranje ili sam resolver. Ponovite sa TCP upitom ako imate dozvolu samo za UDP, jer to je praznina koju prvi test ne može vidjeti.

Popravka ovoga dovršava DNS razmjenu koja hostu zaista treba. Ona ne pretvara host u javni resolver, ne odobrava proslijeđene VPN tokove i ne dokazuje da je DNS bio uzrok neke nepovezane problema s tunelom.