В течение многих лет пресса писала о проблеме, заключающейся в том, что сейчас доступно очень мало адресов IPv4. Но с другой стороны, я использую серверную хостинговую компанию, которая с удовольствием выдает публичные IPv4-адреса за небольшую сумму. А мое частное интернет-соединение поставляется с публичным IPv4-адресом.

Как это возможно? Неужели проблема настолько серьезна, насколько нам хочется верить прессе?

Это очень плохо. Вот список примеров того, что я имею из первых рук, когда потребительские интернет-провайдеры борются с нехваткой адресов IPv4:

• Неоднократные перемещения между блоками IPv4 между городами, приводящие к кратковременным отключениям и сбоям подключения клиентов.
• Сокращение времени аренды DHCP с дней до минут.
• Разрешите пользователям выбирать, хотят ли они преобразование сетевых адресов (NAT) на оборудовании Customer Premise (CPE) или нет, а затем в любом случае включить его задним числом.
• Включение NAT на CPE для клиентов, которые уже использовали возможность отказаться от NAT.
• Снижение ограничения количества одновременно активных адресов управления доступом к среде (MAC), обеспечиваемых CPE.
• Развертывание NAT операторского класса (CGN) для клиентов, которые имели реальный IP-адрес при регистрации в службе.

Все это снижает качество продукта, который интернет-провайдер продает своим клиентам. Единственным разумным объяснением того, почему они будут делать это со своими клиентами, является нехватка адресов IPv4.

Нехватка адресов IPv4 привела к фрагментации адресного пространства, что имеет множество недостатков:

• Административные накладные расходы, которые не только стоят времени и денег, но также подвержены ошибкам и привели к сбоям в работе.
• Широкое использование емкости адресно-ориентированной памяти (CAM) на магистральных маршрутизаторах, которая несколько лет назад приводила к значительным сбоям в работе нескольких провайдеров, когда она выходила за пределы конкретной популярной модели маршрутизаторов.

Без NAT мы не могли бы получить сегодня 3700 миллионов маршрутизируемых адресов IPv4. Но NAT - это хрупкое решение, которое дает вам менее надежное соединение и проблемы, которые трудно устранить. Чем больше слоев NAT, тем хуже будет. Два десятилетия напряженной работы привели к тому, что один уровень NAT в основном работал, но мы уже перешли точку, когда одного уровня NAT было достаточно для решения проблемы нехватки адресов IPv4.

До того, как у нас закончились адреса IPv4, мы (широко) не использовали NAT. У каждого компьютера, подключенного к Интернету, будет свой глобальный уникальный адрес. Когда NAT был впервые представлен, он должен был перейти от предоставления клиентам ISP 1 реального адреса на устройство, которое клиент использовал / владел, к предоставлению 1 клиенту 1 реального адреса. Это решило проблему на некоторое время (годы), в то время как мы должны были перейти на IPv6. Вместо перехода на IPv6 (в основном) все ждали, когда все остальные переключатся, и поэтому (в основном) никто не выкатывал IPv6. Теперь мы снова сталкиваемся с той же проблемой, но на этот раз развертывается второй уровень NAT (CGN), так что интернет-провайдеры могут совместно использовать 1 реальный адрес для нескольких клиентов.

Исчерпание IP-адреса не имеет большого значения, если NAT не является ужасным, в том числе и в случае, когда конечный пользователь не имеет над ним никакого контроля (Carrier Grade NAT или CGN).

Но я бы сказал, что NAT ужасен, особенно в случае, когда конечный пользователь не имеет над ним контроля. И (как человек, занимающийся сетевым проектированием / администрированием, но обладающий степенью разработки программного обеспечения), я бы сказал, что, внедрив NAT вместо IPv6, сетевые администраторы перенесли вес решения по исчерпанию адресов из своей области на конечных пользователей. и разработчики приложений.

Итак (на мой взгляд), почему NAT ужасная, злая вещь, которую следует избегать?

Давайте посмотрим, могу ли я отдать должное объяснению того, что он ломает (и какие проблемы это вызывает, мы настолько привыкли, что даже не осознаем, что это может быть лучше):

• Независимость сетевого уровня
• Одноранговые соединения
• Согласованное наименование и расположение ресурсов
• Оптимальная маршрутизация трафика, хосты знают свой реальный адрес
• Отслеживание источника вредоносного трафика
• Сетевые протоколы, которые разделяют данные и управляют на отдельные соединения

