Поставили новый роутер, запустили онлайн-игру или развернули облачный сервер — и снова натыкаетесь на «двойной 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? Пишите в комментариях!
aik
Защищает не NAT, а роутер - домашний или провайдерский. Злые люди не смогут получить прямого доступа к вашему девайсу, будут всегда упираться в роутер.
Так что если вы не пробрасываете порты для ваших лампочек, то от атак извне они будут защищены.
Vamp
Белый ip на устройстве не означает, что фаервол и фильтрация трафика на роутере автоматически выключаются.
Uporoty
Фаервол на роутере тоже может быть дырявый или с некорректными настройками по умолчанию.
В инфобезопасности всегда работает модель швейцарского сыра - чем больше слоев, тем лучше, даже если какие-то из них дырявые.
Pinkbyte
А NAT дырявым по этой же логике быть не может?
Uporoty
Последствия будут сильно разные.
Если у вас фаервол - единственное звено защиты, то при дырке в фаерволе - все, you are fucked. А дырка типа "фаервол отключен по умолчанию" или "фаервол не применяет какое-то правило" довольно проста сама по себе.
А вот если у вас NAT, то во-первых это не отменяет наличие фаервола - должна быть дырка и там и там одновременно.
Во-вторых, как именно вы себе представляете эту дырку? Суть NAT'а - что внутри сети и снаружи будет разная адресация. Пакет с "внутренним" адресом до вашего роутера тупо не дойдет по сети провайдера, а пакет с внешним адресом не уйдет от роутера во внутреннюю сеть. И даже если в NAT'е будет какая-то фантастическая дырка (это прям очень сильно постараться надо), что он зачем-то объявит какой-то из внутренних адресов DMZ и устроит туда полный порт-форвардинг с трансляцией адресов, то... вас защитит еще один провайдерский NAT :)
Короче, классическая для информационной безопасности модель швейцарского сыра во всей красе.
aik
Белый IP на устройстве обычно означает то, что оно само смотрит в интернеты, напрямую. Без роутера.
Wallhead
У меня белый айпи на роутере. Девайсы внутри за роутером сидят
aik
Так про это и речь. Девайсы за роутером недоступны извне (без дополнительных настроек). Потому они и защищены от атак. И NAT тут не причём. А вот если у всех лампочек будут реальные IP, то вам придётся думать о том, как их защищать.
M_AJ
Ну они же будут подключены в интернет через тот же роутер, через который они подключены сейчас. На нем и будет фаервол, как и сейчас.
Lev3250
Устройства за роутером тоже могут иметь белый ip. Если провайдер дал несколько. Но это прям редко-редко бывает
M_AJ
Ну да, но это так и в случае ipv4, можно купить белых ip4 адресов у провайдера, и выдать их на оборудование. Просто все уже от этого отвыкли, а привыкли к "костылю"
PereslavlFoto
Просто на это нужно столько денег, что их невозможно заработать.
gxcreator
В домашнем IPv6 это классика, провайдер выдает префикс, а не адрес.
aik
Если у всего оборудования реальные IP, то роутер не нужен же, простого свитча достаточно.
А если всё равно будет роутер, то нахрена оборудованию реальные IP?
Оно и так нормально живёт с приватными.
M_AJ
За тем же, за чем они и сейчас – чтобы устройства могли, если это нужно, соединиться друг с другом напрямую, чего в общем случае не могут два устройства с локальными адресами, и им приходится общаться через сервер с белым IP.
aik
Так всё равно впн является более безопасным вариантом для общения напрямую, чем прямая связь через интернеты. Не все же протоколы шифруются и т.п.
Так что возможность прямого доступа к лампочке я за достоинство не считаю.
M_AJ
Чтобы построить VPN-туннель вам все равно нужно устройство с белым адресом. В случае если в вашем распоряжении такого нет (или вам кто-либо не дал таким попользоваться), то и туннель вы не построите. Кроме того, вы ограничены направлением в котором можете строить туннель, только от серого к белому. В итоге если у вас 1 устройство с белым адресом и 5 с серым, то оно становится единой точкой отказа для вашей частной сети.
aik
Так в любом случае точкой отказа при построении впн является впн-сервер.
M_AJ
Зависит от протокола. В OpenVPN одно и то же устройство может быть и клиентом и сервером одновременно. В WireGuard по сути вообще нет разделения на клиента и сервера. В итоге количество VPN-серверов в вашей сети будет технически ограниченно только количеством белых адресов.
aik
Да-да, так и представляю впн-сервера на лампочках.
M_AJ
Не знаю почему вы о лампочках постоянно думаете :) Но даже так, в этом ничего нереального, как я уже говорил, в WireGuard (а это сейчас один из самых популярных протоколов для построения частных сетей) вообще нет разделения на клиента и сервер.
aik
Так мы же начали про защиту тупых девайсов, которые сами защищаться не умеют. И про то, что лампочке накручивать системы безопасности не обязательно, если она закрыта роутером - с приватным IP злые хакеры до неё не доберутся.
M_AJ
Такие устройства будут точно так же закрыты роутером, только с помощью фаерволла, а не с помощью NATа. А хакеры скорее доберутся до лампочки через сервера производителя лампочек, на которые они сейчас вынуждены ходить, чтобы связаться с управляющей программой на телефоне, ведь и лампочка и телефон за NATом.
Aelliari
в 2025? Не совсем, если NAT не совсем злой, то можно и между двумя серыми. Но все равно нужен будет сервер с белым IP который поможет согласовать вам соединение, и выступит релеем в случае неудачи.
P.S. Хотя вроде старый добрый ipsec так тоже умел… но внятной инструкции я не находил, а сам доки не штудировал
M_AJ
Туннель в любом случае будет строиться от серого адреса к белому, то есть инициатором построения туннеля должно быть устройство с серым адресом. Если оба устройства с серыми адресами, то для построения туннеля между собой они оба должны инициировать построение туннеля к какому-либо устройству с белым адресом.
У IPsec как раз вообще все плохо с натом и для работы за натом ему нужен NAT-T.
Aelliari
Нет, координирующий сервер с белым ip может попытаться «пробить» NAT для двух участников, и передать им адреса друг друга. И в случае успеха они смогут отправлять трафик друг другу в дальнейшем без участия координирующего сервера.
Фактически туннель будет между двумя устройствами, где оба могут находиться за NAT.
Прогуглите про zerotier/tailscale/netbird...
Но технически, да, сначала инициализируется подключение к устройству с белым адресом. Но я так и написал в предыдущем сообщении
M_AJ
Ну да, именно это я и имел в виду и мы говорим почти об одном и том же, просто я видимо "чрезмерно упростил", отвечая на сообщение aik, чтобы не закапываться в дебри реализаций. Ведь по сути без внешнего сервера не обойтись, не важно, будет ли это STUN, с помощью которого пиры найдут друг друга, как в Netbird, или трафик будет постоянно идти через это устройство с белым адресом, как в случае классического OpenVPN – это уже детали, которые зависят от конкретной реализации. Но ключевые моменты те же: устройство с белым адресом необходимо, и инициировать соединение должно устройство с серым адресом, а если их два, то они оба должны инициировать соединение с промежуточным сервером. То есть именно они обязаны начать строить туннель, отправив запрос в сторону сервера с белым адресом, а будет это STUN либо классический OpenVPN сервер это уже детали.
Ravius
Через какой сервер им приходится общаться?
И как вы поймёте что общаетесь именно с тем устройством с которым вы хотели общаться, а не с MItM'ом (ток что придумал man in the middle)
Wallhead
Ну а почему нельзя так и делать? Белый на роутере, все остальное за ним.
aik
А почему нельзя? Так ведь и делаем сегодня.
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 даже требование на этот счет есть.
BugM
А потом в нем найдется бага. Не-не-не. Роутер на сером IP провайдера и серые-серые адреса за ним это прямо идеальное решение по защите всего домашнего зоопарка.
Не должны домашние железки светиться в интернете. И адресуемы быть не должны. Пусть провайдер решает все проблемы.
И на этом ipv6 в массах можно закапывать. Оно скорее вредит среднему человеку. Оставьте его для особых случаев и хватит.
Можно начать думать про ipv8. Нормальном, а не как ipv6.
Aelliari
И начнётся тоже самое, зачем этот IPv8, когда есть нормальный IPv6. Мы столько раз это проходили с виндой, что… Нет, с накопленным опытом, в 2025 спроектировать протокол лучше чем v6 человечество может, но и v6 лучше чем v4
nixtonixto
Как тогда удалённо войти в админку роутера?
geher
Включить соответствующий доступ. На некоторых старых роутерах, кстати, это было включено по умолчанию. Не удивлюсь, если и сейчас с такой установкой по умолчанию выпускают
navion
Через приложение в облаке типа Eero или Keenetic.
Tippy-Tip
Админить роутер через приложение в "облаке"? Очень смешно. Особенно в свете Keenetic.
Lev3250
Стоит отдать им должное, роутеры от облака не отвалилисьи работают (по крайней мере пока что)
inkelyad
Поставить галочку 'хочу рулить снаружи' и роутер сам на собственном же файрволле откроет порт на доступ с этого самого внешнего мира.
savagebk
Безопаснее организовать доступ в локальную сеть через VPN и рулить роутером из локалки.
inkelyad
Это правильнее, да. Но вряд ли разница большая.
Сломают либо через дырку в интерфейсе маршрутизатора, либо через дырку в VPN сервисе.
Lev3250
Через несколько лет эти понятия можно будет объединить
ultraElephant
```deny ip any any``` выставленное производителем никто не отменяет
blind_oracle
Никакой разницы по безопасности нет между IPv4+NAT и IPv6 нет.
И там и там работает Connection Tracking и прочий Stateful Firewall, который пропускает в локалку только пакеты для уже открытых изнутри соединений, поэтому микроволновок ваших из интернетов видно не будет.
NAT к этому всему вообще ортогонален, он просто присасывется к Connection Tracking и транслирует один адрес в другой для установленных соединений.
RolexStrider
Да, conntrack с банхаммером ОЧЕНЬ хорошо отбивают всякие нападки. Как правило быстро заносят в свой блеклист, типа "с этим лучше не связываться". Но вот на роутерах "потребительского" класса почти никогда не видел. Казалось бы: ну возьмите тот же OpenWRT, натяните на веб-морду скин какой вам нравится - и... Но нет. В свое время уважал ZyXEL (со времен их модемов) - но и эти походу спаскудились. Так что Raspberry + hostapd + свои мозги = более-менее рабочий вариант.
blind_oracle
Не очень понимаю о каком банхаммере речь. Файрволл практически на любом SOHO роутере блокирует соединения снаружи внутрь локалки, как IPv4, так и IPv6.
Lev3250
Может он про микрот. hAP какой-нибудь. Маскарад накинул и вперёд. Но 99% домашних роутеров всё-таки имеют защиту от дурака
andreishe
"en masse"
antitectress
я тоже хотел поправить, но решил так сильно не душнить.
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-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
drw
Под "сетью провайдера" имеется в виду широковещательный сегмент вашего роутера и куска сети провайдера. То есть вашему соседу достаточно сделать
ip r a ваша.серая.квартирная.сеть/24 via внешний.адрес.вашего.роутераЧего, частенько, будет достаточно, чтобы общаться с вашими лампочками.
Защита сети — фаервол на маршрутизаторе. И его настройки по-умолчанию могут быть как адекватными, так и нет, безотносительно версии ip.
sirmax123
Это если у провайдера нет изоляции клиентов (это зависит от провайдера и в общем случае, лучше когда она есть)
drw
Строго говоря, если клиенты изолированы, то они не в одном широковещательном сегменте :)
aik
Ни разу не видел, чтобы была настроена подобная маршрутизация на бытовых роутерах.
Сейчас попытался так сделать - не работает. Ни трасса, ни пинги не доходят до компа за роутером. Причём роутер даже в трассе не появляется.
andreymal
Вы не забыли отключить фаервол?
aik
Отключен.
andreymal
Тогда не знаю что вы делаете не так
Ладно, вы все вынудили меня снова раздолбать мою сеть и повторить эксперимент
Лабораторное оборудование:
длинк с IP-адресом 1.2.3.1 и DHCP-сервером в роли провайдера
кинетик с «внешним» IP-адресом 1.2.3.4 и внутренним IP-адресом 192.168.0.1/24 в роли бытового роутера
компьютер с IP-адресом 192.168.0.168 в роли «лампочки»
гипотетический пользователь этих бытового роутера и «лампочки», который в сетях ничего не понимает
я в роли злого людя, который устроился на работу к провайдеру специально чтобы хакать лампочки
Никакие порты не проброшены, никакие дополнительные маршруты не добавлены (на скриншоте выше кинетик сам сгенерировал маршруты для своей работы)
Итак, поехали: я в качестве злого людя, хочу найти лампочку и подключиться к ней. Процесс поиска IP-адреса опустим, предположим, что я узнал или узнаю перебором, что это именно 192.168.0.168
Так как я провайдер и имею доступ к своему собственному длинку, я могу творить тёмные дела прямо на нём. Захожу на длинк и пробую подключиться к лампочке:
Ой, Network is unreachable
Ну в общем-то логично, откуда длинку знать, куда отправлять пакеты с локальными IP-адресами
Но я же провайдер и имею полный контроль над длинком!
Не проблема — добавляю маршрут для локальных IP-адресов
Пробую ещё раз:
Опаньки
Ошибка исчезла — длинк успешно отправил пакет, но кинетик его дропнул, потому что межсетевой экран делает своё тёмное дело
В захвате трафика на кинетике можно увидеть, что он успешно получает пакеты, но дальше они дропаются межсетевым экраном
Здесь выяснилось, что выключить межсетевой экран на кинетике нельзя ¯\_(ツ)_/¯
Так что вместо выключения смоделирую немного другую ситуацию:
Пользователь пытался запустить майнкрафт-сервер и своими кривыми руками надобавлял разрешающих правил в роутер
Напомню, что мы проверяем ваше утверждение «как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?», поэтому в рамках данного эксперимента такое устранение влияния межсетевого экрана тоже корректно
Никакие порты НЕ проброшены
(UPnP кстати тоже не установлен)
Ну, что, ещё одна попытка?
ААААААААААА
Без межсетевого экрана кинетик успешно отроутил пакет из внешней сети во внутреннюю
Скриншот из Wireshark, запущенного на «лампочке», это подтверждает
Удаляем разрешающее правило из межсетевого экрана кинетика — пакеты перестают появляться в Wireshark на «лампочке»
Таким образом, по итогам этого эксперимента в очередной раз повторю — NAT ЭТО НЕ ЗАЩИТА, защищает именно межсетевой экран, без него пакеты до лампочки прекрасно пролезают через роутер
Doctor5772
Это хороший дополнительный фактор к защите. Потому что если злоумышленник захочет зайти на условный "192.168.0.х" в домашней сетке удалённо, ему придётся сперва ломануть роутер, а уже от него пойдёт доступ. Но, если мы говорим про провайдерский NAT, сперва придётся как то ломануть именно провайдерскую железку, потому что на внутреннюю серую адресацию (которая не анонсируется в сеть, если что) извне не попасть. Иными словами, "чем помогает NAT - тем что на серую подсеть без анонса не попасть так же как если стучать через белую адресацию". IPv6 с раздачей префиксов облегчает жизнь злоумышленнику. И не надо про firewall и роутеры, уязвимости никто не отменял, а маршруты до условной лампочки с ipv6-пабликом будут
BugM
Вы во тут очень хорошо написали:
Не просто устроился. А на нормальную должность с доступом к редактированию ядра сети. И не просто хакать, а наследить в логах так что как минимум уволят а как максимум посадят без проблем и быстро.
Сравните с безымянным миллионом китайцев которые смогут делать тоже самое в вашем ipv6.
Вот это и есть настоящая защита предоставляемая всем НАТом. Вообще всем, независимо от их знаний и умений.
andreymal
После, например, провайдерского MITM на jabber.ru мой внутренний параноик предпочитает на всякий случай предполагать, что возможно всё
BugM
Сравните с миллионом китайцев, про которых никто уже не пишет и которые ежедневно рутинно сканят все.
Поверхность атаки это важное понятие.
RTFM13
Вы о чем вообще? У всех крупных операторов целые отделы занимаются воровством данных и слежкой за пользователями. Проблема роутинга внутрь сети стала широко известна когда лет 15 назад какой-то оператор засветился с этим.
Но вообще внутри сети хватает потенциальных источников и без этого. Вы уверены что пока вы читаете это сообщение, скрипты на странице с этим сообщением не подбирают пароль к вашему роутеру?
BugM
Вы серьезно? Пруфов естественно не будет? Целые отделы это прям много народа и пруфы соответствующие нужны, а не когда одного человека за 10 лет поймали. Один человек за 10 лет как раз укладывается в крайнюю редкость таких случаев.
CSP это шутка для вас? Давно все уже сделано.
RTFM13
В 2025-м году просить пруфы на то что опсосы подслушивают и воруют персональную информацию, это не просто незамутнённость, а прям хуцпа 80го уровня.
Ладно со скриптами в конфигурации по умолчанию доступа в большинстве случаев нет. Я то в курсе, регулярно веб-интерфейсы отлаживаю и знаю способы обхода CORS). Но остаются гигабайты говнокода на ввсех устройствах в сети. Вы готовы поручиться за каждое устройство, каждое приложение, каждую лампочку?
kamaz1
Мне бы пруфы, я знаю операторов которые не воруют. Они маленькие, потому можно сказать что знаю целых операторов. И не знаю ни одного который ворует. Что вобще можно своровать изнутри https или любого другого шифрованного протокола?
Да и вопрос то был в том, что бы попасть внутрь клиентской сети за НАТ, а не о том что "все" снифают трафик.
BugM
Конечно нужны. Я даже близко ничего похожего не слышал. Реклама да. Но это не оно. Идти на уголовное дело с отзывом лицензии нафиг им надо? Тем более что профита не видно.
Хром вообще любые походы в локальную сеть из js запретил по дефолту. И тут о вас добрые люди подумали.