Поставили новый роутер, запустили онлайн-игру или развернули облачный сервер — и снова натыкаетесь на «двойной NAT», бесконечный порт-форвардинг и вместо своего IP видите чей-то 203.0.113.45. Причем железо и провайдеры уже готовы к IPv6, а мы все еще буксуем в прошлом.
Давайте посмотрим, почему наследие старого интернета — повсеместный NAT — тормозит нашу сетевую эволюцию и что с этим можно сделать. Детали под катом.
Используйте навигацию, если не хотите читать текст целиком:
→ Зачем вообще понадобился NAT
→ Темная сторона костылей
→ IPv6: переход не по щелчку
→ Между двух миров: гибридные решения
→ Путь к чистому IPv6
→ Взгляд в будущее: IPv6-only и децентрализованная сеть
Зачем вообще понадобился NAT
Все уже порядком устали от клише «всемирная паутина» — звучит как старый рингтон. На самом деле интернет — не паутина и даже не улей. Скорее бесконечный гипермаркет, где вместо ценников на товарах приклеены ссылки, а вместо охранников — боты, которые периодически кричат «Вы не пройдете без капчи».
Заметили, как они изменились в последнее время? Уже не просто «Найди машину», а «Подумай, что издаст такой же звук» или «Перетащи детали так, чтобы получилась фигура».
Но что действительно важно: за всей этой шумихой скрывается набор прописанных договоренностей между нашими устройствами — протоколов, адресов и портов, которые позволяют нам обмениваться данными.
IPv4 был создан в эпоху, когда компьютеры считались роскошью, а сеть не была похожа но то, что есть сейчас. 32-битное адресное пространство, 4,3 миллиарда IP-адресов. На бумаге — более чем достаточно. На практике — кризис уже в 1990-х. Почему? Потому что никто не предполагал, что каждая колонка, смарт-часы и даже умная лампочка потребуют свой собственный IP.
NAT (Network Address Translation) появился как ответ на быстрое исчерпание IPv4-адресов. И должен был стать временным решением. Всего лишь костыль, чтобы выиграть время до перехода на IPv6. Но все пошло иначе: костыль превратился в протокол де-факто, а временная мера стала стандартом.
Основная идея NAT заключалась в том, чтобы позволить множеству устройств внутри локальной сети использовать один публичный IP-адрес для выхода в интернет. При этом каждому устройству внутри сети выделяется частный IP-адрес из зарезервированных диапазонов (RFC 1918), которые не выгружаются в глобальную сеть. Маршрутизатор с NAT преобразует внутренние адреса в один внешний адрес, подменяя IP-адрес и номер порта в пакетах, что позволяет сотням и даже тысячам клиентов делить один публичный IP.
Подход позволил сэкономить ограниченный пул IPv4-адресов и упростил маршрутизацию, так как внешняя сеть видит лишь один адрес, а внутренние устройства остаются скрытыми. Это решение стало важным для продолжения роста интернета в 1990-х и 2000-х годах, когда массовое распространение компьютеров и мобильных устройств резко увеличило количество подключенных узлов.
Таким образом, большинство сетей работают через NAT, даже если уже поддерживают IPv6. Почему? Привычка. Инерция. Комфорт. Потому что «все работает, значит, менять не нужно».
Темная сторона костылей
Хороший старый NAT, который долгое время служил спасением, имеет и свою темную сторону, проявляющуюся особенно остро. Одной из главных проблем является так называемый Double NAT — ситуация, когда два уровня трансляции адресов накладываются друг на друга, например, когда домашний роутер подключен к модему провайдера, который тоже работает в режиме NAT.
Онлайн-игры, голосовые чаты, P2P — все это начинает работать с перебоями. Проблема не в игре, а в том, что ваш IP «утоплен» под двойной маской, и серверы просто не могут установить прямое соединение. Игроки получают «жесткий» тип NAT, а виртуальные частные сети — нестабильные соединения с повышенной задержкой. И это не баг, а особенность архитектуры, которую мы вынуждены терпеть.
Процесс работы CGNAT. Источник.
Еще глубже — CGNAT (Carrier-Grade NAT) на уровне провайдеров. Эта технология позволяет провайдерам экономить IPv4-адреса, распределяя один публичный IP сразу на сотни или тысячи абонентов. Результат — вы не можете хостить сервис, потому что порты не принадлежат вам, геолокационные сервисы начинают ошибаться, а VoIP-звонки теряют стабильность. CGNAT не просто усложняет жизнь — он делает пользователей зависимыми от прозрачности инфраструктуры, которой нет.
NAT64 — это режим функционирования CGNAT для трансляции адресов IPv6 клиента в публичные (белые) адреса IPv4 из заданного пула. Большинство онлайн-сервисов все еще поддерживают только IPv4. Режим NAT64 необходим для обеспечения прозрачного доступа клиентам, которые используют оборудование IPv6. Источник.
А что насчет безопасности? Многие считают, что NAT защищает внутренние устройства, скрывая их за общим IP. Это как аварийный выход на высоте 30 тысяч футов — иллюзия безопасности. NAT не шифрует трафик, не аутентифицирует пользователей и не предотвращает атаки на приложения или устройства. Лишь маскирует IP-адреса, создавая ложное чувство защищенности.
Особенно уязвимы устройства IoT, которые часто подключаются к интернету за CGNAT и не имеют собственных механизмов безопасности. Классический пример — сотни «умных» лампочек, объединенных под одним CGNAT-адресом, которые могут быть захвачены злоумышленниками и использованы для создания мощных ботнетов, способных запускать масштабные DDoS-атаки. Подробнее про взлом домашних приборов и не только я писал в одной из предыдущих статей.
Таким образом, несмотря на свои преимущества в экономии адресов и упрощении маршрутизации, NAT и особенно его операторские варианты создают значительные проблемы для современных сетевых приложений. Это одна из причин, почему переход на IPv6, который избавляет от необходимости в NAT, остается актуальной и необходимой задачей для индустрии.
IPv6: переход не по щелчку
Когда-то IPv6 обещал интернет без трюков: уникальный адрес на каждое устройство, никакого NAT, прямая маршрутизация. Но реальность оказалась проще и, вместе с тем, сложнее. В 2025 году мы все еще живем в мире, где IPv4 доминирует, а IPv6 — это «ну, типо, поддерживаем».
Глобально лишь около 40% хостов способны работать по IPv6. В России этот разрыв еще заметнее: и провайдеры, и корпоративные сети массово используют NAT, а только около 10% пользователей имеют возможность нативно подключаться по IPv6.
Источник.
Хотя большинство современных устройств и операционных систем уже много лет поддерживают IPv6 «из коробки», ключевой барьер — инерция провайдеров. Многие ISP, особенно региональные и небольшие, не спешат внедрять IPv6, предпочитая экономить ресурсы и использовать NAT для продления жизни IPv4. Это связано и с затратами на обновление инфраструктуры, и с отсутствием прямых стимулов: спрос на IPv6 со стороны конечных пользователей пока невысок, а для бизнеса переход часто означает дорогой апгрейд маршрутизаторов, коммутаторов и обучающих программ для персонала.
Даже если провайдер предлагает IPv6, на практике часто встречается полумеры: домашние роутеры, выпущенные за последние 10 лет, формально умеют в IPv6, но их прошивки могут содержать баги, неправильно обрабатывать ICMPv6 или фрагментацию пакетов, а файерволы и IDS иногда некорректно фильтруют новый трафик, что приводит к сбоям и падению производительности.
Главный тормоз — огромный пласт старого контента и сервисов, не имеющих IPv6-версий. Десятки миллиардов устройств (особенно IoT, промышленные системы, старые серверы) и тысячи веб-сервисов продолжают работать только по IPv4. Это вынуждает поддерживать dual-stack-сети и арендовать или покупать дорогие IPv4-адреса, что поддерживает спрос и замедляет отказ от старого протокола.
Внедрение IPv6 в каждой стране. Источник.
Перспективы, однако, не безоблачны. Крупные игроки — от Google до Cloudflare — давно перешли на IPv6, что позволяет им снижать задержки и упрощать маршрутизацию, а Азия уже достигла 50% возможностей IPv6 благодаря активным инвестициям и государственным инициативам APNIC Blog.
По мере исчерпания адресного пула IPv4 и старения legacy-сетей, рост IPv6 станет лавинообразным: со временем среды, поддерживающие только IPv6, заменят dual-stack, а NAT и прокси уйдут в историю.
Итак, основные препятствия для внедрения IPv6 заключаются в том, что:
- региональные ISP продлевают жизнь IPv4 через NAT, поскольку замена инфраструктуры, а также обучение персонала начисто «съедают» бюджет;
- даже при официально включенном IPv6 многие выбирают IPv4 из-за ошибок первого;
- миллиарды устройств по всему миру не умеют в IPv6, поэтому сети переключаются в dual-stack, что удваивает сложность и расходы;
- пользователи не замечают, по какому IP «дают» им тот или иной сайт, а значит, спроса на полноценный IPv6-доступ практически нет.
Между двух миров: гибридные решения
Dual-stack и его цена
Поддержка dual-stack требует, чтобы каждый роутер, сервер и конечное устройство умели «говорить» и по IPv4, и по IPv6 — а значит, дублировать: конфигурации, мониторинг, логирование и администрирование.
На примере облачных IP у провайдеров в Европе это выливается в реальные деньги: ежемесячная аренда одного IPv4-адреса стоит до €3 (плавающий IPv4) или €0.50 (статичный IPv4), в то время как IPv6-адрес выделяется бесплатно или за символическую цену в €1 за /64-подсеть. В итоге аренда IPv4 может обходиться в 3, а то и в 10 раз дороже, чем IPv6.
Переходные технологии
Есть несколько механизмов, призванных снизить нагрузку и отложить «полный» dual-stack.
DS-Lite (Dual-Stack Lite)
DS-Lite инкапсулирует IPv4-пакеты внутри IPv6-туннеля и выполняет централизованный Carrier-Grade NAT (CGN) на стороне провайдера (AFTR), а на CPE-устройстве (B4) ограничивается только tunneling’ом.
Плюсы: не нужно выделять каждому абоненту публичный IPv4-адрес, вся транслитерация сосредоточена в одном месте.
Минусы: дополнительные 40 байт overhead на туннель (MTU-проблемы), отсутствие поддержки multicast, зависимость от стабильности AFTR.
Архитектура DSL. Источник.
NAT64/DNS64
Стандарт для мобильных операторов и провайдеров. DNS64 синтезирует AAAA-записи для IPv6-клиентов на основе A-записей старых сервисов, а NAT64 на граничном маршрутизаторе транслирует IPv6-пакеты в IPv4 и обратно.
Плюсы: позволяет IPv6-only хостам обращаться к большинству IPv4-сервисов без туннелей.
Минусы: не работает с протоколами, «вшивающими» IPv4-литералы в payload (SIP, FTP без ALG), требует точной настройки MTU и stateful NAT64.
464XLAT
Расширяет возможности NAT64: на клиенте (CLAT) применяется stateless SIIT (RFC 6145) для преобразования IPv4-трафика в IPv6, а на стороне провайдера (PLAT) — stateful NAT64 (RFC 6146) обратно в IPv4.
Плюсы: поддержка приложений, «жестко» завязанных на IPv4-сокеты и IP-литералы; активно используется в мобильных сетях (3GPP).
Минусы: добавляет дополнительный перевал (двойная трансляция), сложнее отлаживать в enterprise-сетях.
Путь к чистому IPv6
В случае провайдера необходимо зарегистрировать собственные IPv6-префиксы в BGP, чтобы обеспечить глобальную маршрутизацию новых адресов. Дальше — внедрение автоматической адресации: SLAAC (Stateless Address Autoconfiguration) или DHCPv6, чтобы абоненты получали уникальные IPv6-адреса без ручной настройки.
Важно корректно организовать рассылку Router Advertisement (RA) для работы локальных сетей, а для мобильных клиентов — реализовать поддержку PDP (Packet Data Protocol). При этом безопасность должна быть встроена на каждом этапе: фильтрация RA, защита от rogue DHCPv6, настройка firewall для IPv6 — все это уже стандарт индустрии. Важно помнить, что обновление оборудования и программного обеспечения — ключевой этап, иначе часть абонентов останется за бортом современного интернета.
Для разработчика приложения нового поколения должны быть нативно готовы к IPv6. Это значит — никаких жестко прописанных IPv4-адресов, только универсальные вызовы, поддержка IPv6-сокетов и правильная реализация socket.bind() для dual-stack или IPv6-only. WebSockets, REST API, peer-to-peer — все должно работать в среде, где IPv4 уже недоступен. Необходимо тестировать приложения на IPv6-only стендах и использовать современные библиотеки, которые корректно работают с обоими протоколами. Такой подход не только ускоряет отказ от NAT, но и открывает доступ к новым возможностям сетевой архитектуры.
Пользователя может проверить готовность к IPv6 за пару минут.
- Убедитесь, что ваш провайдер поддерживает IPv6 (например, через test-ipv6.com).
- Войдите в веб-интерфейс роутера (обычно 192.168.0.1 или 192.168.1.1) и включите поддержку IPv6 в соответствующем разделе настроек. На большинстве моделей это делается буквально одним переключателем.
- Выберите тип подключения: если провайдер поддерживает «родной» IPv6, используйте Native. Если нет — рассмотрите варианты туннелирования (6to4, 6in4).
- После активации проверьте, что ваши устройства получают глобальные IPv6-адреса и имеют доступ к сайтам, работающим только по IPv6 (например, ipv6.google.com).
- Если что-то не работает, обновите прошивку роутера или обратитесь к провайдеру за консультацией.
В современных роутерах (TP-Link, ASUS, Netgear, Huawei и др.) настройка IPv6 реализована максимально просто, а подробные инструкции есть на сайтах производителей и у операторов.
Взгляд в будущее: IPv6-only и децентрализованная сеть
Переход на IPv6-only уничтожит барьер NAT и вернет интернету истинную архитектуру end-to-end. В таких чистых сетях каждый узел получает глобальный адрес и может инициировать прямое соединение без прокладок CGNAT или порт-форвардинга. Это открывает дорогу для WebRTC-пирингов без TURN-серверов, стабильных P2P-приложений и Mesh-сервисов на базе протоколов BATMAN или Babel, где каждый роутер обладает «липким» адресом и участвует в равноправном обмене.
Сегодня лидерами по доле IPv6-трафика являются Саудовская Аравия (65,5%) и Япония (57,7%), где операторы включают IPv6 по умолчанию и фактически отказались от CGNAT. Эти страны уже зафиксировали в P2P-сценариях двукратное снижение задержек и полный отказ от сложных overlay-решений для multicast.
Ключевые технологии будущего «без NAT» уже встроены в IPv6.
- SLAAC + CGA позволяют узлам авто конфигурироваться и доказывать принадлежность адреса с помощью криптографических ключей, что важно для децентрализованных PKI и безопасной адресации.
-
Secure Neighbor Discovery (SEND) защищает от ARP-спуфинга и rogue-анонсов, обеспечивая проверку подлинности Neighbor Discovery сообщений на уровне железа.
Если к 2030 году в IPv6-only сети окажется 60–70 % новых IoT-устройств, то мы станем свидетелями взрывного роста распределенных систем: edge-computing-кластеров, блокчейнов без центральных нод и P2P-хранилищ с нативным шифрованием на сетевом уровне. При этом важно заранее адаптировать системы защиты — масштабировать DDoS-защиту, обновить IDS/IPS для поддержки ICMPv6 и SEND, а также автоматизировать аудит IPv6-ACL.
А что вы думаете по поводу протокола IPv6? Пишите в комментариях!
Комментарии (66)
NAI
21.05.2025 09:52Главный тормоз — огромный пласт старого контента и сервисов, не имеющих IPv6-версий.
Главный тормоз, это непонимание потребителями, зачем им платить за IPv6? ну и усложнение.
Сейчас будет опыт отдельно взятого хомяка в домашней сети.
Да, мой провайдер поддерживает IPv6, правда уже n-лет грозится начать брать за него деньги, и это проблема номер один - я не очень понимаю, как потребитель, за что буду платить? Сервисы работают и так, скорости не прибавится, ну и что я получу за лишние 100-200-500 рублей? youtube
разблокируетсяначнет работать быстрее, так он и сейчас неплохо работает. Нагрузка с серверов и оборудования упадет - так это не мои проблемы, а проблемы прова\сервисов, для меня они незаметны.Вторая проблема, безопасность и настройки firewall. Сейчас, приходя в кафе с 99.9% вероятностью я окажусь за NAT'ом и открытые порты на моем ноутбуке будут видны только посетителям этого кафе(вероятность что в нем же окажется хакер Вася, аналогично, ничтожна). Представим, что в общественных сетях IPv6 - мой ноутбук голой жопой окажется в интернете - надо настраивать firewall. А еще ноут жены, ребенка. Кстати, кто знает где и как настраивается firewall на мобиле и планшете? И ладно бы это все настраивалось разово, но ведь надо жеж все поддерживать - тут ребенок захотел создать сервер майнкрафта, тут жене подруга по
скайпуp2p хочет файл передать. Это все начинает жрать время - а жонглирование правилами файрволла не то чем я хочу заниматься в свободное от работы время.Проблема два, более глубока чем кажется. Сейчас каждое второе приложение после установки, радостно запрашивает права на доступ в сеть (да, windows)... для каждой сети мне придется создавать правила условно allow <домашняя сеть>, <корпоративная сеть>, <офис 2>, <VPN> Вы же не хотите, чтобы ваша dev-база данных, с паролем 123, развернутая в docker, оказалась доступной всем желающим? Мы же понимаем что есть пионЭры которые в дев раскатывают прод. данные для поиграться.
Третья проблема - SLAAC. Не, оно конечно классно работает, по сути DHCP-сервер переезжает к прову и становится его головной болью. Для домохозяек прям огонь. А теперь представим, что я хочу прибить гвоздями домашний NAS (ну или майнкрафт-сервер)
2001:0db8:85a3::192:168:88:123. Можно конечно прям так и задать, но вдруг пров. сменит префикс? Нужен DHCPv6, который заберет префикс у прова, раздаст в "локалку" и желательно именно в локалку, а не соседям по подъезду. Клиенты получат RA... уххх движ. В общем, я на микротике не шмог. Что там творится когда имеется два провайдеру - мне не ведомо, но есть подозрение, что так же, все усложняется.
Dalas_DV
21.05.2025 09:52Вот собственно и ответ почему ipv6 особо не взлетает. Боюсь представить какие пополнения у ботнетов будут, если все устройства начнут светиться в дикий интернет, с учетом текущего уровня осведомленности пользователей.
V1tol
21.05.2025 09:52Отлично расписано. Я вот, например, не понимаю, как с вот этими всеми ipv6 преимуществами настраивать три буквы на роутере. Если с ipv4 всё как-бы понятно, роутер по настроенным правилам сам маршрутизирует в разные туннели трафик, то с ipv6 ничего не понятно. Допустим, у меня и провайдер, и три буквы предоставляют ipv6. Как теперь на роутере настраивается маршрутизация? Даже вот в простейшем бинарном случае - устройство либо под тремя буквами, либо нет - это уже выглядит как наркомания какая-то. Нужно, чтобы разным устройствам роутер назначал айпи адреса из разных пулов? А как тогда будет маршрутизация в локальной сети работать? В общем, я ничего не понял и продолжил пользоваться "неправильными" ipv4+NAT.
asatost
21.05.2025 09:52Скорее бесконечный гипермаркет, где вместо ценников на товарах приклеены ссылки, а вместо охранников — боты, которые периодически кричат «Вы не пройдете без капчи».
Так это же не так, Интернет - это не только сайты.
Но все пошло иначе: костыль превратился в протокол де-факто
NAT это не протокол вообще.
Особенно уязвимы устройства IoT, которые часто подключаются к интернету за CGNAT и не имеют собственных механизмов безопасности.
С точностью до наоборот. Не имея доступного из общей сети адреса устройства IoT защищены лучше даже без собственных механизмов безопасности.
Классический пример — сотни «умных» лампочек, объединенных под одним CGNAT-адресом, которые могут быть захвачены злоумышленниками и использованы для создания мощных ботнетов, способных запускать масштабные DDoS-атаки. Подробнее про взлом домашних приборов и не только я писал в одной из предыдущих статей.
Это вообще на грани фола. Т.к. в статье по ссылке описание атаки, число которых с внедрением IPv6 имеет только один неизбежный путь - к росту. Если сейчас принтеры и лампочки находятся за NAT и чтобы выставить открытый порт "на улицу" нужно постараться, то при использовании IPv6 порт по умолчанию открыт всему миру и нужно постараться, чтобы его закрыть.
обновить IDS/IPS для поддержки ICMPv6 и SEND
Т.е. теперь пользователю нужно будет ещё и IDS/IPS дома держать? А затраты какие на это нужны?
hogstaberg
21.05.2025 09:52то при использовании IPv6 порт по умолчанию открыт всему миру и нужно постараться, чтобы его закрыть.
Stateful фаерволы на тех же cpe: "Ну да, ну да. Пошли мы нафиг"
asatost
21.05.2025 09:52Stateful фаерволы на тех же cpe: "Ну да, ну да. Пошли мы нафиг"
А кто их будет настраивать?
Пользователю же "умную" лампочку продают под соусом: "Вы сможете управлять ей из любой точки мира!" Перед выходом из дома заранее узнавать IPv6-подсети тех мест, которые желаем посетить плюс оператора сотовой связи? :))
hogstaberg
21.05.2025 09:52Пользователь лампочку непременно прямо в точку обмена трафиком подключит. Оптикой на сто гигабит.
А не в домашний wifi, который раздаёт взятый у оператора CPE с линуксом на борту. В котором ВНЕЗАПНО из коробки практически гарантированно включен stateful фаервол, разрешающий снаружи внутрь проходить только пакеты, относящиеся только established и related соединениям. Такшта домохозяйки и бабушки ровно в такой же безопасности, как и сейчас при ipv4.
budnikovsergey
21.05.2025 09:52большинство пользователей с трудом добираются в настройки фотоприложения своего мобильного телефона, с каковым приложением они не расстаются годами, а вы от них начинаете требовать знание устройства сетей, протоколов и фаерволлов. И что с этим может быть не так? :)
navion
21.05.2025 09:52Лампочки с UPnP злобно потирают руки.
hogstaberg
21.05.2025 09:52Следуя логике господ выше, отключенный на почти каждом CPE из коробки UPnP обычная домохозяйка найти и включить не сможет)
Tzimie
21.05.2025 09:52А роскомтян с IPv6 шалить сложнее или легче?
Doctor5772
21.05.2025 09:52Практика показала, когда "началась деградация YT", первые дни ipv6 помогал. Потом нет. И "что бы сервис не тормозил по всей локалке" пришлось отказаться от него, "по определённым причинам которые теперь нельзя называть, но помогающие починить сервис". Доступность других заблокированных сервисов с ipv6 точно так же решается, и отключением v6 и "настройкой" на роутере.
hssergey
21.05.2025 09:52Всё это хорошо, но сама компания Selectel не дает на своих выделенных серверах ipv6. Только 1 адрес ipv4. А ipv6 только за дополительные деньги. Поэтому подобные статьи от Selectel выглядят для его клиентов издевательски.
hasu
21.05.2025 09:52У меня наверное какой-то неправильный Selectel, но у меня бесплатная /64 подсеть, а дополнительную /64 можно доказать за 32 рубля в месяц, что является не слишком большими деньгами
Gsec
21.05.2025 09:52С ipv4 проще и нагляднее работать в локальных сетях. А ipv6 имеет преимущество именно в интернете. Предположу вариант, что скорее со временем интернет будет только на ipv6, а подавляющее большинство частных и корпоративных пользователей будут иметь роутер, у которого внешний адрес (или пул адресов ipv6), NAT (возможно даже NAT 1:1) и далее локалка ipv4 для всей домашней инфраструктуры.
Т.е. ipv6 полностью не вытеснит ipv4. Они разделят области использования, но продолжат сосуществовать параллельно.
H2oker
21.05.2025 09:52Всё это безусловно прекрасно. Но работать будет только при условии, что никто не будет лезть в трафик и его тем или иным способом цензурировать.
Как только в дело вступает кто-то регулирующий куда ходить можно, а куда нельзя, сразу все эти bgp накрываются медным тазом.
А если это всё ещё и по IP6, то получается вообще винегрет, который никак не будет работать. Столкнулся с этим, когда сервера Ютуба стали внезапно деградировать. Помогло только отключение IP6, который был настроен через IP4, с выделением своего диапазона.
IP4 намного проще конфигуриукется ручками в присутствии неких злобных буратин портящих трафик.
RTFM13
21.05.2025 09:52Утомила эта методичка про опасный NAT и безопасный V6.
Замена серых V4+NAT на белые V6 безопасность не повышает.
Да, NAT не решает всех проблем с безопасностью. Ну так никто и не обещал.
Двойной NAT тоже не особенно проблема. Хоть десятерной, всё прекрасно работает. Ну там могут быть сложности с пробросом портов. И всё.
Первым делом везде в локалках убиваю V6. Потому, что мутная неудобная настройка ради ничего. Недавно после обновления у меня сдох в локальной сети KDE connect. Потому, что какие-то чуда перевели принудительно на V6.
Кстати, то с каким рвением адепты методички "каждому по белому V6" сопротивляются внедрению NAT v6-to-v6 заставляет задуматься о злом умысле.
Aelliari
21.05.2025 09:52Утомила эта методичка про опасный NAT и безопасный V6.
Восхитетельно. Никто не говорит что «nat» опасен, но «v6» тебя защитит. v6 хоть и имеет преимущества перед v4, но в обоих случаях «защитой» должен заниматься фаервол, а не ipv4v6.
Замена серых V4+NAT на белые V6 безопасность не повышает.
NAT - не защита, вообще. NAT - это про сломанную связность в сети
Да, NAT не решает всех проблем с безопасностью
Он их вообще не решает, ибо
так никто и не обещал.
Двойной NAT тоже не особенно проблема. Хоть десятерной, всё прекрасно работает. Ну там могут быть сложности с пробросом портов. И всё.
Спасибо, но нет, это не «прекрасно работает»
Первым делом везде в локалках убиваю V6. Потому, что мутная неудобная настройка ради ничего.
Мне даже любопытно, что же там такого муторного нужно настраивать, я заинтригован
Недавно после обновления у меня сдох в локальной сети KDE connect. Потому, что какие-то чуда перевели принудительно на V6.
Проблемы с вашим софтом в вашей сломанной системе решать только вам. Наверняка меинтейнеры проекта не ждали такой подставы от вас
Кстати, то с каким рвением адепты методички "каждому по белому V6" сопротивляются внедрению NAT v6-to-v6 заставляет задуматься о злом умысле.
Мне непонятен этот тезис, если можно избавиться от трансляции адресов - от неё стоит избавиться. А смысл менять один NAT на другой?
Doctor5772
21.05.2025 09:52NAT - не защита, вообще. NAT - это про сломанную связность в сети
Вообще не в ту сторону уходите.
Зачем провайдеру иметь маршруты до локалхоста клиента? (речь про домашнюю или внутреннюю офисную сеть).
Зачем условному домашнему пользователю наличие до него маршрута из сети? Что бы что? У нас каждый второй поднимает дома Minecraft (или какой там) сервер?
NAT работает нормально в подавляющем большинстве случаев. Я могу понять когда операторам не сильно хочется вливать деньги в NAT, всё таки излишнее железо и издержки, а трафик растёт. Но так же я могу понять зачем условному РКН нужно что бы меньше пользователей было за провайдерскими NAT, уже были слухи о сборах данных в плане "кто, откуда, с каким протоколом и т д" использует трафик в сети, особенно "три весёлые буквы"
firehacker
21.05.2025 09:52Расскажите про CGNAT властям Казахстана.
С недавних пор налоговая отслеживает, с каких IP-адресов отправляются формы налоговой отчетности.
Если зафиксирована отправка отчетов разных юрлиц с одного и того же IP-адреса, считается, что это один и тот же бухгалтер в по сути одном и том же предприятии, которое злонамеренно подробили на несколько юрлиц с целью ухода от налогов.
Соответственно, все такие юрлица берутся «на карандаш».
Alexsandr_SE
21.05.2025 09:52Не знаю, сколько не крутил, NAT позволяет выстроить в квартире четкую систему что с чем взаимодействует и это без выхода наружу. IP6 даст только проблемы. Длинные адреса, которые никак не запомнить нормально, все взаимодействие через фаервол теперь?
Две конторы, соединение через приватную сеть, а роутер уже сам решает что в инет, что по приватной сети пускать, а что внутри сети так и остается. А с отдельными адресами у каждого ящика что делать? Не хочу камеру наблюдения в инете иметь. В локалке с любого места доступ, а по IP6 нужно как-то отслеживать все изменения адресов, и камера и не только легко могут оказаться где-то снаружи портами. Несколько раз в день следить не поменял ли кто адрес в сети, ну так себе идея. Гораздо лучше смотрелась бы концепция NAT IP6. Тогда и свой мирок проще контролировать и от провайдера местами абсолютно не зависишь внутри сети и просто безопасней. Когда придумывали IP6 часто было дома только одно устройство, ну еще парочку добавить и все. Тогда логичным казалось всему дать свой адрес. Сейчас, когда только дома может быть десятки устройств, те же смартфоны имеют опцию динамического изменения MAC при подключении, и куча устройств его позволяет менять настроить сеть адекватно когда все смотрит напрямую в инет еще а задача будет. Я жду NAT IP6-to-IP6. Что бы я решал что в инет смотрит, что нет и это был прозрачно и удобно.hogstaberg
21.05.2025 09:52В упор не понимаю как NAT решает
что в инет смотрит, что нет и это был прозрачно и удобно
NAT транслирует адреса в заголовках. Связность - вопрос роутинга. Безопасность - фаервола. В любом пользовательском CPE/условном микротике/всяких мелкоэнтерпрайзных роутерах/ngfw и прочих таких штуках есть всё из вышеперечисленного.
ponikrf
21.05.2025 09:52Одним ООП не нравится, другим вдруг перестал NAT нравится. Что следующее? Отказ от мышки потому что это вредно для здоровья?
У меня есть несколько будущих заголовков:
«Клавиатуры устарели: Будущее за управлением голосом через крики в микрофон»
«Git — это слишком сложно: Почему возврат к FTP — это прогресс»
«Тёмные темы в IDE вызывают слепоту: Почему белый фон — это must-have»
«Отладка — это харассмент: Настоящие программисты пишут код с первого раза»
«Кэш — это зло: Зачем хранить данные, если можно вычислять их заново?»
«Agile — это секта: Почему водопадная модель вернётся в 2025»
Такие статьи должно быть помечены как юморные.
aik
Защищает не NAT, а роутер - домашний или провайдерский. Злые люди не смогут получить прямого доступа к вашему девайсу, будут всегда упираться в роутер.
Так что если вы не пробрасываете порты для ваших лампочек, то от атак извне они будут защищены.
Vamp
Белый ip на устройстве не означает, что фаервол и фильтрация трафика на роутере автоматически выключаются.
Uporoty
Фаервол на роутере тоже может быть дырявый или с некорректными настройками по умолчанию.
В инфобезопасности всегда работает модель швейцарского сыра - чем больше слоев, тем лучше, даже если какие-то из них дырявые.
aik
Белый IP на устройстве обычно означает то, что оно само смотрит в интернеты, напрямую. Без роутера.
budnikovsergey
NAT an-mass работает именно как отличная защита пользовательских локалок с их незащищёнными устройствами от недружественного интернета с ботами и сканнерами. А отказ от NAT и переход на IPV6 наоборот требует появления поголовной грамотности у всех пользователей и поголовной смены и перенастройки CPE, чтобы зловреды не пролезли и не потёрли любимую многолетнюю подборку фоток на домашнем NAS. И это я ещё не вспоминаю о том, что IPV4 адрес ещё можно держать в голове при администрировании сетей, а IPV6 нет. Так что массовое использование IPV6 пусть и дальше остается у провайдеров вне пользовательских сетей
inkelyad
Всякие домашние NAS-ы, которым в Интернет не надо - им вообще на Link Local адресах надо жить и в зоне .local по имени публиковаться. И точно так же не будут снаружи доступны.
budnikovsergey
это вы каждой бабушке и каждой инстамодели предлагаете знать и уметь настраивать?
inkelyad
Это не надо настраивать. Просто железку в порт включаешь - она это Link Local адрес берет (даже без всяких DHCP) и под своим именем публикуется.
Разумеется, если в сети не отключали 'лишнюю' поддержку IPv6.
wwq_deezer
Товарищ выше, под настройкой, имел в виду, что кроме железкиной Link Local надо озаботиться закрытием железки от интернета, в который она по умолчанию будет светить "голым задом", точнее "голым передом", а бабушки такое не умеют.
inkelyad
Да не будет она. На CPE/домашнем маршрутизаторе будет стоять файрвол с запретом соединений снаружи внутрь по умолчанию. Я подозреваю, что вот в протоколе сертификации на вот этот логотип IPv6 Ready даже требование на этот счет есть.
andreymal
Защищает не роутер, а межсетевой экран. Если его отключить или криво настроить, роутер всё отроутит и даст доступ к лампочкам даже без проброса портов — я проверял это на практике
aik
Ну вот есть обычный бытовой роутер, берёт у провайдера интернеты и раздаёт его домашним девайсам. Что в нём надо отключить, чтобы снаружи можно было получить прямой доступ к лампочке?
andreymal
Для начала определитесь, что такое «снаружи»
Если «снаружи» это провайдер — попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки, и при отключенном на роутере межсетевом экране вы вполне обнаружите эти пакеты в своей локальной сети
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки (я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет), а даже если каким-то чудом смогут, то их отфильтрует межсетевой экран провайдера (а попросить провайдера отключить его собственный межсетевой экран вы уже вряд ли сможете)
aik
Снаружи - это злые хакеры из интернета.
Эта... И как они дойдут?
Внешний IP моего роутера, допустим, 1.2.3.4/24, шлюз - 1.2.3.1
Внутренний роутера - 192.168.0.1, лампочки - 192.168.0.168.
Если я попрошу провайдера попасть на 192.168.0.168 даже со шлюза, то как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?
Именно. Они упрутся в роутер.
andreymal
До вашего роутера они вообще не дойдут, потому что не смогут найти маршрут, ваш роутер не имеет никакого отношения к этой защите
andreymal
А что должно помешать пролезть? Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168, и я не вижу ничего, что остановило бы роутер от совершения такого действия (собственно, его ничего и не останавливает — повторюсь ещё раз, я ПРОВЕРЯЛ описанное вами действие на практике)
vadimk91
Проверяли во своей внутренней сети? В сети провайдера пакет на адрес 192.168.0.168 не будет маршрутизироваться, он до вашего роутера просто не дойдет
andreymal
Провайдеру и не надо его маршрутизировать, бытовой роутер подключен к нему напрямую, провайдер может просто взять и отправить пакет непосредственно в Ethernet-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
budnikovsergey
Linux kernel rp_filter, т.к. большинство клиентских CPE на линуксе
cat /proc/sys/net/ipv4/conf/default/rp_filter
inkelyad
Это на случай, когда src у пакета будет приватный, но пришел на внешний интерфейс.
Так то технически тут правильно и смаршрутизироваться должно. Вот только на каких домашних маршрутизаторах (не микротиках и самоделках) не включен файрволл "запрещаем соединения снаружи внутрь" - непонятно.
budnikovsergey
Да, Вы правы, с легального адреса на внутренний rp_filter пропустит.
И да, Вы правы, по-умолчанию CPE обычно не пускают трафик снаружи внутрь за исключением related,established
andreymal
Ради интереса выполнил для default и для всех интерфейсов на своём кинетике — получил сплошные нули. Это плохо?)
budnikovsergey
зависит от настройки производителем фаерволла. Если там снаружи внутрь можно только умолчательное established/related, то всё ок, иначе провайдер имеет шанс добраться до Вашей любимой коллекции с понями на Вашем домашнем NAS при большом желании.
inkelyad
При большом. Ибо src таких пакетов - в домашней сети. Соответственно, NAS будет отдавать ответные пакеты тоже на адреса домашней сети и до провайдера они дойти бы не должны и без всяких файрволлов.
andreymal
Почему? Не вижу технических причин, которые помешали бы провайдеру прописать в src свой собственный адрес — роутеры именно для того и существуют, чтобы роутить такие адреса туда-сюда между разными сетями
inkelyad
Речь идет про опасность отключенного rp_filter.
Он относится к тем пакетам, у которых src адрес - от внутренней сети, а пришли они - на наружный интерфейс (точнее, пришли с того интерфейса, через который по таблицам маршрутизации этот адрес недоступен).
Если провайдер поставил собственный адрес - он под этот фильтр не попадает.
budnikovsergey
если там есть default gateway прописанный руками или полученный от DHCP, то ответ наружу на маршрутизируемый адрес будет успешным. Другое дело, что по-умолчанию CPE таки не пропустит неинициированный ранее изнутри трафик снаружи внутрь, если нет проброса портов вовнутрь
andreymal
Вышеупомянутую проверку на практике я делал как раз на кинетике и убеждался, что включение фаерволла начинает дропать пакеты, так что буду считать, что всё ок
RTFM13
А что значит упрётся?
(далее пишу упрощенно, но чтобы не потерять суть на примере OpenWRT)
Провайдер может вам в WAN порт послать условно любой набор байт.
Если это эзернет, то любой валидный пакет с мак-адресом роутера или широковещательный на уровне L2, попадёт в ядро. Ядро в заголовке L2 посмотрит номер протокола L3, и если это IP, то передаст на уровень маршрутизации L3. Далее пробежится по таблицам маршрутизации и отправит его в LAN. Порты даже никто смотреть не будет (напомню, что я упрощаю). В правило NAT оно не попадёт т.к. направление противоположное.
В том же OpenWRT древних версий чтобы этого не было надо было добавлять фильтр. Потом вроде его добавили по умолчанию, но это не точно.
Во времена моей провайдерской молодости это была скорее проблема провайдера а не абонента. По лени админов пакеты на локальные адреса уходили по дефолтному маршруту (периодически забегая во внутренние сети провайдера где сидели управляющие интерфейсы оборудования). Плюс можно было получать такой трафик от соседей по широковещательному сегменту (не берусь сказать на сколько это распространено сейчас).
Провайдерам я бы не доверял, особенно крупным именитым, зная как они шарятся по транзитному трафику.
А так локалку может сканировать любое другое устройство в локалке. Те же лампочки. Или любая вкладка браузера через аякс (тут есть нюансы), любое приложение на смартфоне и т.п.
Ну это слабая защита по вышеописанным причинам, но главное, что IPv6 лучше не делает
ildarz
И именно это и есть та самая защита NAT, которой якобы "нет" по мнению авторов статьи и всех остальных, считающих так же.
andreymal
Если злые люди завелись у провайдера — никакой NAT уже не поможет
budnikovsergey
удачи вам в поиске отдельных злых людей, квалификация которых позволит работать в интернет-провайдере за их зарплату и безнаказанно корёжить его ядро с сетью дистрибьюции и доступа только ради доступа к вашей персональной коллекции торрентов. А если вдруг вами действительно заинтересуются спецслужбы, то вы сами им всё на блюдечке принесёте и ещё и будете настойчиво интересоваться устроило ли их то, что вы принесли. Будьте проще: NAT это общественное благо, говорю это как работавший в ISP, в том числе в поддержке в тот момент, когда внешний трафик был помегабайтным и пользователи регулярно влетали в "я этого не качал, за что счёт 100500!?!?"
andreymal
Ну то есть вся «защита NAT» держится лишь на вере в отсутствие заинтересованных злых людей ¯\_(ツ)_/¯
Это, конечно, хорошо работает на практике и я ничего против такого общественного блага не имею, но называть это «защитой», пожалуйста, не надо
budnikovsergey
ох уж это ситхианство с его абсолютом: "если нельзя идеально и навсегда, то значит никак нельзя и ничего делать не надо!" :) NAT это достаточно хорошо со многих сторон, включая простоту и дешевизну CPE, именно поэтому IPV6 до сих пор не в массах, хотя вроде бы о кончине блоков IPv4 уже 2 десятилетия говорят
Yuriy_krd
Уже три) в середине 90-х стали нагнетать вместе с проблемой 2000 )
Uporoty
Я надеюсь вы понимаете, что шансы того, что шанс того, что кто-то из сотрудников провайдера, имеющих доступ к ядру сети и обладающий необходимой квалификацией, захочет взломать ваши устройства - он на несколько порядков ниже, чем ваши устройства захочет взломать какой-то из миллионов кулхацкеров из Китая или любой другой точки земли, массово сканирующих интернет в поисках уязвимостей?
inkelyad
Этим миллионам хакерам сначала придется угадать, на какой из адресов обращаться. А на IPv4 сервисы долбятся просто перебором адресного пространства - логи sshd тому свидетель.
andreymal
Прекрасно понимаю, но это всё ещё не делает фразу «защита NAT» корректной
ildarz
Конечно-конечно. А учитывая, что злые люди могут завестись и в вашей собственной квартире, весь этот разговор о безопасности сетей вообще не имеет смысла, не так ли? И нет, это даже не шутка и не сарказм - вероятность того, что юзеру навредят его собственные родственники, физически добравшись до его девайсов, многократно превышает вероятность проблем со стороны провайдера.
andreymal
Всё так, поэтому я не доверяю не только своей локальной сети, но даже локалхосту (всё, для чего нашлась техническая возможность закрыть и/или зашифровать, у меня закрыто и/или зашифровано, впрочем, я пока ещё не продумал защиту от штук вроде BadUSB или DMA-атак)
budnikovsergey
an-mass только провайдер Интернета сможет отправить на CPE пользователя трафик на локальную сеть 192.168.0.0/24, тогда как злой Интернет не сможет этого сделать своими неусыпными ботосканнерами. Тем массовый NAT и хорош для общественного блага