Посмотрим, смогу ли я объяснить каждый из этих пунктов.

Независимость сетевого уровня

Предполагается, что интернет-провайдеры просто пропускают пакеты уровня 3 и не заботятся о том, что находится на уровнях выше этого. Независимо от того, передаете ли вы протокол TCP, UDP или что-то более / более экзотическое (возможно, SCTP? Или даже какой-то другой протокол, который лучше, чем TCP / UDP, но неясен из-за отсутствия поддержки NAT), ваш ISP не должен забота; все это должно выглядеть как данные для них.

Но это не так - не тогда, когда они реализуют «вторую волну» NAT, «Carrier Grade» NAT. Затем они обязательно должны смотреть и поддерживать протоколы уровня 4, которые вы хотите использовать. Сейчас это практически означает, что вы можете использовать только TCP и UDP. Другие протоколы были бы либо просто заблокированы / отброшены (в моем опыте подавляющее большинство случаев), либо просто перенаправлены на последний хост «внутри» NAT, который использовал этот протокол (я видел 1 реализацию, которая делает это). Даже пересылка на последний хост, который использовал этот протокол, не является реальным исправлением - как только два хоста используют его, он ломается.

Я полагаю, что существуют некоторые протоколы замены для TCP и UDP, которые в настоящее время не проверены и не используются только из-за этой проблемы. Не поймите меня неправильно, TCP & UDP были впечатляюще хорошо спроектированы, и это удивительно, как они оба смогли масштабироваться в соответствии с тем, как мы используем Интернет сегодня. Но кто знает, что мы упустили? Я читал о SCTP, и это звучит хорошо, но никогда не использовал его, потому что это было непрактично из-за NAT.

Одноранговые соединения

Это большой. На самом деле, самый большой на мой взгляд. Если у вас есть два конечных пользователя, оба за собственным NAT, независимо от того, какой из них пытается подключиться первым, NAT другого пользователя отбросит свой пакет, и соединение не будет установлено.

Это влияет на игры, голосовой / видеочат (например, Skype), размещение собственных серверов и т. Д.

Есть обходные пути. Проблема заключается в том, что эти обходные пути стоят времени разработчика, времени и неудобств для конечного пользователя или затрат на инфраструктуру обслуживания. И они не надежны и иногда ломаются. (См. Комментарии других пользователей о сбое в работе Skype.)

Одним из обходных путей является переадресация портов, когда вы программируете устройство NAT для переадресации определенного входящего порта на конкретный компьютер за устройством NAT. Есть целые сайты, посвященные тому, как сделать это для всех различных устройств NAT, которые там есть. Смотрите https://portforward.com/ . Это обычно стоит времени конечного пользователя и разочарования.

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

(Помните, что я говорил о развертывании NAT вместо IPv6, перенося вес проблемы с сетевых администраторов на конечных пользователей и разработчиков приложений?)

Согласованное наименование / расположение сетевых ресурсов

Поскольку внутри NAT используется другое адресное пространство, чем снаружи, любая служба, предлагаемая устройством внутри NAT, имеет несколько адресов для доступа к нему, и правильный выбор зависит от того, откуда клиент обращается к нему. , (Это все еще проблема, даже после того, как вы работаете с переадресацией портов.)

Если у вас есть веб-сервер внутри NAT, скажем, на порту 192.168.0.23, порт 80, и ваше устройство NAT (маршрутизатор / шлюз) имеет внешний адрес 35.72.216.228, и вы настроили переадресацию портов для порта TCP 80, теперь ваш Доступ к веб-серверу можно получить через порт 80 192.168.0.23 ИЛИ порт 35.72.216.228. Выбор одного из них зависит от того, находитесь ли вы внутри или за пределами NAT. Если вы находитесь за пределами NAT и используете адрес 192.168.0.23, вы не попадете туда, где ожидаете. Если вы находитесь внутри NAT и используете внешний адрес 35.72.216.228, вы можете получить, куда хотите, если ваша реализация NAT является продвинутой и поддерживает шпильку, но тогда веб-сервер, обслуживающий ваш запрос, увидит запрос как поступающий с вашего устройства NAT. Это означает, что весь трафик должен проходить через устройство NAT, даже если в сети имеется более короткий путь за NAT, и это означает, что журналы на веб-сервере становятся намного менее полезными, поскольку все они перечисляют устройство NAT в качестве источника связь. Если ваша реализация NAT не поддерживает шпильку, вы не получите того, чего ожидали.

