Miért vall kudarcot a DNS-válasz egy állapotmentes VPN-él tűzfalon

Az alagút él, az ügyfelek elérik a VPN-gazdagépet, a gazdagép mégsem tud semmit feloldani. A saját kimenő lekérdezései tisztán elhagyják az interfészt, tehát a hiba a visszaúton van: egy felsőbb élen, amely szűri a bejövő forgalmat, anélkül hogy emlékezne arra, mit küldött a gazdagép az imént. Az alagút portjának engedélyezése egyáltalán nem írja le ezt a cserét. A DNS-lekérdezésre adott válasz külön folyam, és ha az él állapotmentes, semmi sem adott neki engedélyt a visszatérésre.

A két csere nem ugyanaz a csere

Írja fel a tuple-öket, és a hiba nyilvánvalóvá válik. A kérés célportja a válasz forrásportja lesz, ami éppen az ellenkezője annak, amit a legtöbben elképzelnek, amikor bejövő szabályt adnak az 53-as porton:

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

Egy bejövő szabály, amely célportként 53-at követel, a gazdagépen futó DNS-figyelőnek címzett forgalmat ír le, ami teljesen más szolgáltatás. Azok a címek dokumentációs példák, a forrásportot pedig minden lekérdezéshez az ügyfél választja, tehát ez nem olyan érték, amelyet be lehet másolni egy szabályba, és elvárható, hogy tovább működjön.

Állapotmentes él szemben állapotkövető gazdagép-tűzfallal

Az állapotmentes élszűrő minden bejövő csomagot a szabálylistájához mér, anélkül hogy mögötte kapcsolattábla lenne. Egy sikeresen kimenő lekérdezés nem hoz létre engedélyt a bejövő válaszához, mert az eszköznek nincs feljegyzése arról, hogy valaha is történt lekérdezés. Az állapotkövető gazdagép-tűzfal ennek az ellenkezője: kapcsolatkövetése felismeri egy engedélyezett csere visszirányú forgalmát, és a válaszra vonatkozó szabály nélkül is átengedi. Mindkét határ jelen van egy tipikus útvonalon, és mindkettőnek engedélyeznie kell a szándékolt csomagot.

Az összehasonlítás azért fontos, mert a két eszköz másképp hibázik. Az állapotkövető tűzfal, amely elutasítja a választ, eldobást naplóz; az állapotmentes él csendben utasítja el, ezért a gazdagép egyszerűen időtúllépésbe fut.

A protokoll köré építse az engedélyt, ne egy portszám köré

Szűkítse a szabályt a valódi feloldó címére, a célgazdagépre és a termék által támogatott fogadóport-szabályzatra. Tartsa szem előtt a DNS TCP-útvonalát is, mert egy nagy válasz vagy a csonkítás miatti visszaesés a cserét TCP-re viszi, és a csak UDP-re vonatkozó szabály nem fedi le. Ha az él támogatja az állapotkövető vizsgálatot egy meghatározott folyamra, részesítse előnyben a kézzel írt válaszszabállyal szemben, mert az állapotkövető útvonal automatikusan követi az ügyfél által választott portokat.

Ezután erősítse meg, melyik termék szűri valóban a forgalmat az útvonalon. Egy dokumentált IPv4-élhatókör nem alapoz meg IPv6-szabályzatot, és a szolgáltató belső forgalma talán soha nem halad át ugyanazon a szűrőn.

Miért nem megoldás bármely forrásport 53 engedélyezése

Az a szabály, amely elfogad mindent, ami forrásport 53-at állít, olyan szabály, amely elfogadja, amit a küldő egy fejlécmezőbe ír. A portszám nem hitelesíti a küldőt, és nem bizonyítja, hogy a hasznos teher érvényes válasz, ezért a szabály szélesíti a gazdagép kitettségét anélkül, hogy megbízhatóbbá tenné a feloldást. Tartsa meg a forráskorlátozásokat és az ügyfél saját válaszellenőrzéseit, beleértve a forrásport véletlenszerűsítését, ahelyett hogy kikapcsolná őket egy hozzáférési lista egyszerűsítése érdekében.

Ha a feloldó az Ön által vezérelt szolgáltatás, elég a címeire korlátozni. Ha nyilvános feloldó, korlátozza az Ön által jóváhagyott címekre, és jegyezze fel őket a szabály megjegyzésében.

A megfelelő határon, a megfelelő irányban ellenőrizzen

Rögzítsen a gazdagépen és az élen ugyanarról a lekérdezésről, és a csomagszámok helyett a tuple-öket hasonlítsa össze. Az a lekérdezés, amely mindkét oldalon látszik, de a gazdagép oldalán nem látszik válasz, a bejövő szűrőre mutat; az a lekérdezés, amely csak a gazdagép oldalán látszik, az útvonalkezelésre vagy magára a feloldóra mutat. Ismételje meg TCP-lekérdezéssel, ha csak UDP-engedélye van, mert éppen ez az a rés, amelyet az első teszt nem lát.

Ennek a javítása befejez egy DNS-cserét, amelyre a gazdagépnek valóban szüksége van. Nem teszi a gazdagépet nyilvános feloldóvá, nem engedélyez továbbított VPN-folyamokat, és nem bizonyítja, hogy a DNS volt valamely független alagútprobléma oka.