Обхід NAT

NAT traversal — це набір методів, які дозволяють двом пристроям за окремими NAT встановлювати прямі з’єднання. Без нього однорангові протоколи повністю залежать від серверів ретрансляції, що збільшує вартість і затримку. Завдяки цьому два телефони за домашніми маршрутизаторами можуть спілкуватися безпосередньо через Інтернет протягом більшої частини життя з’єднання.

Основна проблема

NAT (див. нашу статтю NAT) перетворює вихідні з’єднання з приватних IP-адрес на спільну публічну IP-адресу. Вхідні з’єднання без існуючого відображення не мають призначення — NAT не знає, на який внутрішній пристрій пересилати. Два пристрої з NAT не можуть ініціювати підключення один до одного; обидва мають бути ініціатором.

STUN: "як виглядає моя загальнодоступна IP-адреса?"

STUN (Утиліти проходження сеансу для NAT), RFC 5389, — це простий протокол, який дозволяє пристрою виявляти свою загальнодоступну IP-адресу/порт. Пристрій надсилає запит STUN на публічний сервер STUN; сервер відповідає з адресою джерела, яку він помітив (що є зовнішнім відображенням NAT). Сервери

STUN не мають статусу та можуть працювати вільно. Google керує stun.l.google.com:19302; існує багато інших. Вартість запуску одного є незначною, оскільки протокол обміну невеликий.

Найпростіший шаблон проходження NAT

Для двох пристроїв A і B за NAT:

1. A запитує STUN, дізнається, що його загальнодоступне відображення X.
2. B запитує STUN, дізнається його загальнодоступне відображення — Y.
3. A та B обмінюються цими адресами через сигнальний канал (поза смугою, як веб-сокет через сервер програми).
4. A починає надсилати пакети до Y; B починає надсилати на X.
5. Обидва NAT бачать вихідні пакети на адресу іншого, створюють необхідні відображення, а потім вхідні пакети до цих відображень пересилаються всередину.
6. Прямий шлях A-B тепер працює.

Це hole штампування. Це працює, коли обидва NAT є достатньо дозволеними (повний конус або обмежений конус). Типи

NAT і їх можливість пробивання отворів

• Full-cone NAT. Найбільш дозволений — будь-який зовнішній хост може надсилати на зіставлений публічний IP/порт. Проколювання отворів працює легко.
• NAT з обмеженим конусом. Надсилати можуть лише зовнішні хости, з якими раніше було встановлено зв’язок. Перфорація працює після того, як обидві сторони надіслали принаймні один пакет.
• Port-restricted-cone NAT. Обмежено хостом І портом. Перфорація все ще працює, але вимагає, щоб обидві сторони надсилали на точний порт.
• Симетричний NAT. Найбільш обмежений — зовнішній порт відрізняється для кожного призначення, тому відображення, яке бачить STUN, не передбачає відображення для прямого однорангового трафіку. Зазвичай пробивання отворів не вдається.

Симетричні NAT поширені в розгортаннях NAT операторського рівня та деяких корпоративних брандмауерах. Однорангові вузли за симетричними NAT часто не можуть підключатися напряму; їм потрібне реле.

TURN: коли пробивання отворів не вдається

TURN (перехід за допомогою реле навколо NAT) , RFC 5766, є запасним варіантом. Якщо пряме з’єднання неможливо, обидва вузли підключаються до сервера TURN, який ретранслює трафік між ними. Сервери TURN бачать весь медіа-трафік — вартість пропускної здатності значно вища, ніж STUN.

Для служб відеодзвінків (Zoom, Google Meet) використання серверів TURN є основними операційними витратами. За оцінками, 15-30% дзвінків використовують ретранслятори TURN, незважаючи на спроби максимізувати прямі з’єднання.

ICE: поєднання всього

ICE (Встановлення інтерактивного з’єднання) , RFC 8445, — це структура, яка використовує STUN, TURN і пряме з’єднання разом. Процес:

1. Кожен одноранговий вузол збирає всі кандидатські адреси — локальні інтерфейси, відкритий STUN загальнодоступний відображення, резервування реле TURN.
2. Кожен одноранговий вузол обмінюється повними списками кандидатів за допомогою сигналізації.
3. Кожен одноранговий вузол намагається підключитися до всіх комбінацій віддалених кандидати.
4. Перша робоча комбінація стає активним з’єднанням. Прямий є кращим перед ретрансляційним; менша затримка над вищою.
5. З’єднання можна повторно оцінити під час виклику, якщо умови зміняться.

WebRTC використовує ICE для однорангових з’єднань браузера. Перегляньте нашу статтю WebRTC . Більшість сучасних протоколів P2P використовують ICE або щось подібне.

Пробивання отворів UDP порівняно з пробиванням отворів TCP

UDP пробивання отворів є простим (і стандартним для більшості випадків використання NAT-traversal). Проробити отвір TCP набагато складніше, оскільки TCP вимагає синхронізованого рукостискання; обидві сторони мають ініціювати з’єднання одна з одною одночасно, а NAT мають дозволити результуючий стан. Деякі NAT підтримують це; багато хто цього не робить. Більшість P2P-трафіку, який потребує надійного транспортування, використовує протоколи на основі UDP (QUIC, користувальницькі рівні UDP-over-reliability), а не TCP.

NAT64 і IPv6

IPv6 не потребують NAT — кожен пристрій має адресу, яку можна глобально маршрутизувати. Теоретично IPv6 усуває обхід NAT. На практиці часткове розгортання IPv6 означає, що деякі кінцеві точки працюють лише за IPv4 за NAT, інші доступні за IPv6 напряму, а NAT64/DNS64 транслює між ними. Результатом є складніші рішення щодо маршрутизації, але загалом простіші прямі з’єднання для кінцевих точок із підтримкою IPv6.

Що це означає для користувачів

Зазвичай ви не думаєте про проходження NAT — цим займаються програми. Видимі ефекти:

• Відеодзвінки добре працюють у домашніх мережах (зазвичай прямих або майже прямих)
• Дзвінки за корпоративними брандмауерам іноді погіршуються, оскільки трафік проходить через TURN
• Дзвінки через мобільну мережу іноді мають проблеми, оскільки NAT оператора часто симетричні
• Гра Підбір P2P надійніший у деяких мережах, ніж в інших

Для користувачів, які використовують власні служби: перехід до IPv6 і поступове зменшення симетричного розгортання NAT зробили проходження NAT менш болісним за останнє десятиліття.