И эта проблема усугубляется, как только вы используете DNS. Внезапно, если вы хотите, чтобы все работало должным образом для чего-либо, размещенного за NAT, вы захотите дать разные ответы на адрес службы, размещенной внутри NAT, в зависимости от того, кто спрашивает (DNS с разделенным горизонтом AKA, IIRC). Тьфу.

И все это при условии, что у вас есть кто-то, кто хорошо разбирается в переадресации портов, шпильке NAT и DNS с разделением горизонта. Как насчет конечных пользователей? Каковы их шансы настроить все это правильно, когда они купят потребительский маршрутизатор и некоторую IP-камеру безопасности и хотят, чтобы она «просто работала»?

И это приводит меня к:

Оптимальная маршрутизация трафика, хосты знают свой реальный адрес

Как мы уже видели, даже при использовании расширенного NAT-трафика трафик не всегда проходит через оптимальный путь. Это даже в том случае, если опытный администратор устанавливает сервер и имеет шпильку NAT. (Разумеется, DNS с разделением горизонта может привести к оптимальной маршрутизации внутреннего трафика в руках сетевого администратора.)

Что происходит, когда разработчик приложения создает программу, подобную Dropbox, и распространяет ее среди конечных пользователей, которые не специализируются в настройке сетевого оборудования? В частности, что происходит, когда я помещаю файл объемом 4 ГБ в общий файл, а затем пытаюсь получить доступ на следующем компьютере? Передается ли он напрямую между компьютерами, или мне нужно подождать, пока он загрузится на облачный сервер через медленное WAN-соединение, а затем подождать второй раз, пока он загрузится через то же медленное WAN-соединение?

Для наивной реализации, он будет загружен и затем загружен с использованием серверной инфраструктуры Dropbox, которая не находится за NAT в качестве посредника. Но если две машины могли понять только, что они находятся в одной сети, они могли бы просто напрямую передавать файл намного быстрее. Итак, для нашей первой менее наивной попытки реализации мы могли бы спросить у ОС, какой IP-адрес (v4) есть у компьютера, а затем проверить его на других машинах, зарегистрированных в той же учетной записи Dropbox. Если он находится в том же диапазоне, что и мы, просто передайте файл. Это может работать во многих случаях. Но даже тогда возникает проблема: NAT работает только потому, что мы можем повторно использовать адреса. Так что, если адрес 192.168.0.23 и адрес 192.168.0. 42 адреса, зарегистрированные в одной учетной записи Dropbox, фактически находятся в разных сетях (например, в вашей домашней сети и в вашей рабочей сети)? Теперь вы должны вернуться к использованию серверной инфраструктуры Dropbox для посредничества. (В конце концов, Dropbox попытался решить эту проблему, передав каждому клиенту Dropbox широковещательную рассылку в локальной сети в надежде найти других клиентов. Но эти широковещательные рассылки не пересекают маршрутизаторы, которые могут быть у вас за NAT, то есть это не полное решение. ,особенно в случае CGN .)

Статические IP-адреса

Кроме того, поскольку первая нехватка (и волна NAT) произошла, когда многие потребительские соединения не всегда были в соединениях (например, при коммутируемом соединении), интернет-провайдеры могли бы лучше использовать свои адреса, только выделяя публичные / внешние IP-адреса, когда вы на самом деле были подключены. Это означало, что когда вы подключались, вы получали любой доступный адрес, а не всегда получали один и тот же. Это значительно усложняет работу на вашем собственном сервере и усложняет разработку одноранговых приложений, поскольку им приходится иметь дело с перемещающимися одноранговыми узлами, а не с фиксированными адресами.

Обфускация источника вредоносного трафика

Поскольку NAT перезаписывает исходящие соединения так, как если бы они исходили от самого устройства NAT, все поведение, хорошее или плохое, свернуто в один внешний IP-адрес. Я не видел ни одного устройства NAT, которое регистрирует каждое исходящее соединение по умолчанию. Это означает, что по умолчанию источник прошлого вредоносного трафика можно отследить только на устройстве NAT, через которое он прошел. Хотя для регистрации каждого исходящего соединения можно настроить оборудование корпоративного или операторского класса, я не видел ни одного маршрутизатора-потребителя, который бы это делал. Я, конечно, думаю, что будет интересно посмотреть, будут ли (и как долго) интернет-провайдеры вести журнал всех соединений TCP и UDP, выполненных через CGN, по мере их развертывания. Такие записи будут необходимы для рассмотрения жалоб на злоупотребления и жалоб DMCA.

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

