Чаму адрас вашага VPN-тунэля не адкрывае уваходны порт
Адрас тунэля пазначае ваш кліент для партнёраў, якія могуць да яго маршрутызаваць, і ніколі не стварае слухача. Праверце прывязку, зваротны маршрут, затым палітыку.
Падключыцеся да офіснай сеткі VPN, запусціце невялікі сэрвіс на порце 8443, адпраўце адрас тунэля калегу і паназірайце, як злучэнне не ўдаецца, пакуль кліент па-ранейшаму паведамляе пра падключэнне. У тунэлі нічога не зламана: адрас выдадзены, сеанс усталяваны, а пакеты, якія павінны былі несці адказ, проста ніколі не прапускаюцца. Выканайце тры праверкі ніжэй па чарзе і спыніцеся на той, што не ўдалося, бо ў кожнай свая папраўка і толькі адна з іх датычыцца VPN.
Пачніце з таго, куды насамрэч прывязаны сокет
Перш чым што-небудзь будзе маршрутызавана, нешта павінна слухаць адрас, да якога можа дабрацца той, хто выклікае. Серверы распрацоўкі — звычайныя вінаватыя, бо многія з іх па змаўчанні прывязваюцца да loopback і прымаюць толькі злучэнні, што паходзяць з той жа машыны. Адрас тунэля не змяняе гэтую прывязку, і аперацыйная сістэма адмовіць у злучэнні задоўга да таго, як VPN будзе задзейнічаны.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Чытайце слупок мясцовага адраса, а не стан. 127.0.0.1:8443 азначае толькі loopback, і папраўка — прывязка да 0.0.0.0 або да самога адраса тунэля. 0.0.0.0:8443 прымае на ўсіх інтэрфейсах, што шырэй, чым большасць мае на ўвазе, калі машына таксама мае публічны адрас; 10.64.7.15:8443 — вузкая версія, якая слухае толькі там, куды можа дабрацца калега. Звярніце ўвагу на імя працэса ў тым жа вывадзе, бо старонні асобнік ад папярэдняга тэсту — частая прычына таго, што порт выглядае адкрытым і адказвае няправільным змесцівам.
Затым спытайце, ці можа што-небудзь маршрутызаваць да гэтага адраса
Адрас тунэля мае сэнс толькі для партнёраў, наладжаных адпраўляць гэты прэфікс у тунэль. Машына калегі мае ўласную табліцу, і калі ў яе няма маршруту да падсеткі тунэля, пакет ідзе да шлюза па змаўчанні і гіне ў месцы, якое не ведае, што адрас існуе. Гэта пытанне маршрутызацыі на баку таго, хто выклікае, а не дазвол на вашым баку.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Сервер паміж двума кліентамі важны не менш. У звычайнай схеме аддаленага доступу кожны кліент адкрывае зыходнае злучэнне да шлюза, і шлюз трымае стан гэтых патокаў, таму адказы вяртаюцца шляхам, які ён ужо ведае. Злучэнне ад аднаго кліента да другога — гэта новы паток, які шлюз павінен прыняць і пераслаць, і многія разгортванні адключаюць гэта наўмысна, каб трымаць кліентаў ізаляванымі адзін ад аднаго. Спажывецкія службы VPN звычайна ізалююць па змаўчанні; карпаратыўныя шлюзы часам дазваляюць гэта для групы.
Праверце кірунак, перш чым нешта змяняць на хасце. Калі адрас тунэля адказвае з самога шлюза, але не ад партнёра, розніца — у наладзе шлюза «ад кліента да кліента», і ніякая праўка мясцовага фаервала гэтага не заменіць.
Нарэшце, знайдзіце палітыку, якая дазваляе паток
Паміж маршрутызаваным пакетам і сэрвісам, які адказвае, стаяць тры ўзроўні палітыкі: рашэнне VPN-сервера аб перасылцы, фаервал хасця і любая хмарная група бяспекі перад інстансам. Усе тры павінны ўзгадніцца, і яны адмаўляюць па-рознаму, таму сімптом у табліцы вышэй карыснейшы за паведамленне пра памылку ў браўзеры.
Фаервал хасця — гэта ўзровень, які забываюць пасля ўдалай прывязкі, бо правіла, што дазваляе порт на інтэрфейсе LAN, не дазваляе яго аўтаматычна на інтэрфейсе тунэля. Правілы, абмежаваныя інтэрфейсам, — правільны дызайн і адначасова звычайная прычына сэрвісу, які працуе з офіса і не працуе з дому. Чытайце абсяг правіла, а не яго нумар порта.
Фільтраванне з улікам стану тлумачыць адваротны выпадак. Зыходнае злучэнне з вашага наўтбука стварае стан, і адказы на яго прапускаюцца без правіла для ўваходных злучэнняў. Злучэнне калегі — цалкам новы паток без стану за ім, таму яму патрэбны яўны дазвол. Гэтая асіметрыя і ёсць прычына, чаму працоўны сеанс браўзера на вашай машыне нічога не кажа пра даступнасць сэрвісу звонку.
Калі адна праверка не ўдалася, мяняйце дызайн, а не тунэль
Калі патрабаванне — каб калега адкрыў ваш мясцовы сэрвіс, сумленны адказ звычайна механізм, пабудаваны для ўваходнага доступу. Зваротны SSH-тунэль — найменшы з іх: ваша машына злучаецца вонкі да хасця, да якога калега ўжо можа дабрацца, і слухач існуе на гэтым хасце.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Рэле патрабуе GatewayPorts clientspecified у сваёй канфігурацыі SSH-сервера, інакш перасланы слухач прывязваецца да loopback на рэле, і калега атрымлівае тую ж адмову, што і раней. Для ўсяго, што жыве даўжэй за паўдня, лепшы інструмент — балансіроўшчык нагрузкі або ingress з праверкай стану і сертыфікатам для апублікаванага імя, а тунэль паміж пляцоўкамі з маршрутамі для абедзвюх падсетак — правільны адказ, калі дзве сеткі сапраўды павінны размаўляць.
Кожны з гэтых дызайнаў робіць экспазіцыю яўнай, і ў гэтым сутнасць. VPN перамяшчае пакеты паміж сеткамі, якія вам ужо дазволены; ён не публікуе сэрвіс і не ператварае наўтбук у хост, адкрыты ў інтэрнэт. Задача — вырашыць, які з трох узроўняў змяніць, і тунэль сярод іх бывае рэдка.