Hacker News Digest

В статье рассматривается применение протокола QUIC для решения проблем обхода NAT в P2P-сетях. Авторы отмечают, что за годы было стандартизировано множество протоколов (STUN, ICE, TURN), но процесс остается сложным из-за разнообразия реализаций NAT, которые переписывают IP-адреса пакетов и действуют как файрволы. Основная проблема P2P-сетей — соединение двух узлов, находящихся за разными NAT, независимо от их типа.

Традиционные решения включают использование STUN для обнаружения публичных IP-адресов, ICE для координации пробивания дыр в файрволах и TURN как запасной вариант с ретрансляцией трафика. Авторы предлагают, что QUIC может предоставить комплексное решение для обхода NAT, объединяя все эти функции в одном протоколе и упрощая P2P-сетевое взаимодействие. Это потенциально может заменить несколько отдельных протоколов единой, более эффективной реализацией.

• Обсуждение вращается вокруг проблемы NAT и hole punching при попытке установить прямое P2P соединение, включая то, что некоторые NAT ведут себя непредсказуемо и не позволяют hole punching.
• QUIC и WebTransport обсуждаются как потенциальные решения, но оба стандарта ещё не реализованы в браузерах и их поддержка ограничена.
• Обсуждается, что для P2P соединений не требуется централизованный сервер, но вопрос в том, что сервер может всё ещё потребоваться для ретрансляции трафика в случае, если оба клиента находятся за NAT.
• Поднимается вопрос о том, что TLS сертификаты могут быть самоподписанными и не обязаны быть выданы удостоверяющим центром, что может быть использовано для P2P соединений.
• Участники обсуждают, что хотя WebTransport и был предложен как стандарт для web-платформ, он всё ещё не реализован в браузерах и его будущее неясно.

Крупные компании и хостинг-провайдеры активно внедряют MPTCP (Multipath TCP) для повышения отказоустойчивости и производительности. Например, Google и Meta используют его для распределения трафика между сотовыми сетями и Wi-Fi.

MPTCP позволяет одному соединению использовать несколько сетевых интерфейсов одновременно — например, 5G и Wi-Fi — повышая надёжность: если один путь недоступен, трафик автоматически переключается на другой.

В отличие от обычного TCP, MPTCP также поддерживает многопоточность на уровне ядра Linux, что ускоряет передачу данных. Однако для работы MPTOS требуется поддержка на обоих концах соединения, что пока ограничивает его применение.

• MPTCP и SCTP обсуждаются как способы объединения нескольких каналов, но оба сталкиваются с проблемами: MPTCP требует специфической поддержки в ядре и приложениях, а SCTP не поддерживается большинством маршрутизаторов и имеет проблемы с NAT.
• Пользователи отмечают, что MPTCP теперь имеет улучшенный API и может быть полезен для агрегации полосы пропускания и отказоустойчивости, но его использование ограничено тем, что он не может обрабатывать мобильность (handover) без сохранения старых адресов.
• SCTP, хоть и был предложен как альтернатива, но его поддержка в ядре Linux и в коммерческих устройствах оставляет желать лучшего, и он не может пройти через большинство NAT устройств.
• Вопрос о том, почему SCTP не стал широко используемым, обсуждается в контексте его сложности в прохождении через NAT и отсутствия поддержки в потребительских устройствах.

Magic Wormhole позволяет безопасно передавать файлы и сетевые потоки между компьютерами напрямую или через ретранслятор. Для соединения используется одноразовый код из легко запоминаемых слов, который вводится на обоих концах. Это обеспечивает сквозное шифрование через протокол PAKE (SPAKE2), защищающий от перехвата даже при ретрансляции.

Система автоматически выбирает оптимальный метод подключения: прямое соединение в локальной сети, через публичный IP или ретранслятор при NAT. Помимо передачи файлов, инструмент поддерживает TCP-потоки, интеграцию с Git и совместные терминальные сессии. Реализации включают CLI, GUI для GNOME и мобильное приложение для Android.

• Рекомендации инструментов для передачи файлов между устройствами: Wormhole William и Destiny для Android/iOS, croc (с поддержкой возобновления), localsend (с автоматическим обнаружением в LAN), PairDrop, Tailscale Funnel, Copyparty и другие.
• Обсуждение преимуществ Magic Wormhole: простота использования, безопасность (шифрование через SPAKE2), надежность даже за NAT, удобство для быстрой передачи больших файлов или настройки новых устройств.
• Критика и ограничения: отсутствие возобновления передачи в базовой версии, путаница из-за схожих названий инструментов, ограничения мобильных версий (размер файлов), необходимость ручного ввода кодов на телефонах.
• Технические детали: использование сервера-посредника (mailbox) для установления соединения, попытка прямого P2P-подключения с fallback на реле, обсуждение безопасности коротких паролей и роли сервера в защите от перебора.
• Альтернативы и сравнения: croc предпочтительнее для некоторых из-за скорости и возобновления, Syncthing для постоянной синхронизации, WireGuard для VPN, Web Wormhole для браузеров.

Не выбирайте странные подсети для встраиваемых сетей, используйте VRF

Встраиваемая сеть — это, например, переносная стойка с видео- и сетевым оборудованием, которую подключают к сети площадки. Устройства внутри стойки должны общаться между собой, но перенастраивать их IP при каждой смене локации неудобно. Обычно добавляют маршрутизатор с NAT и используют простую подсеть вроде 10.0.0.0/24. Проблема возникает, если внешняя сеть площадки использует ту же подсеть — возникают конфликты. Люди начинают выбирать «редкие» диапазоны (172.16.42.0/24, 10.11.12.0/24), но конфликты всё равно случаются.

IPv6-решение
Использовать link-local адреса fe80::/64 и протоколы обнаружения (avahi). Маршрутизатор раздаёт маршруты, и внутренние устройства получают доступ в интернет. Недостаток: большинство встраиваемых устройств (аудио- и видеомикшеры) не поддерживают IPv6. Аналогичный IPv4-механизм APIPA (169.254.0.0/16) не даёт шлюза и интернета.

Универсальное решение
Вместо экзотических подсетей ограничьте «странность» настройками маршрутизатора. Используйте VRF (Virtual Routing and Forwarding), чтобы изолировать внутреннюю сеть и избежать конфликтов, не меняя адресацию устройств.

• Docker случайно выбирает подсеть RFC1918, которая может конфликтовать с корпоративной сетью; это частая проблема в AWS и вызывает головную боль при отладке.
• IPv6-поддержка всё ещё редка, поэтому обсуждают альтернативы: IPv4 link-local, CGNAT 100.64.0.0/10, «benchmark» 198.18.0.0/15 и даже выделение «мертвой» подсети.
• Некоторые просто используют VRF или VLAN, чтобы изолировать трафик и избежать конфликтов, хотя это требует понимания маршрутизации.
• Участники сомневаются, что IPv4 исчезнет скоро: у провайдеров его много, а стимул перехода на IPv6 минимален без внешнего давления.