Протоколы, использующие второе соединение

Протоколы, такие как FTP и SIP (VoIP), как правило, используют отдельные соединения для контроля и фактического содержимого данных. Каждый протокол, который делает это, должен иметь вспомогательное программное обеспечение, называемое ALG (шлюз прикладного уровня) на каждом устройстве NAT, через которое он проходит, или обходить проблему с помощью какого-либо посредника или пробивки отверстий. По моему опыту, ALG редко, если вообще обновляются, были причиной по крайней мере нескольких проблем, с которыми я сталкивался при использовании SIP. Каждый раз, когда я слышу, как кто-то сообщает, что VoIP у них не работает, потому что звук работает только в одном направлении, я сразу же подозреваю, что где-то есть NAT-шлюз, сбрасывающий UDP-пакеты, с которыми он не может понять, что делать.

Таким образом, NAT имеет тенденцию ломаться:

• альтернативные протоколы TCP или UDP
• одноранговые системы
• доступ к чему-то, что находится за NAT
• такие вещи, как SIP и FTP. ALG, чтобы обойти это, по-прежнему вызывают случайные и странные проблемы сегодня, особенно с SIP.

По сути, многоуровневый подход сетевого стека относительно прост и элегантен. Попытайтесь объяснить это кому-то новичку в сети, и они неизбежно предполагают, что их домашняя сеть, вероятно, является хорошей, простой сетью, которую нужно понять. Я видел, как это привело в нескольких случаях к довольно интересным (чрезмерно сложным) идеям о том, как работает маршрутизация из-за путаницы между внешними и внутренними адресами.

Я подозреваю, что без NAT VoIP был бы вездесущим и интегрированным с PSTN, и что звонки с мобильного телефона или компьютера были бы бесплатными (за исключением Интернета, за который вы уже заплатили). В конце концов, зачем мне платить за телефон, если мы с вами можем просто открыть поток VoIP 64K, и он работает так же хорошо, как PSTN? Кажется, что сегодня проблема номер 1 с развертыванием VoIP проходит через устройства NAT.

Я подозреваю, что мы обычно не понимаем, насколько проще было бы многое, если бы у нас была сквозная связь, которую прервал NAT. Люди по-прежнему отправляют по электронной почте (или Dropbox) сами файлы, потому что если основная проблема заключается в необходимости посредника, когда два клиента находятся за NAT.

Один большой симптом исчерпания IPv4, о котором я не упоминал в других ответах, заключается в том, что некоторые поставщики мобильных услуг начали использовать IPv6 только несколько лет назад. Есть вероятность, что вы использовали IPv6 в течение многих лет и даже не знали об этом. Мобильные провайдеры новички в интернет-играх и не обязательно имеют огромные ранее существовавшие ресурсы IPv4 для извлечения. Для них также требуется больше адресов, чем для кабельного / DSL / оптоволокна, поскольку ваш телефон не может использовать общедоступный IP-адрес для других членов вашей семьи.

Я предполагаю, что IaaS и PaaS провайдеры будут следующими, поскольку их рост не связан с физическими адресами клиентов. Я не удивлюсь, увидев скоро IaaS-провайдеров, предлагающих только IPv6 со скидкой.

В основных RIR некоторое время назад не хватило места для нормального распределения. Поэтому для большинства поставщиков единственными источниками адресов IPv4 являются их собственные запасы и рынки.

Существуют сценарии, в которых предпочтительно иметь выделенный публичный IPv4 IP, но это не является абсолютно необходимым. Существует также множество общедоступных IPv4-адресов, которые выделены, но в настоящее время не используются в общедоступном Интернете (они могут использоваться в частных сетях или вообще не использоваться). Наконец, есть более старые сети с адресами, распределенными куда более свободно, чем им нужно.

Три крупнейших RIR теперь позволяют продавать адреса как между их участниками, так и между ними. Таким образом, у нас есть рынок между организациями, у которых есть адреса, которые они не используют, или у которых есть адреса, которые могут быть освобождены за плату с одной стороны, и организациями, которым действительно нужно больше IP-адресов с другой.

Трудно предсказать, сколько будет спроса и предложения в каждой ценовой точке и, следовательно, что будет делать рыночная цена в будущем. Пока что цена за IP, кажется, остается на удивление низкой.

