Трафік кліента VPN і стан міжсеткавага экрана: вонкавы і ўнутраны паток

Рукі VPN завяршаюцца, кліент атрымлівае адрас, а служба за шлюзам усё роўна адхіляе злучэнне. Міжсеткавы экран часта робіць менавіта тое, што яму сказалі. Ён дазволіў вонкавы паток тунеля, а гэта іншы пакет, чым злучэнне праграмы пасля дэкапсуляцыі. З гэтага вынікаюць два рашэнні: які паток вы дазваляеце і ці адсочвае мяжа стан наогул.

Пакуль вы іх не раздзялілі, кожная змена правіла — здагадка.

Міжсеткавы экран бачыць два розныя пакеты

Да дэкапсуляцыі міжсеткавы экран бачыць трафік, адрасаваны канчатковаму пункту VPN: вонкавы паток UDP да слухача. Пасля дэкапсуляцыі перададзены пакет нясе ўнутраны адрас кліента і прызначэнне службы.

Дазвол для вонкавага патоку не дае права на перададзенае злучэнне TCP. Іх могуць ацэньваць у розных ланцугах, на розных інтэрфейсах і з рознымі адрасамі пасля трансляцыі.

Параўнайце захопы з раўназначных пазіцый з абодвух бакоў. Захоп на краі тунеля і захоп на серверы паказваюць розныя картэжы для аднаго сеансу.

Рашэнне першае: дазволіць тунель ці службу

Калі кліенту патрэбны толькі сам канчатковы пункт VPN, вонкавага дазволу можа хапіць. Калі яму патрэбна служба за шлюзам, патрэбны дазвол на перадачу для гэтага прызначэння і порта. Правіла тунеля, якое дазваляе яшчэ і службу, — гэта рашэнне праекта, якое трэба назваць, а не выпадковасць.

Трымайце дыяпазон кліента і абсяг службы вузкімі. Дазвол ад падсеткі тунеля да ўсёй лакальнай сеткі — гэта рашэнне давяраць кожнаму хасце, а не кароткі шлях для адной праграмы.

Запішыце абодва правілы асобна. Правіла тунеля і правіла службы адмаўляюць па-рознаму і адладжваюцца рознымі доказамі. Калі адно адмаўляе, вы ведаеце, які ўзровень правяраць першым.

Рашэнне другое: з адсочваннем стану ці без яго на кожнай мяжы

Правіла ўсталяванага патоку можа прапускаць адказы для дазволенага абмену, але яе паводзіны залежаць ад прадукту. Група бяспекі ў воблаку звычайна вядзе стан; спіс кантролю падсеткі часта не вядзе стан і патрабуе яўнай апрацоўкі ў абодвух кірунках. Не мяркуйце, што кожная мяжа на шляху ставіцца да стану аднолькава. Пералічыце кожную мяжу і пазначце яе з адсочваннем стану ці без яго, перш чым праектаваць правілы.

Калі правіла змянілася, існуючыя адсочваемыя патокі могуць працягваць працу, а новыя — адмаўляць, або наадварот. Гэтая розніца — карысная падказка, а не прычына скідваць увесь стан злучэнняў на жывым шлюзе.

Праверце свежым кантраляваным запытам і паглядзіце адпаведныя лічыльнікі. Чысты тэст лепш за разбуральны скід. Запішыце назву лічыльніка ў запіс пра змену, каб наступны тэст выкарыстаў тыя ж доказы.

Праверце зваротны шлях пры той жа палітыцы

Адпраўце новы запыт ад кліента да службы і праверце лічыльнікі напрамку і звароту на кожнай мяжы. Пацвердзіце, што адказ ідзе па чаканым шляху, асабліва калі ўдзельнічае трансляцыя.

Трымайце меркаваны дыяпазон кліента і абсяг службы вузкімі і праверце зваротны шлях пры тым жа наборы правілаў, які дазволіў запыт. Правіла, якое працуе толькі таму, што стары паток яшчэ адкрыты, не з'яўляецца працоўным правілам.