Може ли roaming VPN клиент да хоства услуга за офиса?

Офисният ви лаптоп може да се свърже от вкъщи и пак да предоставя нещо, от което офисът се нуждае, но само когато три отделни решения съвпаднат. Тунелът е транспорт, вътрешният адрес е дестинацията, а политиката решава кой може да почука. Ако приемете което и да е от тях за целия отговор, получавате познатата оплакване: хостът отговаря на ping, но приложението така и не се свързва. Ролите не са еднакви и именно в тази разлика живее дизайнерската работа.

Посоката на свързване не казва нищо за посоката на услугата

Когато клиент стартира тунел, той отваря път, който и двете посоки могат да използват, след като съществува. Дали ново свързване може да влезе от центъра към този клиент е въпрос на политика на шлюза, а не свойство на това кой се е свързал. Например при рутиран център OpenVPN сървърът се нуждае от маршрут към вътрешния адрес на клиента и препращане, което разрешава връзката между peer-ове.

Представете си система за инвентаризация, която опитва агент на roaming лаптопи, или разработчик, на който му трябва тестово API от работна станция вкъщи. И двете искат офисната страна да започне разговора, което е обратното на обичайния модел клиент-към-сървър.

Хостваните продукти за отдалечен достъп се различават тук и разликата не е дефект. Някои управлявани VPN услуги умишлено блокират непоискани връзки към свързани клиенти, защото моделът им е от клиент към ресурс, а не от ресурс към клиент. Прочетете документираната архитектура на продукта, преди да обещаете на колега, че лаптопът му може да действа като сървър.

Проследете пътя на отговора, преди да отворите порт

Пътят има три части: маршрут на шлюза, който сочи към вътрешния адрес на клиента, политика, която разрешава конкретния викащ, и слушаща услуга на целта. Всяка част се проваля по различен начин и затова „VPN-ът работи“ не ви казва почти нищо.

Добрата новина е, че вътрешният път не се нуждае от пренасочване на порт на домашния рутер на клиента. Точно това е смисълът услугата да се публикува на адреса на тунела, а не на домашния WAN адрес, където излагането и NAT правилата биха били напълно различни. Домашният рутер може също да откаже да обърне връзка, идваща от офиса, така че WAN маршрутът се проваля по причини, несвързани с вашия VPN. Задържането на трафика в тунела избягва и двата проблема наведнъж.

Проверете и страната на целта. Услуга, обвързана само с 127.0.0.1, не може да приеме връзка, идваща по интерфейса на тунела, колкото и правилни да са маршрутите на шлюза. Правило на хост-брандмауера, което разрешава порта само от локалната подмрежа, също ще изхвърли офис трафика, и това правило е независимо от VPN политиката над него.

Имената и адресите са дизайнерски решения

Адресът в тунела не е автоматично име. Частен DNS запис, който контролирате, е по-ясен от надеждата протокол за откриване да премине тунела, защото локалното многоадресно разрешаване на имена остава в локалния сегмент и не става 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 е разрешен. Ако заявката се провали, вървете назад през трите части, вместо да разширявате брандмауера и да се надявате.

Наличността принадлежи към същия разговор. Лаптопът заспива, роуминг между мрежи и се изключва в края на деня. Услуга, която трябва да отговаря по всяко време, принадлежи на постоянно включен хост, докато услуга с най-добро усилие може да остане на клиента, ако това ограничение е записано.

Публикувайте ресурса съзнателно – с име, списък на разрешените викащи и собственик – и отдалеченото устройство става поддържана услуга, а не случаен сървър.