В идеале, каждый хост в Интернете должен иметь возможность получить IP-адрес глобальной области, однако исчерпание IPv4-адреса реально, но в ARIN уже исчерпан адрес в их свободном пуле .

Причина, по которой все по-прежнему могут получить доступ к интернет-службам просто отлично, заключается в методах преобразования сетевых адресов (NAT), которые позволяют нескольким хостам совместно использовать публичные IP-адреса. Однако это не без проблем.

Интернет-провайдеры раздают компании блоки из 256 IP-адресов. Теперь интернет-провайдеры скупы и дают вам (компании) вроде 5. В те времена (2003 г.) у каждого ПК и подключенного устройства в вашем доме был свой IP-адрес в Интернете. Теперь маршрутизатор Cable / DSN / Fios имеет один IP-адрес и выдает IP-адреса 10.0.0.x всем компьютерам в вашем доме. Резюме: Интернет-провайдеры использовали для тратить IP-адреса, и теперь они больше не тратят их.

Вы уже получили много отличных ответов, но я хотел бы добавить кое-что, что еще не было упомянуто.

Да, исчерпание IPv4-адреса плохо, в зависимости от того, как вы его измеряете. Некоторые компании по-прежнему имеют огромное количество адресов IPv4, но мы начинаем видеть обходные пути, такие как NAT операторского уровня.

Но многие из ответов неверны, когда они переходят на IPv6.

Вот список технологий, которые могут помочь справиться с нехваткой адресов IPv4. У каждого есть свои преимущества и недостатки.

• IPv6

  • Преимущество: стандартизировано и доступно в большинстве операционных систем.
  • Недостаток: несмотря на частые заявления об обратном, серьезные проблемы с безопасностью. Еще в 2005 году US CERT предупреждал о проблемах безопасности, вызванных глобальной адресацией IPv6. IPv6 может быть защищен должным образом, но, учитывая состояние маршрутизаторов-потребителей, это может не произойти.
  • Недостаток: миграция требует времени, денег и опыта.
  • Недостаток: многие потребительские устройства имеют серьезные недостатки. Например, ряд маршрутизаторов D-Link поддерживают IPv6, просто перенаправляя весь трафик, не предлагая брандмауэра.

Еще одно соображение: даже если IPv6 полностью завоевал популярность сегодня, все равно потребуется еще около 20 лет для поэтапного отказа от IPv4 из-за устаревшего оборудования, которое люди будут использовать в течение очень долгого времени (я все еще вижу серверы Windows 2003 и рабочие станции Windows XP время от времени! Не говоря уже о всех принтерах, камерах и устройствах IoT, которые не поддерживают IPv6).

• CGNat:
  • Преимущество: работает без изменений на территории заказчика.
  • Недостаток: поддерживает только исходящие соединения.
  • Недостаток: может не поддерживать несколько протоколов.

В конце концов, CGNat не будет достаточно. Возможно, IPv6 получит популярность, но вполне возможно, что в конечном итоге мы увидим NAT уровня страны или что-то в этом роде.

В настоящее время в качестве консультанта мне часто приходится указывать своим клиентам, что они знакомы с IPv6 (часто благодаря Teredo). Следующий вопрос неизменно будет звучать так: «Сколько стоит это исправить?» а затем "Сколько стоит его заблокировать? Что мы потеряем, если выключим?" Угадай, какое решение будет каждый раз.

Итог: чтобы ответить на ваш вопрос, да, исчерпание IPv4 реально. И мы увидим немало механизмов, чтобы справиться с этим. IPv6 может или не может быть уравнением.

Чтобы было понятно: я не говорю, что мне нравится эта ситуация. Я хотел бы, чтобы IPv6 был успешным (и я хотел бы видеть ряд улучшений в IPv6). Я просто смотрю на ситуацию, которая сейчас на месте.

NAT - это то, что произошло, когда IPv6 был идеей, до того, как это стало реальностью, и распределение IP-адресов становилось реальной проблемой (кто-нибудь помнит, когда они раздавали классы C в основном для запроса?), А реальный мир нуждался в решении тем временем ,

NAT не достаточно для IoT. Если IoT произойдет, это произойдет с IPv6. Природа IoT более тесно связана с тем, как работает мир коммутируемого доступа, за исключением того, что одновременно будет подключено больше устройств на несколько порядков.

Весь вопрос с адресом IPv4 довольно запутан. Вы можете найти определенную статью, сообщающую, что она исчерпана, а другая говорит о том, что большое количество избыточных (никогда не использованных) адресов было продано от одной стороны к другой. Вопрос заключается в том, почему они недоступны для тех (развивающиеся регионы и сельские районы развитых стран), в которых они отсутствуют?

