Чи може роумінговий клієнт VPN розміщувати сервіс для офісу?

Роумінговий клієнт може обслуговувати офісні системи лише тоді, коли шлюз маршрутизує до нього, політика хоста це дозволяє, а пристрій залишається доступним достатньо довго.

Ваш офісний ноутбук може підключатися з дому і все ж надавати те, що потрібно офісу, але лише коли збігаються три окремі рішення. Тунель — це транспорт, внутрішня адреса — це призначення, а політика вирішує, кому можна постукати. Якщо вважати будь-що з цього повною відповіддю, виникає знайома скарга: хост відповідає на пінги, але застосунок так і не підключається. Ролі не однакові, і різниця саме там, де живе робота над дизайном.

Напрямок підключення нічого не говорить про напрямок сервісу

Коли клієнт запускає тунель, він відкриває шлях, яким після його появи можуть користуватися обидва напрямки. Чи може нове з'єднання увійти з концентратора до цього клієнта — питання політики шлюзу, а не властивість того, хто підключився. Наприклад, на маршрутизованому концентраторі OpenVPN серверу потрібен маршрут до внутрішньої адреси клієнта і пересилання, що допускає стосунки рівноправних вузлів.

Уявіть систему обліку, яка опитує агента на роумінгових ноутбуках, або розробника, якому потрібен тестовий API з домашньої робочої станції. Обидва хочуть, щоб розмову починала офісна сторона, а це протилежне звичайній схемі від клієнта до сервера.

Хостингові продукти віддаленого доступу різняться в цьому місці, і ця відмінність не помилка. Деякі керовані VPN навмисно блокують незапитані з'єднання до підключених клієнтів, бо їхня модель — від клієнта до ресурсу, а не від ресурсу до клієнта. Прочитайте задокументовану архітектуру продукту, перш ніж обіцяти колезі, що його ноутбук може працювати сервером.

Простежте зворотний шлях, перш ніж відкривати порт

Шлях має три частини: маршрут на шлюзі, що вказує на внутрішню адресу клієнта, політика, яка дозволяє конкретного викликача, і служба, що слухає на цілі. Кожна частина відмовляє по-своєму, тому «VPN увімкнено» майже нічого не говорить.

Добра новина в тому, що внутрішньому шляху не потрібна переадресація порту на домашньому маршрутизаторі клієнта. Саме в цьому сенс публікувати службу на адресі тунелю, а не на домашній адресі WAN, де доступність ззовні й правила NAT були б зовсім іншими. Домашній маршрутизатор може також відмовитися робити hairpin для з'єднання з офісу, тож маршрут через WAN відмовляє з причин, не пов'язаних із вашим VPN. Тримання трафіку всередині тунелю уникає обох проблем одразу.

Перевірте й цільову сторону. Служба, прив'язана лише до 127.0.0.1, не може прийняти з'єднання, що надходить на інтерфейс тунелю, хоч би якими правильними були маршрути шлюзу. Правило брандмауера хоста, яке дозволяє порт лише з локальної підмережі, теж відкине офісний трафік, і це правило не залежить від політики VPN вище.

Імена й адреси — це рішення дизайну

Адреса всередині тунелю не стає іменем автоматично. Приватний запис DNS, який ви контролюєте, ясніший за надію на те, що протокол виявлення пройде крізь тунель, бо розв'язання імен через локальний multicast залишається в локальному сегменті й не стає DNS між підмережами.

Стабільність адреси не менш важлива. Якщо клієнти VPN отримують адреси з пулу з короткою орендою, внутрішня адреса ноутбука змінюється між сеансами, і кожна закладка, область брандмауера та перевірка моніторингу, побудовані на ній, тихо ламаються. Використовуйте резервування або задокументований шлях динамічного оновлення.

Узгодьте ім'я з тим, хто володіє ідентичністю VPN, щоб запис, призначення адреси й політика доступу змінювалися разом, а не в трьох окремих заявках.

Тестуйте службу, а не членство

На цілі підтвердьте, що і на якій адресі слухає, потім підтвердьте погляд шлюзу на зворотний шлях:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Тепер перевірте з боку офісу справжнім запитом, а не луною. Успішний curl до служби доводить маршрут, політику й слухача одразу, тоді як успішний ping доводить лише те, що ICMP дозволено. Якщо запит не проходить, ідіть назад трьома частинами, а не розширюйте брандмауер у надії.

Доступність належить до тієї самої розмови. Ноутбук спить, переміщується між мережами й відключається наприкінці дня. Служба, яка має відповідати будь-якої години, належить постійно ввімкненому хосту, а служба за принципом найкращих зусиль може залишитися на клієнті із цим обмеженням записаним.

Публікуйте ресурс свідомо, з іменем, списком дозволених викликачів і власником, і віддалений пристрій стане підтримуваною службою, а не випадковим сервером.

Схожі статті