* У меня такая ситуация: *
Боб хочет взаимодействовать с Алисой напрямую (зашифрованное взаимодействие, без промежуточного сервера, который будет пересылать его пакеты). Оба находятся за NAT. У Алисы есть общедоступный адрес ipv6 и адрес ipv4 (за несимметричным NAT). У Боба есть адрес ipv4 с переадресацией портов ipv4, но у Алисы нет переадресации портов для своего трафика ipv4. Боб знает IPv6-адрес Алисы и ее текущий IPV4-адрес, а Алиса знает публичный IPV4-адрес Боба. Боб хочет инициировать сетевое взаимодействие с Алисой напрямую, но частный IPv4-адрес Алисы недоступен за NAT. Боб должен попытаться связаться с IPv6-адресом Алисы со своего IPv4-адреса. Как Боб может добраться до Алисы? 6to4 - решение?
* Исходная информация: *
Алиса и Боб оба используют одноранговое приложение (которое я разрабатываю). Это одноранговое приложение при запуске пытается открыть порты IPv4 Алисы и Боба. Библиотека открытия портов uPnP (универсальный plug and play) работает на маршрутизаторе Боба с его интернетом ipv4, но не на маршрутизаторе Алисы с двойным интернетом ipv4 / ipv6. Вот почему у Боба открыты порты ipv4, когда он запускает приложение, а у Алисы - нет. Допустим, STUN и TURN недоступны - Боб хочет инициировать прямое соединение с Алисой без использования промежуточного сервера (STUN или другого) для облегчения соединения. Как бы Боб поступил так (при условии, что и Алиса, и Боб оба находятся за NAT, и ни один из их NAT не является симметричным NAT)?
* БОЛЬШОЕ РАЗЪЯСНЕНИЕ *
Боб буквально не отправляет пакеты ipv6 с адреса ipv6. В Интернете Алисы есть как ipv4, так и ipv6 (Алиса может подключаться к веб-сайтам с поддержкой / поддержкой ipv6, таким как Google, и она может подключаться к сайтам, которые предлагают только ipv4). Поэтому, если Алиса набирает в Google «какой у меня IP», она получает адрес IPv6 (попробуйте). Но если она пойдет в http://checkip.amazonaws.com (попробуйте и это - ipv6 не включен), она получит только свой адрес ipv4. Мне было интересно, может ли Боб обернуть пакеты ipv6, предназначенные для Алисы, своими пакетами ipv4 (ipv6 over ipv4 или 6to4) в качестве средства обхода NAT.
* Что я имею в виду под словом «без посредников»? *
Я не имею в виду пересылку TURN или любую другую форму пересылки, при которой промежуточный сервер получает копию пакета, предназначенного для Алисы, и пересылает эту копию Алисе.
* Если у Алисы есть адрес ipv4, а Боб и Алиса знают адреса ipv4 друг друга, почему Боб просто не отправляет пакеты со своего адреса ipv4 на адрес Алисы? *
У Боба есть перенаправление портов, а у Алисы нет перенаправления портов. Даже если Алиса ожидает соединения на частном порте 30000, когда Боб отправляет пакет со своего общедоступного порта 30000 на свой адрес ipv4 на открытый порт 30000 Алисы на ее адрес ipv4, NAT Алисы не пропустит пакет Боба.
То, что вы просите, невозможно без кого-то посередине. Вы можете использовать IPv6 только в том случае, если обе стороны имеют IPv6, и вы не можете принимать входящие соединения за NAT без переадресации портов.
Требование отсутствия посредников можно трактовать по-разному. И какая именно интерпретация используется, действительно имеет значение, потому что определенные интерпретации в сочетании с другими требованиями приведут к невозможному набору требований.
Рассмотрение того, что интернет-провайдер, обеспечивающий подключение к Интернету для каждой конечной точки, является третьей стороной, на которую нельзя положиться, очевидно, слишком строго для обеспечения связи. Но даже если мы включим маршрутизаторы в путь IPv4 между конечными точками в инфраструктуре, на которую мы можем положиться, это останется невозможным из-за других требований:
Если мы интерпретируем требование отсутствия посредников, чтобы просто сказать, что основная часть трафика не должна маршрутизироваться через третью сторону, но допустимо привлекать третью сторону к установке соединения, тогда это возможно.
Боб может отправить пакет третьей стороне на общедоступном IPv4-адресе с просьбой отправить сообщение на IPv6-адрес Алисы с просьбой подключиться обратно к Бобу через IPv4. В любом новом проекте протокола, рассчитанном на будущее, я бы использовал соединение IPv4 между конечными точками только как средство туннелирования пакетов IPv6, а затем позволил бы всем более высоким уровням иметь дело только с IPv6.
Какие протоколы туннеля IPv6 могут подойти
Давайте рассмотрим следующие варианты получения Бобом IPv6-адреса, который можно использовать для массового транспорта: 6to4, 6rd, 6in4, native, Teredo, домашний.
Отсутствие поддержки со стороны ISP Боба немедленно исключает 6rd и native.
Требование отсутствия третьей стороны исключает 6in4, если один из провайдеров на прямом пути между Алисой и Бобом не предлагает 6in4, который Боб может использовать. Такая служба вряд ли будет существовать на прямом пути, и если бы она потребовала дополнительной настройки со стороны Боба, я думаю, вы бы захотели.
Требование отсутствия третьей стороны также означает, что 6to4 и Teredo потенциально проблематичны.
Все, что использует протокол 41, трудно пройти через NAT. И даже если вы можете заставить его работать через NAT, в большинстве случаев он может поддерживать только одного пользователя за NAT. Учитывая, что Алиса даже не может получить переадресацию портов, мы можем в значительной степени исключить использование сквозного протокола 41. Таким образом, возможна сквозная связь 6in4 и 6to4.
Для настройки чего-либо, основанного на протоколе 41, требуются права администратора на конечной точке, на которой вы это настраиваете. Это еще один аргумент против 6in4, 6rd и 6to4. Туннель на основе UDP можно встроить прямо в приложение, поскольку порты UDP могут быть открыты непривилегированным приложением.
Использование 6to4 на стороне Боба с собственным IPv6 на стороне Алисы означает, что необходимо использовать реле. Поскольку я утверждал, что Алиса не может отправлять пакеты протокола 41, Алисе придется полагаться на ретранслятор, управляемый кем-то другим. Если повезет, у провайдера Алисы есть реле, но на него нельзя полагаться. В обратном направлении не намного лучше, поскольку интернет-провайдер Боба вообще не поддерживает IPv6, у них тоже вряд ли будет какой-либо ретранслятор. Таким образом, 6to4 в этом сценарии, вероятно, будет иметь проблемы в обоих направлениях. Это исключает 6to4.
Из стартового списка у нас остается Teredo или доморощенный. Если Боб использует Teredo, его первый пакет будет отправлен на сервер Teredo, выбранный Бобом. Поскольку Боб может выбрать, какой сервер Teredo использовать, использование стороннего сервера будет менее проблематичным. Если третья сторона окажется ненадежной, Боб может просто переключиться на другую.
Но это касается только первого пакета от Боба Алисе. Обратный путь немного проблематичен. Если вы просто полагаетесь на маршрутизацию по умолчанию, то ответный трафик от Алисы будет идти на ретранслятор Teredo, управляемый провайдером Алисы, или, что более вероятно, ретранслятор третьей стороны. Если провайдер Алисы развернул достаточно ретрансляторов Teredo для обработки трафика своих клиентов, и они обращают внимание на стабильность ретрансляторов, то в этом сценарии Teredo будет надежным. Однако такие интернет-провайдеры встречаются редко.
Алиса может решить запустить собственное реле. Но связь между клиентом Teredo (работающим на компьютере Боба) и реле Teredo (работающим на компьютере Алисы) обычно открывается от клиента к реле. Это направление, которое у вас не сработало.
В Teredo есть устаревший режим работы, в котором соединения могут открываться в другом направлении от ретранслятора к клиенту.
Это означает, что вы можете встроить клиент Teredo непосредственно в свое программное обеспечение, и в конкретной настройке, которую вы описываете, использовать этот устаревший режим на компьютере Боба. На стороне Алисы ваше программное обеспечение работает на собственном IPv6-адресе, но в то же время ваше программное обеспечение должно обнаруживать одноранговые узлы, использующие этот устаревший режим Teredo, и при обнаружении попытки отправить пакеты напрямую одноранговому узлу с использованием встроенного ретранслятора Teredo непосредственно в ваше программное обеспечение.
Вы должны обратить внимание на одно предостережение: когда первый эхо-запрос от Боба отправляется через сервер Teredo Алисе, он будет обрабатываться стеком IPv6 в ОС на компьютере Алисы, а не вашим приложением. Это означает, что будет сложно перенаправить ответ через встроенное реле Teredo в ваше программное обеспечение.
Если вы воспользуетесь этим подходом, я настоятельно рекомендую вам написать свое программное обеспечение для поддержки отправки пакетов либо через вашу сборку в коде Teredo, либо через обычный маршрут. И периодически проверяйте оба способа отправки пакетов, чтобы всегда использовать самый надежный из двух.
Немного иронично, что из всех стандартных протоколов, которые я могу придумать, тот, который лучше всего соответствует вашим требованиям, оказывается устаревшим вариантом Teredo. Тем более что Teredo обычно считается ненадежным. Тем не менее, я искренне верю, что при конкретных обстоятельствах, которые вы описываете, его можно заставить работать надежно.
Возможное домашнее решение
Вы можете выбрать префикс / 80 адресного пространства RFC 4193 для использования в своем приложении и использовать последние 16 бит адреса IPv6 для внедрения адреса IPv4 и номера порта конечной точки туннеля.
При таком подходе у Боба будет IPv6-адрес, на который Алиса сможет отправлять пакеты. Проблема с этим подходом заключается в том, что Боб не сможет отправить пакеты IPv6 Алисе до того, как достигнет первого пакета IPv6 от Алисы.
Кроме того, это доморощенные серверы, которые могли бы ретранслировать эти пакеты от Боба Алисе. Таким образом, этот собственный подход будет похож на Teredo, за исключением того, что проблема недостаточной инфраструктуры будет усилена.
Исходя из этого, я думаю, что если вы хотите использовать собственное решение, вы с большей вероятностью получите хороший результат, если возьмете Teredo в качестве отправной точки и попытаетесь его улучшить, а не создавать собственное решение с нуля.