Ниже приведен результат исследования, в которое мы случайно попали. Он использует не что иное, как оригинальный протокол IPv4 RFC791 и давно зарезервированный, но с трудом используемый блок адресов 240/4 для расширения пула IPv4 в 256 раз. Мы представили в IETF проект предложения под названием EzIP (фонетика для Easy IPv4):

https://tools.ietf.org/html/draft-chen-ati-adaptive-ipv4-address-space-03

По сути, подход EzIP не только решит проблемы нехватки адресов IPv4, но и в значительной степени уменьшит первопричину уязвимостей кибербезопасности, а также откроет новые возможности для Интернета, все в пределах домена IPv4. Фактически, эта схема может быть развернута "скрытно" для изолированных регионов, где это необходимо. Это должно уменьшить необходимость развертывания IPv6 в течение значительного промежутка времени и обесценить рынок торговли адресами IPv4.

Любая мысль или комментарий будут высоко оценены.

Абэ (2018-07-15 17:29)

Честно говоря, я думаю, что это не так плохо, как думают люди. Да, может быть, в некоторых местах, но не так много, потому что не хватает адресов. Это потому что они все в собственности. Может быть, это мое местоположение или что-то в этом роде, но за последние семь лет или около того я занимался ИТ-работой для компаний малого и среднего бизнеса, и все, о чем вы все говорите, обычно является стандартной установкой. Довольно просто, если у вас нет дрянного устройства, или нет дерьмовой установки с сетью в первую очередь, с которой нужно разобраться.

Лично у меня все нормально с NAT. Вообще говоря, это дополнительный уровень защиты. По крайней мере, они либо должны пройти через дополнительное устройство, либо найти способ косвенно взломать мое соединение. Что касается запуска серверов, то это, как правило, выходит за рамки и / или считается нарушением договора с вашим интернет-провайдером, если только вы не платите за него. Конечно, вы можете сделать это, и они, вероятно, не будут беспокоить вас об этом, но они могли.

Переадресация портов и все такое не совсем сложно. Теперь, может быть, некоторые устройства не так легко настроить, но это не из-за IPv4. Это все еще предлагает большую совместимость просто потому, что это вездесуще.

Никто на самом деле не нуждается в том, чтобы самим писать по электронной почте, и отправка чего-либо в Drop-box, Google Drive или миллион других подобных сервисов - не совсем ракетостроение, и не медленное в наши дни. Я имею в виду все синхронизируется. Вы бросаете его в папку. Если вы не такой занудный, как я, и вы делаете все через ssh / sftp (хорошо, не все ). И если у вас есть какая-то причина, по которой вы действительно хотите запустить свой собственный сервер, облачный хостинг стоит дешево - у меня есть выделенный виртуальный сервер, который запускает linux на ssd. Пропускная способность сумасшедшая быстро. Он загружается быстрее, чем я могу набрать стрелку вверх и нажать Enter. И масштабируем. Вся установка стоит от 5 до 10 долларов в месяц, с бесплатными резервными копиями и без счета за электричество.

Не нужно действительно одноранговое сетевое решение. Даже большинство многопользовательских игр в наши дни настроены на взаимодействие через промежуточный сервер, все настроено и предварительно настроено. С другой стороны, если все, что я читаю в этом посте, все правда, ИТ будет переполненным и дешевым, если / когда IPv6 взлетит. Даже мобильные телефоны приближаются к оптоволоконным скоростям. Или хотя бы кабель.

Если вы запускаете внутренний сервер и вам нужно использовать одно и то же доменное имя внутри или вне вашей сети, вы всегда можете подделать его адрес с помощью маршрутизатора на основе Linux и dnsmasq или любых других пользовательских записей на хостах. файл, чтобы перенаправить вас на локальный адрес, если вы находитесь внутри.

На самом деле, я не думаю, что на самом деле желательно, чтобы каждое устройство имело собственный адрес прямо в сети. Если кто-то хочет запутать себя, нападая на вас, это случится независимо. Но ты - сидячая утка, если ты просто сидишь там на свежем воздухе. Нет, я возьму свой IPv4 и NAT в любой день. Но хорошо, что он там.

Во всяком случае, засыпаю сейчас ... вероятно, еще скажу, но я проверю завтра, если я что-то пропустил. Я уверен, что есть больше.