Рукацісканне WireGuard працуе, а служба — не

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

Спыніцеся на першым, які не выконваецца, і не дадавайце правілы для астатніх.

Рукацісканне даказвае толькі тунель

Рукацісканне WireGuard усталёўвае ключы паміж аднагодкамі і дазваляе трафік для дыяпазонаў, якія пералічыў кожны з іх. Яно нічога не кажа пра тое, якія працэсы слухаюць на серверы, і нічога пра тое, ці прымае міжсеткавы экран хосця пакеты, адрасаваныя яго ўласным адрасам.

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

Чытайце слухач і маршрут

На кліенце пераканайцеся, што адрас тунеля сервера маршрутызуецца ў тунель. На серверы пераканайцеся, што сокет існуе на адрасе, які выкарыстоўвае кліент, і што працэс за ім — той, які вы мелі на ўвазе.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

Прымяняйце правілы для лакальнага ўводу, а не для пераадрасацыі

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

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

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

Аддзяляйце збоі назвы, памеру і ідэнтычнасці

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

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

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