Чому адреса вашого 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 переміщує пакети між мережами, на які ви вже були авторизовані; він не публікує сервіс і не перетворює ноутбук на хост, обернений в інтернет. Завдання — вирішити, який із трьох рівнів змінювати, і тунель рідко буває одним із них.