Доступ к рабочей станции за NAT без проброса порта

Две конечные точки за NAT оператора и заблокированный офисный маршрутизатор не оставляют ни одного входящего порта для проброса, а рефлекс — всё равно попросить его. Лучший вопрос: какая сторона может звонить наружу и какому доступному сервису разрешено нести трафик. Четыре схемы отвечают на этот вопрос по-разному и отказывают по-разному, когда путь заблокирован. Выбор между ними — это сравнение гарантий, а не названий протоколов.

Четыре схемы, четыре разных обещания

Таблица ниже — короткая версия. Читайте средний столбец как обещание, которое можно проверить, а правый — как обещание, которого никто не давал.

Какая строка применима, зависит от задачи, а не от предпочтения. Один сеанс удалённого рабочего стола, одна административная оболочка и доступ ко всей частной подсети — это три требования, которым не нужен один и тот же вход, даже если они случайно касаются одной и той же машины.

Концентратор меняет, кто звонит наружу, а не то, что разрешено

В схеме с маршрутизируемым концентратором удалённый ноутбук и рабочая станция, или шлюз площадки перед ней, открывают каждый исходящий туннель к сервису, доступному обеим сторонам. Ничто не принимает нежданное соединение на маршрутизаторе рабочей станции, и именно поэтому эта схема выживает за NAT и работает даже тогда, когда у площадки нет статического адреса. Затем концентратор маршрутизирует трафик между двумя внутренними адресами согласно своей политике.

Цена в том, что концентратор должен существовать, быть доступен с обеих сторон и кем-то обслуживаться. Фильтрация исходящего трафика должна разрешать транспорт, и сеть, которая его блокирует, сорвёт схему, даже если проброс порта не требовался.

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

Прохождение работает только тогда, когда его реализуют оба стека

Прохождение между равноправными узлами — это возможность конкретной системы, а не настройка, улучшающая VPN. Interactive Connectivity Establishment собирает несколько адресов-кандидатов и проверяет пары, пока одна не сработает: кандидаты хоста на локальных интерфейсах, серверно-отражающие кандидаты, построенные из того, что раскрывает NAT, и ретранслируемые кандидаты, выделенные на ретрансляторе. Один частный адрес сам по себе не путь, потому что другая сторона не может маршрутизировать к нему.

Ретранслируемый случай стоит понять, прежде чем его отбрасывать. RFC 8656 описывает TURN как протокол, в котором клиент просит у сервера ретранслируемый транспортный адрес, а сервер передаёт трафик между этим клиентом и его равноправными узлами. Значит, данные несёт ретранслятор, что существенно отличается от каталога, который только помогает конечным точкам встретиться. Обмен ретранслируемым адресом с другой стороной — это шаг координации, который должно выполнить приложение.

Чего вы не можете обещать — это прямой путь. Симметричный NAT и некоторые корпоративные межсетевые экраны побеждают пробивание отверстий, и когда это происходит, система либо откатывается на ретранслятор, либо отказывает. Вы также не можете сделать вывод, что две транслированные конечные точки никогда не смогут общаться: поддерживаемый стек с ретрансляционным резервом существует именно потому, что они часто могут. Решите, что важнее — доступность или прямая связь, а затем проверьте, какой путь фактически выбрала установка, вместо того чтобы предполагать благоприятный случай.

Брокер уже сети

Когда требование — одно приложение, брокер приложений или обратное соединение, запущенное рабочей станцией, может быть наименьшим ответом. Рабочая станция звонит наружу к брокеру, брокер аутентифицирует удалённого пользователя, и передаётся только этот сеанс приложения. Маршрут в подсеть рабочей станции не создаётся, поэтому компрометация удалённого сеанса не наследует путь к каждому устройству рядом.

У этой узости есть цена: каждому дополнительному приложению нужна своя интеграция, и всё, что приложение предполагает о локальной сети, например файловая папка, которую оно открывает на ближайшем сервере, может оказаться недоступным. Брокеры также концентрируют политику и журналирование в одном месте, что полезно, пока это место не станет сбоем.

Сравните границы доверия, затем проверьте путь

Концентратор, завершающий туннели, может читать трафик, который маршрутизирует. Ретранслятор может нести независимо защищённый обмен, когда приложение шифрует от края до края, а брокер обычно завершает сеанс, который представляет. Установите, где защита действительно заканчивается, прежде чем решать, что две схемы эквивалентны, потому что обе шифруются.

Затем проверьте, до чего рабочая станция действительно достаёт наружу, поскольку каждая схема выше зависит от этого. Выполните это на рабочей станции, заменив имя хоста, которое собираетесь использовать.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Принимайте схему только после того, как нужная удалённая операция удалась под разрешённой учётной записью, неодобренная учётная запись получила отказ, а поведение при недоступном прямом или ретранслируемом пути известно и задокументировано. Включите повторное подключение и обычный контекст запуска рабочей станции, потому что сеанс, начатый в офисе по LAN, не проверяет ничего, от чего зависит удалённый доступ.