VPN падключаны, але брандмаўэр усё яшчэ блакуе: як зразумець, які бок вінаваты

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

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

Аддзяліце шлях ад палітыкі

Пачніце з формы збою, бо гэта бясплатная інфармацыя. Скід пакета дае тайм-аўт: кліент паўтарае спробу, нічога не вяртаецца, і каманда вісіць, пакуль не здасца. Адмова дае адказ або скід: нешта адказала і сказала «не». Сэрвіс, які не слухае, адмаўляе на самім хасце, без удзелу брандмаўэра.

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

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

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

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

Адна пастка, уласцівая VPN, заслугоўвае асобнай праверкі. У WireGuard AllowedIPs суседняга вузла — гэта адначасова маршрут і крыптаграфічны фільтр: пакет, адрас крыніцы якога не ўваходзіць у дазволены набор вузла, скідаецца да таго, як будзе прачытана хоць адно правіла брандмаўэра. Таму цалкам правільны хост-брандмаўэр можа стаяць за ціхім скідам, які выглядае як палітыка, і выпраўленне — гэта радок канфігурацыі ключа, а не правіла.

Прачытайце палітыку на ўзроўні, які адказвае

Калі шлях правільны, ідзіце па палітыцы ад хоста вонкі і глядзіце на той адзіны ўзровень, чые лічыльнікі рухаюцца:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

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

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

Прачытайце рашэнне шлюза, калі тунэль там сканчаецца

На шлюзе «сайт-сайт» або аддаленага доступу VPN аўтэнтыфікуе карыстальніка, а палітыка дазваляе рэсурс, і гэта асобныя дазволы. Карыстальнік, якога пусцілі ў тунэль, не атрымлівае аўтаматычна доступ да кожнага ўнутранага хоста, і адмова часта прыходзіць ад правіла перасылкі, пакуль сам тунэль здаровы. Такое ж раздзяленне ёсць у IPsec, дзе палітыка бяспекі, якая выбірае трафік, адрозніваецца ад фільтра, які яго прапускае, і менавіта таму дзве рэчы апісаны як розныя механізмы ў RFC 4301.

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

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

Змяніце самае вузкае месца, затым праверце

Супраціўцеся шырокаму рамонту. Адключэнне хост-брандмаўэра, даданне правіла, якое дазваляе ўсё, або прымусовае перанясенне кожнага інтэрфейса ў давераны профіль — кожнае з гэтага прыбірае кантроль, які рабіў сваю справу, і змена перажыве інцыдэнт. Правіла, абмежаванае дыяпазонам крыніцы і патрэбным портам, лягчэй правяраць, лягчэй выдаліць, і яно пакідае астатнюю палітыку машыны цэлай.

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

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Перш чым закрыць пытанне:

  • Маршрут да прызначэння выходзіць праз інтэрфейс тунэлю, і адрас крыніцы супадае з тым, чаго чакае палітыка.
  • Нешта слухае на порце, і адмова або тайм-аўт аднесены да названага правіла, а не выказаны здагадкай.
  • Шлюз перасылае ў абодвух кірунках, і прызначэнне бачыць тую крыніцу, для якой напісаны вашыя правілы.
  • Ніводзін кантроль не быў адключаны, каб тэст прайшоў, і зробленая змена называе адзін дыяпазон крыніцы і адзін порт.

Падобныя артыкулы