Доступ до робочої станції за NAT без переспрямування порту
Робоча станція без вхідного порту все одно доступна через концентратор, реле або брокер застосунків. Порівняйте, що гарантує кожна схема, перш ніж обрати одну.
Дві кінцеві точки за NAT оператора і заблокований офісний маршрутизатор не залишають жодного вхідного порту для переспрямування, а рефлекс — усе одно попросити його. Краще питання: яка сторона може викликати назовні і якому доступному сервісу дозволено нести трафік. Чотири схеми відповідають на це питання по-різному і зазнають невдачі по-різному, коли шлях заблоковано. Вибір між ними — це порівняння гарантій, а не назв протоколів.
Чотири схеми, чотири різні обіцянки
Таблиця нижче — коротка версія. Читайте середній стовпець як обіцянку, яку можна перевірити, а правий — як обіцянку, якої ніхто не давав.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Який рядок застосовний, залежить від завдання, а не від уподобання. Один сеанс віддаленого робочого столу, одна адміністративна оболонка і доступ до всієї приватної підмережі — це три вимоги, яким не потрібна однакова точка входу, навіть якщо вони випадково стосуються тієї самої машини.
Концентратор змінює, хто викликає назовні, а не те, що дозволено
У схемі з маршрутизованим концентратором віддалений ноутбук і робоча станція, або шлюз майданчика перед нею, відкривають кожен вихідний тунель до сервісу, доступного обом. Ніщо не приймає небажаного з’єднання на маршрутизаторі робочої станції, і саме тому ця схема виживає за 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, не перевіряє нічого, від чого залежить віддалений доступ.