В течение многих лет пресса писала о проблеме, заключающейся в том, что сейчас доступно очень мало адресов IPv4. Но с другой стороны, я использую хостинговую компанию, которая с радостью выдает общедоступные IPv4-адреса за небольшие деньги. И мое частное интернет-соединение идет с публичным IPv4-адресом.
Как такое возможно? Неужели проблема настолько серьезна, как нас хотят представить в прессе?
Это очень плохо. Вот список примеров того, что я из первых рук делал с поставщиками услуг Интернета для борьбы с нехваткой адресов IPv4:
Все это снижает качество продукта, который интернет-провайдер продает своим клиентам. Единственное разумное объяснение того, почему они поступают так со своими клиентами, - нехватка адресов IPv4.
Нехватка IPv4-адресов привела к фрагментации адресного пространства, имеющей ряд недостатков:
Без NAT мы не смогли бы обойтись сегодня с 3700 миллионами маршрутизируемых IPv4-адресов. Но NAT - это хрупкое решение, которое дает вам менее надежное соединение и проблемы, которые трудно устранять. Чем больше слоев NAT, тем хуже будет. Два десятилетия напряженной работы сделал один слой NAT в основном работы, но мы уже перешли точку, где один слой NAT было достаточно, чтобы обойти проблему нехватки адресов IPv4.
До того, как у нас закончились адреса IPv4, мы (широко) не использовали NAT. Каждый компьютер, подключенный к Интернету, будет иметь свой глобальный уникальный адрес. Когда NAT был впервые представлен, он должен был перейти от предоставления клиентам интернет-провайдера 1 реального адреса на каждое устройство, которое клиент использовал / владел, к предоставлению 1 покупателю 1 реального адреса. Это устранило проблему на время (годы), пока мы должны были перейти на IPv6. Вместо перехода на IPv6 (в основном) все ждали, пока все переключатся, и поэтому (в основном) никто не развернул IPv6. Теперь мы снова сталкиваемся с той же проблемой, но на этот раз развертывается второй уровень NAT (CGN), чтобы интернет-провайдеры могли совместно использовать один реальный адрес между несколькими клиентами.
Исчерпание IP-адреса не имеет большого значения, если NAT не страшен, в том числе в случае, когда конечный пользователь не может его контролировать (NAT или CGN операторского класса).
Но я бы сказал, что NAT ужасен, особенно в том случае, если конечный пользователь не может его контролировать. И (как человек, чья работа связана с сетевым проектированием / администрированием, но имеет степень инженера по программному обеспечению), я бы сказал, что, развернув NAT вместо IPv6, сетевые администраторы переложили вес решения проблемы исчерпания адресов за пределы своей области на конечных пользователей. и разработчики приложений.
Итак (на мой взгляд), почему NAT - это ужасная и злая вещь, которой следует избегать?
Давайте посмотрим, смогу ли я справедливо объяснить, что он ломает (и какие проблемы он вызывает, к которым мы так привыкли, что даже не осознаем, что может быть лучше):
Посмотрим, смогу ли я объяснить каждый из этих пунктов.
ISP должны просто передавать пакеты уровня 3 и не заботиться о том, что находится на уровнях выше. Независимо от того, передаете ли вы TCP, UDP или что-то лучшее / более экзотическое (возможно, SCTP? Или даже какой-то другой протокол, который лучше TCP / UDP, но неясен из-за отсутствия поддержки NAT), ваш интернет-провайдер не должен забота; все это должно выглядеть для них как данные.
Но это не так - не тогда, когда они внедряют «вторую волну» NAT, 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 порт 80. Тот, который вы должны использовать, зависит от того, находитесь ли вы внутри или за пределами NAT. Если вы находитесь за пределами NAT и используете адрес 192.168.0.23, вы не попадете туда, где ожидаете. Если вы находитесь внутри NAT и используете внешний адрес 35.72.216.228, вы мощь иди туда, куда хочешь, если ваша реализация NAT является продвинутой, которая поддерживает шпильку, но тогда веб-сервер, обслуживающий ваш запрос, увидит запрос как исходящий от вашего устройства NAT. Это означает, что весь трафик должен проходить через устройство NAT, даже если есть более короткий путь в сети за NAT, и это означает, что журналы на веб-сервере становятся гораздо менее полезными, поскольку все они перечисляют устройство NAT как источник связь. Если ваша реализация NAT не поддерживает шпильку, вы не добьетесь того, чего ожидали.
И эта проблема усугубляется, как только вы используете DNS. Внезапно, если вы хотите, чтобы все работало правильно для чего-то, размещенного за NAT, вы захотите дать разные ответы на адрес службы, размещенной внутри NAT, в зависимости от того, кто спрашивает (AKA split horizon DNS, 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.)
Кроме того, поскольку первая нехватка (и волна 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 имеет тенденцию ломаться:
По сути, многоуровневый подход, который использует сетевой стек, относительно прост и элегантен. Попробуйте объяснить это кому-то, кто плохо знаком с сетями, и они неизбежно подумают, что их домашняя сеть, вероятно, хорошая и простая сеть, которую нужно понять. Я видел это в паре случаев, когда приводились довольно интересные (чрезмерно сложные) идеи о том, как работает маршрутизация из-за путаницы между внешними и внутренними адресами.
Я подозреваю, что без 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-адрес в Интернете. Теперь кабельный / DSN / Fios-маршрутизатор имеет один IP-адрес и выдает IP-адреса 10.0.0.x всем ПК в вашем доме. Резюме: интернет-провайдеры тратили впустую IP-адреса, и теперь они больше не тратят их.
Вы уже получили много отличных ответов, но я хотел бы добавить кое-что, о чем еще не упоминалось.
Да, исчерпание адресов IPv4 - это плохо, в зависимости от того, как вы это измеряете. У некоторых компаний все еще есть огромное количество адресов IPv4, но мы начинаем видеть обходные пути, такие как NAT операторского уровня.
Но многие ответы неверны, когда они переходят на IPv6.
Вот список технологий, которые могут помочь справиться с нехваткой IPv4-адресов. У каждого есть свои достоинства и недостатки.
IPv6
Еще одно соображение: даже если IPv6 полностью приживется сегодня, потребуется еще около 20 лет, чтобы постепенно отказаться от IPv4 из-за устаревшего оборудования, которое люди будут использовать очень долго (я все еще вижу серверы Windows 2003 и рабочие станции Windows XP иногда! Не говоря уже обо всех принтерах, камерах и гаджетах IoT, которые не поддерживают IPv6).
В конце концов, CGNat будет недостаточно. Возможно, IPv6 завоюет популярность, но также вполне возможно, что мы в конечном итоге увидим NAT национального уровня или что-то в этом роде.
В настоящее время, будучи консультантом, мне часто приходится указывать своим клиентам, что они доступны по IPv6 (часто благодаря Teredo). Следующим вопросом неизменно будет: «Сколько стоит это исправить?» а затем «Сколько стоит его заблокировать? Что мы потеряем, если выключим его?» Угадай, какое будет решение каждый раз.
Итог: отвечая на ваш вопрос, да, исчерпание IPv4 реально. И мы увидим немало механизмов, как с этим справиться. IPv6 может оказаться уравнением, а может и не оказаться.
Чтобы было ясно: я не говорю, что я лайк эта ситуация. Я бы хотел, чтобы IPv6 был успешным (и я хотел бы увидеть ряд улучшений в IPv6). Я просто смотрю на ситуацию, как сейчас.
NAT - это то, что произошло, когда IPv6 был идеей, до того, как он стал реальностью, и выделение IP-адресов становилось реальной проблемой (кто-нибудь помнит, когда они раздавали класс C в основном для запроса?), А реальный мир тем временем нуждался в решении .
NAT не подходит для Интернета вещей. Если IoT и произойдет, это произойдет с IPv6. Природа Интернета вещей более тесно связана с тем, как работает мир коммутируемого доступа, за исключением того, что одновременно будет подключено на несколько порядков больше устройств.
Весь вопрос с адресами 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-адресами.
Будем очень признательны за любые мысли или комментарии.
Абэ (15.07.2018 17:29)
Честно говоря, я считаю, что это не так плохо, как думают. Да, может кое-где, но не настолько, потому что не хватает адресов. Это потому, что все они принадлежат. Может быть, это мое местоположение или что-то в этом роде, но за последние семь лет или около того я выполнял ИТ-работу для множества малых и средних предприятий, и все, о чем вы все говорите, обычно является стандартным. Довольно просто, если у вас нет дрянного устройства или дерьмовой настройки сети в первую очередь, в которой нужно разобраться.
Лично меня устраивает NAT. Вообще говоря, это дополнительный уровень защиты. По крайней мере, им нужно либо пройти через дополнительное устройство, либо найти способ косвенно перехватить мое соединение. Что касается работы серверов, это обычно выходит за рамки и / или считается нарушением контракта с вашим интернет-провайдером, если вы за это не платите. Конечно, вы можете это сделать, и они, вероятно, не будут вас беспокоить, но могли.
Перенаправление портов и все такое совсем не сложно. Возможно, некоторые устройства нелегко настроить, но это не из-за IPv4. Он по-прежнему предлагает максимальную совместимость просто потому, что он повсеместен.
На самом деле никому не нужно отправлять электронные письма, а отправка чего-либо в Drop-box, Google Drive или миллион других подобных сервисов в наши дни не совсем ракетная наука и не медленная. Я имею ввиду все синхронизируется. Закидываешь в папку. Если только вы не такой ботан, как я, и делаете все через ssh / sftp (ладно, не все). И если у вас есть причина, по которой вы действительно хотите запустить свой собственный сервер, облачный хостинг дешевый - у меня есть выделенный виртуальный сервер, который запускает Linux на ssd. Пропускная способность безумно быстрая. Он загружается быстрее, чем я могу набрать стрелку вверх и нажать Enter. И масштабируемость. Вся установка стоит от 5 до 10 долларов в месяц, с бесплатными резервными копиями и без счетов за электричество.
На самом деле не нужно решение для одноранговой сети. Даже большинство многопользовательских игр в наши дни настроены для взаимодействия через промежуточный сервер, все настроены и предварительно настроены. С другой стороны, если все, что я читаю в этом посте, правда, ИТ будет переполнен и дешев, если / когда появится IPv6. Даже мобильные телефоны приближаются к скорости, подобной волоконной. Или хотя бы кабель.
Если у вас есть внутренний сервер, и вам нужно поразить его с тем же доменным именем внутри или вне вашей сети, вы всегда можете подделать его адрес, используя маршрутизатор на базе Linux и dnsmasq или что-то еще, и настраиваемые записи в хостах файл, чтобы перенаправить вас на локальный адрес, если вы находитесь внутри.
На самом деле, я не думаю, что на самом деле желательно, чтобы у каждого устройства был свой собственный адрес прямо там, плавающий в сети. Если кто-то хочет скрыть себя во время нападения на вас, это произойдет независимо. Но вы сидячая утка, если просто сидите на свежем воздухе. Нет, в любой момент я возьму свой IPv4 и NAT. Но хорошо, что она есть.
Anywa, сейчас засыпаю ... наверное, еще сказать, но я проверю завтра, если я что-то пропустил. Я уверен, что есть еще кое-что.