Чаму адказ 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 быў прычынай нейкай незвязанай праблемы тунэля.