В последнее время мы всё чаще слышим не самые приятные новости про IP-адреса. Компания AWS объявила, что будет брать по $0,005/ч. за каждый адрес IPv4, тем самым присоединившись к другим облачным провайдерам, сделавшим платным использование публичного адреса IPv4. GCP просит с клиентов по $0,004/ч., а Azure и Hetzner — по €0,001/ч. Очевидно, что эпоха, когда облачные провайдеры расширялись, скупая дополнительное пространство IPv4, подходит к концу. Чем дальше, тем ценнее становятся эти адреса, и тем менее целесообразно предоставлять их бесплатно.
Так что перспективы ясны — нам нужно переходить на IPv6. Впервые о необходимости перехода на IPv6 я услышал, когда учился в колледже, а сейчас мне 36. Это я к тому, чтобы вы поняли, как давно стали очевидны эти перспективы. До этого с IPv6 я не работал, на рынке практически отсутствовал спрос на соответствующие навыки, и мне не доводилось трудиться в компаниях, где бы эта тема кого-то интересовала. Поэтому и осваивать я её не стал, и зря, ведь она прекрасно дополнила бы мои навыки в сфере сетевых технологий.
Но теперь настал очередной удачный момент, чтобы этим заняться, и я решил перевести свой блог исключительно на IPv6. Он будет находиться за CDN для обработки трафика IPv4, но всё же пора уже вступить в ряды крутых ребят. Однако в процессе я выяснил одну весьма неприятную вещь: в IPv6 практически ничто не работает «из коробки». Основные зависимости тут же слетают, а обходные решения оказываются не готовыми к продакшену. Процесс перевода команд на IPv6 будет очень тернистым, преимущественно из-за того, что никто ещё с этим не сталкивался. Мы многие годы откладывали освоение этой технологии, и теперь придётся за это платить.
Почему IPv6 стоит приложенных усилий?
Я не собираюсь подробно сравнивать IPv4 и IPv6. В сети есть множество прекрасных статей на эту тему. Давайте просто вкратце посмотрим «Почему вообще есть резон переходить на IPv6».
Заголовок пакета IPv6
- Пространство адресов (это очевидно).
- Меньше полей заголовков (8 против 13 в v4).
- Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не нужно выполнять перерасчёт для каждого пакета.
- Ускоренная маршрутизация: больше общих и иерархических маршрутов. (Не знаете, что такое «общий маршрут»? Поясню. Общий маршрут равнозначен совмещению нескольких IP, благодаря чему вам уже не требуются все эти адреса, только их общее направление, основанное на первой части адреса. То же самое касается маршрутов. Поскольку адреса IPv6 уникальны по всему миру, вы можете использовать компактную и эффективную магистральную маршрутизацию).
- QoS (качество обслуживания): поля Traffic Class (класс трафика) и Flow Label (идентификатор потока) упрощают предоставление качественного сервиса.
- Автоматическая адресация. Позволяет хостам IPv6 в сети LAN подключаться без маршрутизатора или DHCP-сервера.
- Можно добавить в IPv6 набор протоколов IPsec с Authentication Header (заголовком аутентификации) и Encapsulating Security Payload (безопасной инкапсуляцией полезной нагрузки).
Ну и самое значительное: потому что адреса IPv6 свободны, в отличие от адресов IPv4.
Настройка сервера исключительно на IPv6
По факту процесс настройки оказался прост. Я подготовил ПК с Debian и выбрал «IPv6». Затем возник первый сюрприз. Мой компьютер не получил адрес IPv6. Мне было выдано /64 адресов, а именно 18,446,744,073,709,551,616. Приятно осознавать, что мой скромный сервер на ARM смог масштабироваться для запуска всей сетевой инфраструктуры в каждой компании, где я работал, на всех публичных адресах.
Такой подход кажется растратным, но если рассмотреть принцип работы IPv6, выяснится, что это не так. Поскольку IPv6 намного менее «говорлив» в сравнении с IPv4, то даже когда у меня в сети было 10 000 хостов, это ничего не меняло. Как уже говорилось, есть смысл сохранить всё пространство IPv6, даже если сначала это покажется безумно затратным. Так что просто не думайте, сколько адресов отправляется на каждое устройство.
Важно: противьтесь желанию оптимизировать использование адресов. Общаясь с более опытными системными администраторами, я понял, что это типичная ловушка, в которую попадают очень многие. Мы все зачастую волновались, сколько пространства осталось в блоке IPv4, и проводили немало времени за поиском решений этой проблемы. Теперь же она просто исчезла. Префикс /64 является минимальным, какой вам нужно настроить в интерфейсе.
Попытка использовать префикс ещё меньше, например, /68 или /96, как известно по опыту некоторых специалистов, может нарушить автоконфигурацию адресов без сохранения состояния. На каждый сайт вам нужно подразумевать префикс /48. Именно такое значение выдаётся региональным интернет-регистратором при выделении IPv6. Продумывая организацию сети, вам также нужно определиться с ограничением по полубайту (nibble boundary). По сути, этот способ упрощает чтение IPv6.
Предположим, у вас адрес 2402:9400:10::/48. Если вы захотите получить для каждой машины в однотипной сети только /64, то поделите его так:
| Подсеть | Адрес подсети |
| 0 | 2402:9400:10::/64 |
| 1 | 2402:9400:10:1::/64 |
| 2 | 2402:9400:10:2::/64 |
| 3 | 2402:9400:10:3::/64 |
| 4 | 2402:9400:10:4::/64 |
| 5 | 2402:9400:10:5::/64 |
| Подсеть | Адрес подсети |
| 0 | 2402:9400:10::/52 |
| 1 | 2402:9400:10:1000::/52 |
| 2 | 2402:9400:10:2000::/52 |
| 3 | 2402:9400:10:3000::/52 |
| 4 | 2402:9400:10:4000::/52 |
| 5 | 2402:9400:10:5000::/52 |
Хорошо, свою машину я подготовил. Теперь попробуем настроить на ней рабочий сервер.
▍ Проблема 1 — не могу подключиться по SSH
Это была ожидаемая проблема. Протокол IPv6 не поддерживается ни моим домашним провайдером, ни рабочим. Так что хорошо, что я настроил свою машину, но сделать теперь с ней я ничего не могу. Ладно, пока что я подключил адрес IPv4, установил соединение по SSH и далее настрою
cloudflared для запуска туннеля. Возможно, этот сервис выполнит преобразование на своей стороне.Вот только Cloudflare работает иначе. Представьте себе моё удивление, когда в момент удаления адреса IPv4 туннель закрылся. По умолчанию утилита
cloudflared предполагает использование IPv4, и вам необходимо добавить в служебный файл systemd следующее: --edge-ip-version 6. После этого туннель заработал, и подключиться по SSH мне удалось.▍ Проблема 2 — не могу использовать GitHub
Хорошо, система налажена. Теперь пора заняться настройкой всего остального. Я запускаю скрипт конфигурации сервера, и он тут же даёт сбой. Он пытается обратиться к инструкциям установки hishtory, прекрасной программы отслеживания истории оболочки, которую я использую для всех своих задач. Скрипт безуспешно пробует получить с GitHub файл её установки. «Но это очень странно. Ведь GitHub должен поддерживать IPv6?»
А вот и нет. Конечно, очень плохо, что сервис, через который разработчики по всему миру выпускают ПО, не поддерживает IPv6. Но ведь и у Microsoft возникли проблемы, и теперь эта компания занимается только фальшивым ИИ, так что какая разница? В итоге я успешно использовал TransIP GitHub Proxy. Теперь у меня есть доступ к GitHub. Но далее Python выдал
urllib.error.URLError: <urlopen error [Errno 101] Network is unreachable>. Ладно, сдаюсь. Предполагаю, что версия Python 3 в Debian не дружит с IPv6, но сейчас я не в настроении с этим разбираться.▍ Проблема 3 — не могу настроить Datadog
Займёмся чем-то попроще. Я определённо могу настроить Datadog, чтобы следить за своей машиной. Мне не нужно множество метрик, лишь несколько исторических данных о загрузке. Перехожу в Datadog, авторизуюсь и запускаю процесс… Сразу же сбой. Простая настройка подразумевает выполнение
curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh. Но ведь S3 поддерживает IPv6, тогда какого чёрта?curl -v https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh
* Trying [64:ff9b::34d9:8430]:443...
* Trying 52.216.133.245:443...
* Immediate connect fail for 52.216.133.245: Network is unreachable
* Trying 54.231.138.48:443...
* Immediate connect fail for 54.231.138.48: Network is unreachable
* Trying 52.217.96.222:443...
* Immediate connect fail for 52.217.96.222: Network is unreachable
* Trying 52.216.152.62:443...
* Immediate connect fail for 52.216.152.62: Network is unreachable
* Trying 54.231.229.16:443...
* Immediate connect fail for 54.231.229.16: Network is unreachable
* Trying 52.216.210.200:443...
* Immediate connect fail for 52.216.210.200: Network is unreachable
* Trying 52.217.89.94:443...
* Immediate connect fail for 52.217.89.94: Network is unreachable
* Trying 52.216.205.173:443...
* Immediate connect fail for 52.216.205.173: Network is unreachable
123456789101112131415161718Проблема не в S3 или машине, потому что я вполне могу подключиться к тестовому бакету S3, который предоставляет AWS.
curl -v http://s3.dualstack.us-west-2.amazonaws.com/
* Trying [2600:1fa0:40bf:a809:345c:d3f8::]:80...
* Connected to s3.dualstack.us-west-2.amazonaws.com (2600:1fa0:40bf:a809:345c:d3f8::) port 80 (#0)
> GET / HTTP/1.1
> Host: s3.dualstack.us-west-2.amazonaws.com
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 307 Temporary Redirect
< x-amz-id-2: r1WAG/NYpaggrPl3Oja4SG1CrcBZ+1RIpYKivAiIhiICtfwiItTgLfm6McPXXJpKWeM848YWvOQ=
< x-amz-request-id: BPCVA8T6SZMTB3EF
< Date: Tue, 01 Aug 2023 10:31:27 GMT
< Location: https://aws.amazon.com/s3/
< Server: AmazonS3
< Content-Length: 0
<
* Connection #0 to host s3.dualstack.us-west-2.amazonaws.com left intact
1234567891011121314151617Хорошо. Я проделаю всё вручную через apt.
0% [Connecting to apt.datadoghq.com (18.66.192.22)]Да ёпрст! Ладно, Datadog исключается. В этот момент я понял, что эксперимент с использованием только IPv6 не сработает. Почти ничто не работает напрямую без посредника или всяческих ухищрений. Попробую по максимуму придерживаться IPv6, но использовать только его пока точно не вариант.
NAT64
Для доступа к ресурсам IPv4 через IPv6 вам нужно пройти через сервис NAT64. Я использовал этот. Тут же все мои проблемы исчезли. Я немного переживаю, насколько можно доверять процессы взаимодействия с критическими интернет-ресурсами сервису, по сути являющемуся хобби-проектом. Но раз уж, по всей видимости, ни один из восходящих сервисов не утруждается налаживанием работы IPv6, то выбора у меня особо не остаётся.
Я удивлён, насколько мало доступно альтернатив. Вот весь список провайдеров, какой мне удалось собрать:
Большинства из них сейчас уже нет. Связь Dresel не работает, Trex в ходе тестирования вызывал проблемы, August Internet закрылся, большинство тестовых устройств Go6lab отключены, Tuxis сработал, но их сервис был запущен в 2019 и, похоже, с тех пор не дорабатывался. По сути, Kasper Dupont является единственным, реально заинтересованным в продвижении IPv6. Спасибо тебе, Kasper.
Да, по факту развитие этого сегмента всемирной сети держится на плечах всего одного человека.
▍ Kasper Dupont
Мне стало интересно познакомиться с этим энтузиастом, и я написал ему письмо с несколькими вопросами. Вот часть нашей переписки:
Я: Лично мне сервис Public NAT64 показался очень эффективным инструментом перехода, но я хотел бы побольше узнать, почему вы этим занимаетесь.
Каспер: я делаю это в первую очередь ради продвижения IPv6. В течение нескольких лет у меня была возможность пользоваться дома нативной сетью исключительно на IPv6, используя DNS64+NAT64, и мне этот опыт очень понравился. В результате я просто захотел дать и другим людям возможность его испытать.
Когда я поднял первый шлюз NAT64, это стало просто подтверждением работоспособности расширения NAT64, которое я хотел распространять. Сервис NAT64 стал популярен, а вот расширение не особо.
Несколько месяцев назад я, наконец, наладил нативный IPv6 у себя в новом доме, поэтому сейчас могу использовать собственный сервис так, как предполагается его использование целевыми потребителями.
Я: Похоже, ваш сервис является одним из немногих оставшихся в бесплатном доступе, и мне бы хотелось понять, что подталкивает вас продолжать этим заниматься, сколько стоит его обслуживание, да и любые мысли, какими вы бы сами хотели по этому поводу поделиться.
Каспер: Под мои личные продукты у меня запущено 7 виртуальных машин, подключённых к разным хостингам. Некоторые из них я арендую у Hetzner по 4,51 евро в месяц.
Другие VM обходятся чуть дороже, но ненамного.
Из всех машин 4 используются для сервиса NAT64, а остальные для других сервисов, связанных с переходом на IPv6. Например, на отдельной VM у меня работает этот сервис.
Надеюсь, что в итоге договорюсь с промежуточными провайдерами и смогу расширить возможности сервиса, а также сделать его прибыльным. Это бы позволило мне посвятить себя работе над IPv6 полностью, а не частично, как это есть сейчас. Идеальным исходом будет, если провайдеры, работающие только с протоколом IPv4, будут оплачивать расходы в рамках своих платежей за использование пропускной способности.
Я: Было бы здорово, если бы вы рассказали о каких-нибудь технических деталях своего проекта.
Каспер: Сразу видно — свой человек :-)
Я могу углубиться в детали очень сильно.
Думаю, что мой сервис отделяет от других то, что каждый из моих серверов DNS64 автоматически обновляется префиксами NAT64 на основе проверки состояния всех шлюзов. Это означает, что выход из строя любого отдельного шлюза NAT64 окажется для потребителей практически незаметен. Кроме того, это упрощает обслуживание. Думаю, благодаря этому, мой сервис предоставляет один из высочайших уровней доступности среди всех публичных сервисов NAT64.
Весь код NAT64 разработан мной, и на данный момент он выполняется как демон в пространстве пользователя Linux. Правда сейчас я подумываю о переносе наиболее важной для производительности части в модуль ядра.
Сайт оригинала статьи
Хорошо, всё основное я наладил. Для передачи контейнеров Docker через IPv6 вам потребуется добавить в начало имени образа следующее:
registry.ipv6.docker.com/library/. Например, image: mysql:8.0 станет image: registry.ipv6.docker.com/library/mysql:8.0.Docker предупреждает, что данная конфигурация не готова к использованию в продакшене. Я не уверен, что это конкретно значит для Docker. Возможно, если всё наладить, то вы просто сможете скачивать образы как обычно?
Разобравшись с этим, я настроил сайт как запись DNS AAAA и позволил Cloudflare выступить в качестве посредника, то есть этот ресурс сможет обрабатывать оповещения IPv6 и перенаправлять трафик ко мне. По сравнению с прежней конфигурацией я изменил одну вещь. Раньше я использовал веб-сервер Caddy, но поскольку теперь бо́льшая часть моего трафика поступает через Cloudflare, я переключился на Nginx. Зная, что весь трафик поступает от Cloudflare, вы можете ради удобства сменить режим работы SSL.
Теперь у меня в Nginx загружен сертификат Origin из Cloudflare с настроенной функциональностью Authenticated Origin Pulls, поэтому я уверен, что весь трафик поступает именно через Cloudflare. Этот сертификат выдаётся на 15 лет, так что я могу уверенно внедрить его в систему управления учётными цифровыми идентификационными данными и забыть. Для интересующихся этой темой есть хорошее руководство.
Отлично. Сайт налажен и работает.
Нерешённые проблемы
- Мои контейнеры по-прежнему не могут взаимодействовать с ресурсами IPv4 несмотря на то, что находятся в сети IPv6 с мостом IPv6. Разрешение имён DNS64 работает, и я также добавил в Docker
fixed-cidr-v6. Я могу прекрасно взаимодействовать с ресурсами IPv6, но преобразование NAT64 не функционирует. Буду с этим разбираться. - Пришлось добавить NAT с ip6tables.
- Проблемы с SMTP-сервером. Я не смог найти коммерческий SMTP-сервис, имеющий запись AAAA. Я опробовал Mailgun, SES и несколько более мелких — ни один не подошёл. Даже Fastmail не сгодился. Если вам известен хороший вариант, будьте добры, напишите мне сюда.
Почему бы не продолжать использовать IPv4?
Давайте на минуту забудем, что у нас кончаются адреса. Если бы мы начали внедрять IPv6 раньше, то построение инфраструктуры происходило бы совсем иначе. Компании зачастую используют такие технологии, как балансировщики нагрузки и туннели, не потому что фактически нуждаются в них, а потому что им требуется некий способ разделить закрытые IP-диапазоны и открытый IP-адрес, который они могут внести в запись DNS А.
Если разбить балансировщик нагрузки на составляющие, то он выполняет две задачи: распределяет входящие пакеты по внутренним серверам и проверяет состояние этих серверов, исключая нездоровые из ротации. Сегодня эти инструменты зачастую обрабатывают такие процессы, как завершение SSL и сбор метрик, но эта функциональность не является для них необходимой.
Балансировать нагрузку можно множеством способов, но самыми распространёнными являются следующие:
- Round-robin. Круговая обработка запросов на подключение.
- Weighted Round-robin. Взвешенная круговая обработка, в результате которой сервера получают больше или меньше нагрузки.
- Least-Connection. При получении новых запросов их распределение происходит по серверам с наименьшим числом подключений.
- Weighted Least-Connection. То же самое, но можно отдавать приоритет определённым машинам.
Как видите, здесь нет ничего, что требовало бы или получало преимущество от использования закрытого IP-адреса вместо публичного. Настройка хостов для получения трафика только от одного источника (балансировщика нагрузки) производится просто и относительно дёшево в вычислительном смысле. Многие схемы инфраструктуры, с которыми мы оказались вынуждены работать, например, VPC, шлюзы NAT, публичные и закрытые подсети — без всех них можно было либо обойтись полностью, либо опираться на эти решения в меньшей степени.
Ещё одна ирония заключается в том, что практика формирования белых списков IP-адресов, которая сейчас является неактуальной, поскольку мы все используем адреса, принадлежащие облачным провайдерам, в этом случае оказалась бы кстати. С появлением спроса компаниям стало бы проще приобретать для себя адреса с префиксом /44, и люди бы начали чаще обращаться за покупкой блока IP-адресов в Американский реестр номеров интернета (ARIN), Координационный центр распределения ресурсов сети интернет в Европейском регионе (RIPE) или Азиатско-Тихоокеанский сетевой информационный центр (APNIC).
Вам бы никогда не пришлось думать о том «Купит ли Google дополнительные IP-адреса» или «Мне нужно мониторить страницу поддержки GitHub, чтобы убедиться, что они не добавят их позднее». У вас бы был один блок, который компания бы использовала для всего бизнеса до конца его существования. Системам контейнеров не потребовалось бы присваивать внутренние IP-адреса каждому хосту, достаточно было бы выделять для них сегменты публичных IP, а также при необходимости делать оповещения через стандартные публичные DNS.
Я не утверждаю, что закрытые сети не нужны. Мой посыл заключается в том, что многие виды используемых нами сетевых структур основаны не на необходимости, а на навязанном дизайне. Подозреваю, что в ином случае мы бы начали разрабатывать приложения с пониманием того, что они работают через открытый интернет, а не стали бы опираться полностью на безопасность закрытых VPC. Учитывая, как работают эксплойты, это наверняка пошло бы на пользу дизайну и безопасности в целом.
Так что, даже если стоимость и доступность не являются для вас проблемой, то предоставление вашей организации более широкого права собственности и контроля над функционированием сети принесло бы ощутимую ценность.
Улучшится ли ситуация?
Так что пока всё печально. Вы либо платите облачным провайдерам больше денег, либо получаете полурабочий интернет. Надеюсь, что те, кто не хочет платить больше, продвинут идею использования IPv6. Считаю, что нам также должно быть стыдно за то, что потребовалось так много времени для осознания всего этого. Все проблемы можно было решать постепенно, но теперь этот процесс будет доводить людей до безумия, пока команды, управляющие такими ресурсами, не внесут необходимые изменения.
Надеюсь, что в конечном итоге ситуация всё же улучшится. Думаю, по меньшей мере, это должно открыть новые возможности для небольших компаний, стремящихся занять для себя IP-диапазон, которым они будут пользоваться неограниченное время. К тому же, наверняка с распространением IPv6 упростится и его использование. Но должен сказать, что сейчас эта технология находится в поразительно плачевном состоянии.
Если вы являетесь небольшой компанией, которая не желает платить лишние налоги на IP, уделите время на решение множества проблем, с которыми вам предстоит столкнуться.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️
Комментарии (176)
dreamer2
13.08.2023 10:47+46нам не хватает адресов - давайте придумаем протокол в котором выбросим по /64 на каждое устройство, всё равно никто не придумал что с ними делать...
-
nat навязан устаревшим старым протоколом - давайте вообще избавимся от закрытых сетей, ну а кому надо пусть сам придумывает, что будет фильтровать на границе.
Отличный и продуманный дизайн - впрочем все уже оценили по внедрению.
Nurked
13.08.2023 10:47+24По поводу первого - категорически несогласен. Как показывает практика, у современных инженеров очень сильно плохо всё с масштабами мышления. Идиотизмы, типа "тысяча адресов на человека будет достаточно" или "640 килобайт хватит всем" или "8 мегов рама - более чем", даже тот же самый UnixTime это полный бред из этой же категории.
Пусть будет /64 уж если что, будем по блоку на планету выдавать в будущем.
По поводу второго - возражений нет.
FSA
13.08.2023 10:47+39/64 вполне обосновывается тем, что имея 64 бита можно вписать в адрес любой существующий MAC адрес и гарантированно получить уникальный адрес ни с кем не пересекающийся. В контексте серверов, это позволит сократить размер адреса благодаря тому что вторая часть будет состоять из нулей. А если ещё учесть сеть /48, которую вы можете легко получить, то можно получить очень короткий адрес.
-
NAT - это костыль, который был придуман для того, чтобы в сеть могли выйти те узлы, которые его не имели. В IPv6 тоже есть NAT и если вы желаете, то можете его использовать. К тому же NAT64 практически делает незаметным отсутствие IPv4 на машине, но за редким исключением, когда IPv4 адреса жёстко вшиты в программу. Но и для этого найдётся свой костыль в виде NAT46, который нужно установить на само устройство или ваш маршрутизатор (который, кстати говоря, уже занимается NAT44). И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой задачи предназначен.
Основная проблема внедрения IPv6 - это нежелание людей разбираться в новом протоколе. Даже если провайдер вам его предоставляет, можно столкнуться с ситуацией, когда IPv6 перестаёт работать. Домашние провайдеры (например, Ростелеком) отказываются чинить баги ссылаясь на то, что они этот протокол не поддерживают, но по факту предоставляют, т.к. это позволяет снизить нагрузку на перегруженный провайдерский NAT. Все эти проблемы не вина протокола, но при этом, конечно, отпугивает новичков.
Уже сейчас можно перевести сеть на IPv6 и спокойно жить. А чтобы получить доступ к ресурсам IPv4 использовать уже знакомый костыль -NAT. Только в отличие от провайдерского NAT для IPv4, нагрузка на этот NAT будет падать по мере внедрения IPv6 и, в теории, вообще необходимость в нём отпадёт.
lexore
13.08.2023 10:47+12И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой задачи предназначен.
Вы это хотите сказать всем пользователям интернета?
LAZst
13.08.2023 10:47+8Это хочется сказать тем кто с пеной у рта доказывает что без NATа нет защиты...
А пользователям интернета пофигу чеге какой протокол отобразится их любимый вконтактик, хоть голубями пакеты пересылайте ))))))
lexore
13.08.2023 10:47+4Вы знаете, я не встречал тех, кто что-то доказывает про NAT. Но встречал тех, кто с пеной у рта доказывает (точнее высказывает), что NAT - это не фаервол. На деле, все домашние пользователи защищаются с помощью NAT.
Aelliari
13.08.2023 10:47На деле, все домашние пользователи защищаются с помощью NAT
Очень часто NAT является частью фаерволла (или наоборот??), и как правило во всей домашней и soho мелочи - фаерволл активен по умолчанию. И, домашние пользователи, мало того что ограничили связность через NAT, так ещё и закрыты кроме фаерволла на роутере, часто и фаерволлом isp
lexore
13.08.2023 10:47+2Фаервол - это инструмент, который применяет правила. Поэтому нужно смотреть не на фаервол, а на правила.
Например, NAT можно считать фаерволом со следующим функционалом:
закрыть все порты внутри сети;
при наличии исходящего соединения, открыть порт источника только для IP из соединения;
Что, в общем-то, уже очень неплохо защищает пользователей внутри сети. Включая NAT, человек гарантировано получает неплохую защиту.
Если человек полезет настраивать фаервол сам, такой гарантии уже нет. Тем более, что на разных железках правила и интерфейс фаервола может быть разным.
Можно сказать "Не смог настроить фаервол - ССЗБ". Но это очень странная логика. Сначала мы говорим человеку использовать фаервол, а потом потешаемся над ним, если он не смог его настроить.
slonopotamus
13.08.2023 10:47+1Не надо настраивать нткакие фаерволы. В том же самом домашнем роутере он уже есть и уже из коробки намтроен так чтобы снаружи никого не впускать.
lexore
13.08.2023 10:47+1В вашем роутере это может быть так. Но мы не можем так сказать про все модели роутеров. Некоторые провайдеры сейчас собирают свои модели роутеров со своими настройками. Мы не можем утверждать, что там все настроено верно. Зато там иногда находят дыры)
DreamingKitten
13.08.2023 10:47+2Домашние пользователи защищаются тем, что им вендор в прошивку роутера впихнул. И всех этих страшных слов как фаерволл и нат они не знают вообще, так что не надо выдавать это за осознанный выбор.
lexore
13.08.2023 10:47+1Никто и не выдает это за осознанный выбор. Наверное, стоило написать не "защищаются", а "защищены", чтобы было точнее. Вы же понимаете, что большинство домашних пользователей не будет настраивать фаервол. Так что хорошо, что у них есть NAT.
DreamingKitten
13.08.2023 10:47+1Так они и NAT не настраивают.
Потому что он по дефолту настроенный. Точно так же, как может быть по дефолту настроенный файрволл, для чего нужна лишь политическая воля вендора и ничего более.
lexore
13.08.2023 10:47Потому что он по дефолту настроенный.
Да. Хотя скорее он так работает без настройки.
нужна лишь политическая воля вендора и ничего более.
О, политическая воля - это очень дорогой ресурс) Они иногда даже явные дырки не закрывают. Поэтому, хорошо, что хоть NAT есть.
DreamingKitten
13.08.2023 10:47+8Да.
Потому что, если вы вдруг забыли, само слово "Интернет" обозначает связность каждый сети с каждой. И эту связность NAT ломает.
Megakazbek
13.08.2023 10:47+2"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось невостребованным и сейчас скорее представляет угрозу безопасности, чем то, к чему нужно стремиться. Нет смысла об этом даже вспоминать в мире, в котором интернет обозначает, что ты с телефона можешь заказать пиццу.
vikarti
13.08.2023 10:47+1Это очень полезное свойство. Хотя бы тем, что дает возможность убрать CGNAT который ресурсы сейчас жрет у многих провайдеров.
Ну и — мессенджерам и им подобным как бы совсем не хорошо через сервер ретранслироватся (что еще и сервер грузит) ну или надо не всегда рабочие схемы обхода NAT'а
DreamingKitten
13.08.2023 10:47+7"Связность каждый сети с каждой" - это бесполезное свойство,
Да ладно?
Если вы интернетом пользуетесь только для заказа пиццы, то не надо судить о других по себе.
Раз в пол-года на Хабре появляется очередная статья с нытьём о том как у IPv6 всё плохо и как он никому не нужен. Под каждой такой статьёй каждый раз разгорается один и тот же срач с одними и теми же аргументами.
Вот чтобы не повторяться, по поводу невостребованности
https://habr.com/ru/articles/711444/comments/#comment_25130512
encyclopedist
13.08.2023 10:47+9"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось невостребованным
Ага-ага, скажите это всем разработчикам, которым приходится изобретать NAT hole punching на свой лад, как только понадобится сделать что-то peer-to-peer.
Megakazbek
13.08.2023 10:47-2Дело в том, что эти приложения довольно нишевые и их проблемы особо никому не интересны, особенно учитывая то, что эти проблемы решаемые. Облегчение работы несущественного числа разработчиков - точно не драйвер перехода на IPv6.
MiraclePtr
13.08.2023 10:47"Довольно нишевые"??? Это онлайн-месседжеры то в наше время "нишевые приложения"? Мда...
Docke
13.08.2023 10:47Здравствуйте! Извините, что здесь спрашиваю...
Делал настройку по вашей статьте "Shadowsocks-2022 & XRay (XTLS) сервер с простой настройкой и приятным интерфейсом"
Всё завелось! Есть проблема с доступом к панели: попробовал сделать доступ с "виртуального" IP, вместо возни с сертификатами, как в 3 варианте ( раньше заходил так - http://IPсервака:порт/URL/).
Добавил в /etc/network/interfaces следующую запись:
iface lo:1 inet static
address 192.88.99.1
network 192.88.99.0
netmask 255.255.255.0
В настройках панели указал IP 192.88.99.1. Панель из вне - стала не доступно, как и ожидалось... .
Подключаюсь к сети через Shadowsocks (в NekoBox только его пока настроил) - инет есть, всё работает. IP сервера через whoer светится.
Вбиваю строку в браузере - http://192.88.99.1:порт/URL/ - Вообщем, в панель попасть теперь не могу. Что не так?
Спасибо за подсказку и сорри за глупые вопросы (только вникаю, в связи с известными событиями)!
Система Debian12 у меня.
lexore
13.08.2023 10:47Так это Интернет. Домашний роутер с публичным IP адресом - вполне себе часть этого интернета. А в квартире у человека Интранет. Там полная связность только внутри квартиры. А с Интернетом связность избирательная.
DreamingKitten
13.08.2023 10:47+3Вы путаете причину и следствие.
Border gateway как концепция одинаково хорошо работет и на основе NAT и на основе файрволла, первый вариант больше распространён исключительно и только из-за истощения адресов, у него никакого технологического преимущества нет, скорее даже наоборот.
lexore
13.08.2023 10:47У него есть преимущество в том, что он дает хорошую защиту из коробки. А фаервол еще надо настроить. Нет гарантии, что во всех домашних роутерах он хорошо настроен из коробки.
DreamingKitten
13.08.2023 10:47+1У него есть преимущество в том, что он дает хорошую защиту из коробки. А фаервол еще надо настроить.
Не понял, почему файрвол не может давать хорошую защиту из коробки? Какой такой волшебник настраивает NAT хорошо, но не может настроить файрволл так же хорошо?
Нет гарантии, что во всех домашних роутерах он хорошо настроен из коробки.
А есть гарантия, что во всех домашних роутерах NAT хорошо настроен из коробки?
lexore
13.08.2023 10:47+2С этим все просто. По счастливой случайности, NAT by design обладает свойствами хорошего фаервола:
Закрыть все компьютеры внутри сети от атакующих снаружи;
При наличии исходящего соединения, сделать динамическое разрешающее правило только для IP из этого соединения;
Получается система, которую не нужно настраивать. Нет настроек - нет проблем :-)
Фаервол можно настроить так же. Но нет гарантии, что фаервол в каждой железке и на каждом компьютере настроен таким образом. На деле всплывает проблема человеческого фактора. Во первых, фаервол из коробки где-то может и не иметь таких правил. Во вторых, его могут неправильно настроить. В итоге фаервол как бы есть, но не защищает.
На самом деле я не против фаерволов. И я не говорю, что все фаерволы нужно заменить с помощью NAT. Просто исторически получилось так, что NAT, кроме своей функции, еще и не дает атакующим добраться до компьютеров внутри. Для многих людей этого оказалось вполне достаточно в плане безопасности.
DreamingKitten
13.08.2023 10:47+1Вы занимаетесь абсолютно произвольными допущениями, не основанными ни на чём, кроме ваших же предпочтений и привычек.
На каждое ваше «нет гарантии, что...» я могу заявить, что а) нет и гарантии обратного, и б) нет гарантии, что предлагаемое вами решение не страдает теми же недостатками.
В целом же, мне представляется более логичным использовать инструментарий по назначению.
lexore
13.08.2023 10:47не основанными ни на чём, кроме ваших же предпочтений и привычек.
А вот это уже ваше допущение) Я основываюсь на своем опыте. И сейчас я поделюсь им с вами.
Возьмем роутеры от разных компаний и посмотрим на функционал их фаерволов.
Вот документация к роутеру D-Link DIR-X1860: link.
Со страницы 230 начинается описание веб интерфейса для управления фаерволом. Там много настроек, но все они позволяют создавать только статические правила. То есть, нет динамических правил, которые реализованы в NAT.Вот документация к роутеру D-Link DIR-842: link.
Со страницы 200 идет схожее описание управления фаерволом. Опять таки, они статические правила.Вот ссылка на страничку FAQ компании Asus, с описанием их фаервола: link.
Там много разных настроек, но они скорее про то, чтобы закрыть пользователю доступ куда-то снаружи.Справедливости ради, можно посмотреть на фаерволл в OpenWRT: link.
И вот там-то динамические правила можно настроить. Но просто потому, что тот фаервол - некая обертка над iptables, где все это есть.Поэтому, когда мне говорят про фаерволы в роутерах, мне это видится, как очень урезанная штука, сделанная для галочки.
А еще есть роутеры "от провайдера", которые провайдер ставит клиентам. И очень часто клиенты даже не имеют там доступа в веб интерфейс. Поэтому они даже имеющийся фаервол не могут использовать.
Поэтому, говоря "нет гарантии, что есть фаервол", я немного лукавлю. Скорее можно утверждать, что в большинстве случаев у людей нет нормального фаервола. Зато есть NAT. Поэтому, имеем то, что имеем)
slonopotamus
13.08.2023 10:47Прекратите распространять FUD. В том же самом роутере уже есть фаервол.
lexore
13.08.2023 10:47+2А вы посмотрите на правила этого фаервола. Роутеров много. Ручаться, что все они с хорошими правилами, нельзя. Там иногда явные дыры не закрывают.
Antra
13.08.2023 10:47+20Конечно же, NAT - это не средство безопасности. Но если из сотни серверов мне нужно сделать доступными из Интернета штук 5, я вовсе не хочу, чтобы любой мой внутренний IP (IPv6) маршрутизировался и был доступен извне, и условная MongoDB стала публично доступной из-за малюсенькой ошибки в правиле на фаерволе.
Даже имея сеть класса C мне в голову не придет каждому из сотни серверов выдать по публичному IP. Я либо кусочек сети с публичными адресами замаршрутизирую в DMZ, либо даже DMZ серверы сделаю доступными извне через NAT. И уж точно серверы, которые не должны быть доступными из Интернета, буду выходить в Инет через NAT, но ни в коем случае не быть на публичных маршрутизируемых адресах. А-ля NAT66 (хотя мне казалось,что он в очень незрелом состоянии).
Для меня идеально иметь внутри сети IPv6 и не думать об адресах, а "снаружи" - IPv4. И пусть фаервол имеет не только политику с правилами доступа, в которой можно случайно открыть огромную сеть, но и делает Static NAT из IPv4 в IPv6 только для "избранных".
Клиенты мобильных операторов (и ряд других кейсов), разумеется, отдельная песня.
VADemon
13.08.2023 10:47Если у вас во внутреннем контуре IPv6, то какой? И почему не site-local?
Antra
13.08.2023 10:47+7Я отвечал на "NAT - это костыль", пытаясь показать, что даже при использовании IPv6 всем серверам и устройствам выдавать публично маршрутизируемые адреса - не лучшая идея. NAT все равно не повредит, с ним безопаснее будет.
Если же использовать site-local - тем более без NAT не обойтись. И точно так же можно столкнуться с тем, что "купили компанию, надо объединять сети, а там совпадает адресное пространство".
Нет уж. Я бы регистрировал свой IPv6 блок, но использовал его внутри, в Интеренет не маршрутизировал, а наружу выпускал бы через NAT.
veryboringman
13.08.2023 10:47+1Нужно только помнить, что NAT - это не firewall. И он в любом случае нужен.
Высшее достижение NAT-строения - Carrier grade NAT у сотовиков. Врагу такого не пожелаешь.
Antra
13.08.2023 10:47+1Безусловно. Я вообще за эшелонированную защиту.
Интернет-фаервол - DMZ - Другой фаервол - бэкбон - ЦОД фаервол - серверные сегменты
Причем на Интернет фаерволе даже маршрутов в сторону "корпоративной сети" нет. Он только про DMZ сети знает.
Где бы и кто бы ни ошибся - внутренний сервер из ЦОД не окажется внезапно exposed.
veryboringman
13.08.2023 10:47Не совсем только понятно, почему в этой схеме не может быть ipv6?
NAT в ipv6 тоже есть, просто он гораздо проще реализуется, чем в ipv4 и менее глюкав из-за этого.
Antra
13.08.2023 10:47+2Конечно же может. Но не для того, чтобы избавиться от NAT.
И вы о каком NAT говорите? IPv6-to-IPv6 Network Prefix Translation (NPTv6) или NAT66?
veryboringman
13.08.2023 10:47+1В том числе и для избавления от NAT.
Я говорю про NPTv6 - потому что исчезает кривая схема с транслированием портов. Вот прямо сейчас ее и применяю.
nidalee
13.08.2023 10:47+5Я сам не сисадмин, но вроде как все файерволлы из коробки блокируют все, что не разрешено? Тот же ufw.
Если вы зачем-то разрешили in на порт mongodb, то это ССЗБ.
Не поставили файерволл — ну, в общем-то, тоже.
А у домохозяек он как бы из коробки. Если только знакомый-вредитель им не поставил говносборочку с вырезанным "ненужным" брандмауэром windows...
powerman
13.08.2023 10:47+3ufw - локальный на сервере. Там порт монги открыть придётся, иначе к ней никто из локалки не сможет подключиться. Вопрос в том, чтобы теперь на этот открытый порт никто из инета не пришёл - а это уже должно делаться не в ufw сервера монги, а на роутере. И настройка файрвола этого роутера с введением IPv6 заметно усложняется, т.е. растёт и вероятность ошибок. В результате в среднем защита в сетях IPv6 получается ниже. Не потому, что её невозможно сделать (почти) идентичной, а потому, что людям свойственно совершать ошибки и чем больше возможностей для ошибок система предоставляет тем больше ошибок будет совершаться - а IPv6 возможностей для ошибок предоставляет заметно больше.
nidalee
13.08.2023 10:47а это уже должно делаться не в ufw сервера монги
Но почему? Просто даете allow in со всех локальных адресов (можно подсетью) и дело с концом. Я так и сделал.Antra
13.08.2023 10:47+1Вообще для всех 192.168/172.16/10.0 разрешили? Ну чтобы не заморачиваться, когда новый филиал открывается. Не будете же вы при такого рода изменении в сети по десяткам серверов бегать и правила ufw менять.
Если то, что при таком подходе партнерские организации, контракторы всякие имеют к нему свободный доступ, не смущает, можно и ufw ограничиться.
powerman
13.08.2023 10:47+1Очевидно же почему: потому что не стоит прошивать инфу "какие адреса в нашей локалке" на каждом отдельном сервере, иначе при изменении архитектуры сети замучаемся это на каждом сервере исправлять. И уж тем более не стоит прошивать на сервере инфу "а кто имеет доступ к этому сервису" в виде списка конкретных адресов, по аналогичной причине.
Доступ можно контролировать либо на уровне подсетей (все сервера в подсети имеют доступ ко всем сервисам в этой подсети) либо на уровне логики авторизации конкретного сервиса либо на уровне файрвола между подсетями на роутере (для доступа между подсетями). Всё остальное создаёт слишком много сложностей в поддержке.
NAI
13.08.2023 10:47+2"Просто поверьте, у нас не всё так однозначно" (С) мем
Мой опыт и то с чем столкнулся. Провайдер выдает IPv6 - все ок. Микротом пробросилось, все счастливо работает. Местами даже блокировки обходятся.
Проблема 1 - статичный IPv6. С IPv4 понятно, вот мой DHCP-сервер, вот создал запись, вот я знаю что 88.10 - это телевизор. IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6 между мной и провом. И тут надо погружаться и становиться админом чтобы эт все настроить. Не погружался, но кажется микрот до сих пор так не умеет (если умеет нужна ссыль).
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы "обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса? Звучит как костыль, выглядит как костыль, ведет себя как костыль, значит перед нами костыль. (да, отключаемый, но збс - надеяться что ты выключишь ПК быстрее чем кто-нибудь сумеет воспользоваться какой-нибудь уязвимостью)
Проблема 2 - решение которой лично я не нашел. Windows firewall по дефолту блокирует не все. По этому если представить ситуацию что FW на роутере по умолчанию разрешает какие-то входящие, то можно получить сканером портов. А теперь думаете домохозяйки и прочие геймеры будут запариваться с FW на маршрутизаторе, FW на ПК? Сидеть и думать че-куда там пробросить надо? Да все жмакнут Allow, лишь бы запустилось и все.
Проблема 2.1 - Если проблему 1 маршрутизатор решить не может, то и публиковать внутренние ресурсы наружу становится невозможно. Т.к. надо будет или открывать доступ ко всем или после ребута можно получить смену IPv6 и тыкву вместо сервиса.
Проблема 3 (надуманная) - правила FW IPv4 я могу протестировать хоть с мобилки. А вот IPv6 нифига, кроме моего провайдера никто не дает. Как итог - настроил, работает, а вот чего открыто, как FW работает, не протестить. Надо идти в AWS (ну или любое другое облако) и брать инстанс с IPv6. Так каждый раз. =\
nidalee
13.08.2023 10:47по дефолту блокирует не все.
ЕМНИП, все что откровенно не нужно из коробки, там запрещено.то можно получить сканером портов.
Сканером портов ты в любом случае получишь, если есть разрешение на входящие подключения. Сам по себе он безвреден.
Ну вот открыт у меня (ныне пустующий) 27015, и что вы с ним сделаете?Сидеть и думать че-куда там пробросить надо? Да все жмакнут Allow, лишь бы запустилось и все.
Разве Windows Firewall делает запросы на входящие подключения? Вроде только при первом запуске, причем там по умолчанию стоит запрет для «общественных сетей», которыми по умолчанию являются все.NAI
13.08.2023 10:47+1Сам по себе он безвреден. Ну вот открыт у меня (ныне пустующий) 27015, и что вы с ним сделаете?
Ну вот веду я разработку чего-нибудь и в своем домашнем, ламповом окружении. Да еще и с каким-нибудь старым легаси софтом из 2008 года к которому патчи безопасности выпускались примерно никогда. За NAT'ом можно открыть все. C IPv6 вы не можете спокойно работать с БД и паролем pa$$word. Т.е. вместо быстрого прототипирования у вас появляется задача даже дома, даже для тестового стенда настрой нормальную безопасность (FW как минимум). Это не проблема если вы администратор, а если инженер-проектировщик? Да в таком случае вы даже про security-patch можете ничего не знать.
Разве Windows Firewall делает запросы на входящие подключения?
В нем есть пучек стандартных правил, во-вторых когда приложение просит дать доступ, оно как бы не пишет чего-кому-куда. Считается что дома оно вам не поможет т.к. вы пользователь, а в организации у вас есть политики и админы.
Бонусом, иногда проще отключить FW, чем потратить полдня на выяснение а что же софту надо ради 10 минутной работы.
czz
13.08.2023 10:47+2Проблема 1 - статичный IPv6. С IPv4 понятно, вот мой DHCP-сервер, вот создал запись, вот я знаю что 88.10 - это телевизор. IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6 между мной и провом.
У телевизора внутри сети есть link local address, который всегда одинаковый.
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы "обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса?
Не запрашивает, а генерирует случайным образом.
Permanent address всегда остается, и используется для входящих подключений.
Это не проблема, а фича, чтобы не раскрывать permanent address.
Проблема 2 - решение которой лично я не нашел. Windows firewall по дефолту блокирует не все. По этому если представить ситуацию что FW на роутере по умолчанию разрешает какие-то входящие, то можно получить сканером портов.
Чтобы получить сканером портов, нужно, чтобы злоумышленник знал ваш permanent address. Это не так чтобы невозможно, но хотя бы тупым сканом всего адресного пространства уже не обойтись.
Проблема 2.1
Она в том, что провайдер выдает каждый раз новый префикс? Конечно, чтобы открывать сервисы наружу, нужно заказать статический префикс. В IPv4 ведь также?
Проблема 3 (надуманная)
Это не проблема протокола :)
NAI
13.08.2023 10:47Это не проблема, а фича, чтобы не раскрывать permanent address.
...
Чтобы получить сканером портов, нужно, чтобы злоумышленник знал ваш permanent address.
Я не говорил что это проблема, я говорил о том что это выглядит как костыль =) причем весьма сомнительный, т.к. это поможет от снифферов, но если пользователь зайдет на сомнительный сайт, то как бы вот IP - скань\используй уязвимости\DDoS'ь. Да, до ребута. Но и этого может хватить.
Еще раз, не силен в IPv6, но где гарантия что в FW для temporary address что-нибудь не будет открыто? Ну т.е. in microsoft we trust?
У телевизора внутри сети есть link local address, который всегда одинаковый.
Тут вопрос скорее был про публикацию (разрешение на FW) одного ресурса из локальной сети - скажем SSH'а или http(s). Или наоборот полный запрет на выход в интернет устройству.
Она в том, что провайдер выдает каждый раз новый префикс?
Не, префикс выдается один и тот же. Но у меня каждый раз устройства получают новые IPv6, т.е. я не могу прописать allow IPv6:80
Это не проблема протокола :)
Не проблема протокола, но проблема отладки, что не добавляет привлекательности
czz
13.08.2023 10:47Еще раз, не силен в IPv6, но где гарантия что в FW для temporary address что-нибудь не будет открыто? Ну т.е. in microsoft we trust?
Я согласен, что на windows firewall не стоит полагаться, но в норме у вас на роутере стоит запрет на forward из WAN в LAN, кроме отдельных явным образом открытых портов.
Насчет микротиков не помню, там возможно по умолчанию нет вообще никаких правил файрвола для IPv6. Но микротик все-таки предполагает, что пользователь немного админ :)
Тут вопрос скорее был про публикацию (разрешение на FW) одного ресурса из локальной сети - скажем SSH'а или http(s). Или наоборот полный запрет на выход в интернет устройству.
Если у вас префикс выдается один и тот же, то и перманентные IP-адреса устройства получают по SLAAC одни и те же, вычисленные по их MAC-адресам. Они не должны каждый раз получать новые IP.
NAI
13.08.2023 10:47Они не должны каждый раз получать новые IP.
Да, но по факту нет =)
Windows
Пример с Win10, мак - C8-5B-76-E6-B1-9C
Ну и в целом смотрите картинку, там по МАКу выдан только 1 IPv6
Ethernet adapter vEthernet (LAN):
Connection-specific DNS Suffix . : *owl.ru
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
Physical Address. . . . . . . . . : C8-5B-76-E6-B1-9C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : ****:****:****:****:8b21:b090:bed4:b6b2(Preferred)
Temporary IPv6 Address. . . . . . : ****:****:****:****:c82:8706:1b6f:cf2b(Preferred)
Link-local IPv6 Address . . . . . : fe80::b64c:ad:bf05:b58a%23(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.88.112(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 14 августа 2023 г. 22:47:56
Lease Expires . . . . . . . . . . : 16 августа 2023 г. 22:57:56
Default Gateway . . . . . . . . . : fe80::66d1:54ff:fe68:53ee%23
192.168.88.1
DHCP Server . . . . . . . . . . . : 192.168.88.1
DHCPv6 IAID . . . . . . . . . . . : 1254644598
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2A-D4-0A-CB-C8-5B-76-E6-B1-9C
DNS Servers . . . . . . . . . . . : 192.168.88.1
Primary WINS Server . . . . . . . : 192.168.88.1
NetBIOS over Tcpip. . . . . . . . : Enabledczz
13.08.2023 10:47+2Вы говорите в категориях DHCP, где адреса "выдают". При использовании SLAAC их не выдают, а устройство, зная префикс /64, само их генерирует на свое усмотрение в любом количестве.
Один из адресов всегда генерируется детерминированными образом, и остается одинаковый. По нему вы открываете файрвол для входящих соединений.
Остальные случайные, используются для исходящих содинений.
Есть два способа генерации детерминированного адреса:
EUI64, по мак-адресу (RFC 4291). Телевизор, скорее всего, воспользуется этим способом. В linux-системах этот метод обычно стоит по умолчанию, и он удобнее, если у вас в сети сервер, который вы хотите вывести наружу.
Stable privacy (RFC 7217) — как хэш от стабильных параметров системы. Вот этот адрес, :8b21:b090:bed4:b6b2, он должен быть детерминированным, но поменяется при переустановке системы, а также зависит от префикса сети и используемого сетевого интерфейса. В винде и MacOS по умолчанию такой метод. Не исключаю, что в hyper-v он работает не совсем так, как надо. Если нужно больше предсказуемости, то это можно отключить (google: windows disable stable privacy.
P.S. Создание временных адресов тоже можно отключить, если не нравятся.
DreamingKitten
13.08.2023 10:47IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6 между мной и провом. И тут надо погружаться и становиться админом чтобы эт все настроить. Не погружался, но кажется микрот до сих пор так не умеет (если умеет нужна ссыль).
Не надо ничего вкорячивать. Грамотные реализации slaac такие как radvd, умеют выдавать статические адреса, если настроить.
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы "обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса? Звучит как костыль, выглядит как костыль, ведет себя как костыль, значит перед нами костыль.
Это не костыль, это фича.
Причём фича, предписанная стандартом — RFC 4941
Предназначена она да, для приватности — чтобы не палить кому не попадя основной адрес, исходящие коннекты делаются с временного.
Проблема 2.1 - Если проблему 1 маршрутизатор решить не может, то и публиковать внутренние ресурсы наружу становится невозможно. Т.к. надо будет или открывать доступ ко всем или после ребута можно получить смену IPv6 и тыкву вместо сервиса.
Может. Но если бы и не мог, то в v4 всё то же самое.
NAI
13.08.2023 10:47Грамотные реализации slaac такие как radvd, умеют выдавать статические адреса, если настроить.
И как это вкорячивать в IoT, windows и synology (для примера)?
DreamingKitten
13.08.2023 10:47Это вкорячивается со стороны роутера, а не клиентов.
https://wiki.mikrotik.com/wiki/Manual:IPv6/ND
Windows и Synology умеют в Ipv6 из коробки.
ValdikSS
13.08.2023 10:47+1И уж точно серверы, которые не должны быть доступными из Интернета, буду
выходить в Инет через NAT, но ни в коем случае не быть на публичных
маршрутизируемых адресах.Почему? В чём преимущество использования NAT для этого сценария, по сравнению с обычным firewall с блокировкой входящих соединений?
Antra
13.08.2023 10:47В человеческом факторе.
Что нужно, чтобы открыть доступ к серверу на публичном адресе? Чуток поменять правила. Они же не статичные. Не тот хост добавил в разрешенные.. Хотел дать доступ только из ЛВС, а сдуру открыл из Интернета... Не то drop правило удалил или просто перетащил выше этого блокирующего... Сетку с разрешениями указал /28 вместо /29... Когда в политике сотни правил такое легко может случиться. Я уж молчу про "случайную ошибку маршрутизации в обход фаервола", особенно при наличии всяких резервных каналов.
А вот если действительно хочешь опубликовать ресурс с приватного адреса в Инете, надо дополнительно к фаервольским правилам еще явным образом Static NAT сделать. Причем выбрать не задействованный под другие серверы. Это уже напрячься надо, не просто "рука дрогнула".
Повторюсь, NAT сам по себе - не средство безопасности. Как и маршруты, VLAN и многое другое. Можно обойтись и без него. Но он дополнительно уменьшает риски в случае человеческой ошибки. С ним нужно больше ошибок совершить для бадабумса (хотя это отнюдь не значит, что с NAT вы в полной безопасности).
slonopotamus
13.08.2023 10:47Случайно залезли в роутер и случайно открыли доступ снаружи к внутреннему девайсу? Не несите бред.
Antra
13.08.2023 10:47Давайте быть последовательными. Степень распространения IPv6 определяется отнюдь не домашними пользователями, действующими по принципу "включил и забыл", а компаниями. Поэтому я рассматриваю кейсы применения IPv6 именно в организациях.
"Настрою-ка я у себя дома IPv6, чтобы сделать холодильник доступным из Интертнета" - с такими кейсами не ко мне.
Heggi
13.08.2023 10:47Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Имею 2 4to6 туннеля, один в рф, другой не в рф. Хочу, чтобы сайты из рф ходили через туннель в рф, остальные через второй.
Без NAT имею, что каждый девайс в сети имеет по два IPv6 адреса и с какого source IP пойдет запрос - вообще не угадать. И через какой туннель уйдет запрос - тоже не угадать (а туннели вредные, если пакет идет не с их source IP, то пакет дропается).
С NAT это решилось бы легко и просто маршрутами на роутере. Как решить это без NAT - идей никаких.
upd: для конторы со своей AS все решается с помощью BGP. Для дома BGP не вариант.
Sap_ru
13.08.2023 10:47+2"и с какого source IP пойдет запрос - вообще не угадать", но это вы просто не умеете его готовить. В системе тоже есть маршрутизация для source interface. В Linux через route tables.
Heggi
13.08.2023 10:47Но настраивать маршрутизацию на каждом телефоне-телевизоре тоже не дело. Такое должно на роутере настраиваться.
vikarti
13.08.2023 10:47Есть. Но вот только как быть в ситуациях когда устройство есть. Даже может быть с Linux. Но вот консоли нет (кроме разве что отладочного UART внутри корпуса). Подразумевается автонастройка приложением умного дома. Не опенсорсным конечно же.
FSA
13.08.2023 10:47+2Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Да кто ж вам NAT запрещает то? Я бы, пожалуй, вашу задачу тоже бы с ходу решил через NAT. На устройствах пользователей основной IPv6 от провайдера. А на шлюзе маршрутизация нужных адресов в нужный туннель, на конце которого NAT с его собственной адресацией. При чём транслировать можно адреса 1:1, а значит даже состояние не нужно запоминать для соединений.
NAT плох там, где его рассматривают как средство обеспечения защиты сети, хотя он им не является. К тому же, повсеместное применение его приводит к неявному отказу от главного принципа Internet: сквозной прозрачности на сетевом уровне [RFC 2775], когда любой хост А может послать пакет IP любому хосту Б (где А может быть равно Б). В вашем варианте, кстати, сквозная прозрачность нарушена, так что почему бы в этом случае не использовать NAT как средство обхода проблемы.
vikarti
13.08.2023 10:47+3Запрещают те кто активно устроили пропаганду, что NAT в любой форме на IPv6 не нужен. И поддержка в софте — не нужна. Из-за чего та поддержка совсем не сразу появляется.
То, что есть товарищи у которых NAT это замена firewall — это отдельная проблема.
Pochemuk
13.08.2023 10:47Вы в самом деле думаете, что все MAC-адреса уникальны?
У меня как-то был в локалке компьютер, у которого MAC-адрес совпадал с MAC-адресом сетевого принтера. Было весело.
Как-то поставили нам несколько терминалов для бесконтактных пропусков. У двух из них были одинаковые MAC-адреса. Убил 5 часов на поиск плавающей нестабильности их функционирования. Думал, что я сошел с ума. Они как бы работали, но не всегда.
buldo
13.08.2023 10:47-1Как админ локалхоста могу сказать , что "нежелание людей разбираться" вполне объяснимо.
Разрыв сложности между привычным ipv4, который просто как два пальца и его понимают даже не специалисты и ipv6 - просто огромен. Новые концепции, куча режимов, магия. Сколько раз пытался осилить ipv6, так и не смог.
ValdikSS
13.08.2023 10:47+3Базовые концепции маршрутизации ровно такие же. Если вы считаете IPv4 «простым как два пальца», то вы, вероятно, мыслите в концепциях типичной конфигурации вашего роутера не дальше вашей квартиры.
DreamingKitten
13.08.2023 10:47На самом деле IPv6 проще, а "разрыв сложности" это просто привычка как следствие возраста протокола.
GennPen
13.08.2023 10:47+2На сколько помнится, по стандарту /64 дается на подсеть. А там уже либо DHCPv6 с выдачей рандомных/последовательных адресов как в DHCPv4, либо SLAAC.
IPv6 это отличная замена, и уже почти полностью рабочая. Однажды я что-то тестировал на компьютере, отключил IPv4 и забыл про это, а потом несколько дней сидел не замечая. Только после того как заметил что некоторые редкие сайты перестали открываться вспомнил.
FSA
13.08.2023 10:47+7некоторые редкие сайты перестали открываться
Ну не такие уж и редкие. В России большинство сайтов не имеет IPv6. Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса! Но если у вас был доступен DNS64+NAT64, то вы вполне могли не заметить отсутствие IPv4 на вашей машине. Знаю только одно приложение, которое не умеет в IPv6 сеть - это Steam. Видимо у него внутри вшиты IP адреса серверов. Но и это лечится путём запуска NAT46 непосредственно на вашей машине.
А вообще слышал, что Европейские провайдеры уже строят свои сети только на основе IPv6. Но ведь клиенты будут недовольны, что у них доступа нет? А вот и нет. Используется технология MAP-T. При этом сеть провайдера полностью построена на IPv6. Весь пул адресов они выделяют для NAT64. Один IPv4 адрес они делят между несколькими абонентами. Каждому выделяется определённое количество портов. При чём связь используется статичная, т.е. не нужно сохранять даже состояния соединений. На клиентской же стороне маршрутизатор по классике даёт какую-то серую сеть, типа 192.168.1.0/24 или аналогичную. А все соединения с серверами IPv4 направляются не на обычный NAT, а NAT46, который использует только строго выделенный диапазон портов, который согласован с набором на NAT64 у провайдера. Т.е. схема получается почти аналогичная тому, что есть сейчас с IPv4, только трафик между маршрутизатором клиента и NAT провайдера теперь идёт по IPv6. К тому же теперь провайдерскому NAT не нужно следить за состоянием соединений, т.е. он становится менее требователен к железу. Нагрузка на этот NAT будет постепенно снижаться ввиду того, что больше ресурсов будет доступно по IPv6 напрямую.
VADemon
13.08.2023 10:47Про провайдеров верно, туннель на IPv6.
Мне интересно, что творится, когда размер IPv4 пакета проходит около MTU сети? IPv4 MTU искусственно занижен или пакеты фрагментируются на стороне провайдера?
DreamingKitten
13.08.2023 10:47Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса!
У hsto.org есть.
Но это, судя по всему, какой-то побочный эффект а не сознательное внедрение.
ultraElephant
13.08.2023 10:47+6Проблема открытости/закрытости внутренней сети высосана из пальца. Какая разница будет ли на пограничном устройстве nat или `ip deny any any` на вход?
M_AJ
13.08.2023 10:47давайте вообще избавимся от закрытых сетей, ну а кому надо пусть сам придумывает, что будет фильтровать на границе.
Вот каждый раз меня это тригеррит. NAT -- это не замена фаерволу.
dreamer2
13.08.2023 10:47а с чего столько людей стриггерилось на нат если речь про четко описанный в статье посыл "я не утверждаю что закрытые сети не нужны совсем, но это навязанный дизайн и на самом деле они вам не нужны" ?
при этом нат это конечно не фильтр, но средство изоляции сетей, что не однократно тут же в комментариях подтверждается
M_AJ
13.08.2023 10:47при этом нат это конечно не фильтр, но средство изоляции сетей
Потому что NAT это не средство изоляции сетей. Для изоляции как раз и придуман фаервол, и нормальный дизайн сети как раз предусматривает настроенный нормально закрытый фаерволл, а NAT, как следует из его названия, это механизм трансляции адресов.
dreamer2
13.08.2023 10:47можно сколько угодно триггериться от того что кто-то забивает шурупы молотком, но это не изменит существующей реальности
точно так же как и те кто признают, что нат мешает связности и придумывают средства пробивки нат почему-то думают, что фаерволы у юзер роутеров в дефолтных конфигах разрешат подключаться их в6<->-в6 приложухам без проблем
судя по темпам внедрения многие из нас этого всё равно не застанут :D
DreamingKitten
13.08.2023 10:47почему-то думают, что фаерволы у юзер роутеров в дефолтных конфигах разрешат подключаться их в6<->-в6 приложухам без проблем
В v4 эта проблема уже решена включением на роутере IGD/UPNP. Не вижу принципиальных проблем добавить в него поддержку IPv6, тем более что на бэкенде это будет проще.
theurus
13.08.2023 10:47+3ждем дальше. когда все провайдеры переползут тогда и нам можно будет
DreamingKitten
13.08.2023 10:47Никто не будет переползать (вкладываться в обучение и в настройку) пока это не будет массово продаваться, увы. IPv6 не является selling point'ом даже для многих IT-шников.
Nurked
13.08.2023 10:47+6Ну, на самом деле не всё так плохо. Внутренние сети поднимать на ipv6 - одно удовольствие. Получить адрес в ARIN? Занимает один день. У вас свой блок на пару ***-ардов адресов. Пожалуйста, по ссылке. https://www.arin.net/resources/guide/ipv6/first_request/
Сделаться провайдером? Не проблема.
Майкрософт не шелохнулись, чтобы ввести IPv6 на своих сетях? Оханьки и ухоньки. Естественно. И фиг с ними.
Обновления дебиана? Отлично обновлялся.
Настройки оборудования и маршрутов - одно удоволсьвие. Там, конечно не без приколов, но работает.
Я разрабатывал сеть для VDS провайдера. Для клиентов в конце концов на внутренних хостах поставили нат наружу для их же обратной совместимости. Но это тем, кому надо было. Сама система - вся на IPv6.
Ничего, переживём.
Astroscope
13.08.2023 10:47+21Протокол IPv6 не поддерживается ни моим домашним провайдером, ни рабочим.
Это, надо полагать, типичная ситуация вообще в мире, а не только локально у автора. Почему провайдеры не поддерживают IPv6? Потому что это не нужно клиентам - единичные энтузиасты не в счет, а поддержка стоит не только человекочасов, но и может потребовать аппаратного апгрейда. И ради чего, если у всех и так все работает? Дефицит белых адресов? Да неважно, будет больше слоев NAT.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки. Сказать по правде, я не уверен, что бытовой роутер с еще одним NAT это хуже, чем если все эти умные (умные, серьезно?) чайники и умные утюги будут смотреть наружу напрямую - с их-то пресловутой склонностью вступать в ряды ботнетов или по мере своих скромных вычислительных возможностей что-то там майнить, ведь пусть один чайник много не намайнит, но миллионы впараллель это же уже вполне себе сила.
Дефицит адресов объективен. Все остальное оказалось никому не нужно. Пора пилить IPv7, который будет полностью повторять известный IPv4 с единственным расширением - с еще одним, двумя, или сколько там решат достаточным октетами для описания пространства адресов и полной, насколько это возможно, совместимостью с IPv4, чтобы имеющееся оборудование продолжило работать без изменений ближайшие хотя бы лет двадцать, а новое просто имело больше возможностей. Чтобы у кого есть поддержка могли использовать новые диапазоны адресов вместе со старыми напрямую, а у кого нет - работали только со старым диапазоном, а новые - только через NAT.
Nurked
13.08.2023 10:47+5Это зависит от страны. Equinix поддерживает IPv6 во всех своих зонах. Кстати, погуглите кто это такой.
А в Лос-Анджелесе местные провайдеры уже давно прокидывают IPv6 с настроеным сверху натом для IPv4 трансляций.
slonopotamus
13.08.2023 10:47+8Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки
В этом же самом бытовом роутере есть бытовой фаерволл, который включением одной галочки (причём включенной по умолчанию) прекрасно защищает все ваши чайники и утюги.
checkpoint
13.08.2023 10:47+7Полностью согласен на счет необходимости переходить на IPv7/IPv8, а IPv6 следует похоронить как можно скорее.
IPv6 - это явный пример overengineering-а - вместо того, что бы банально увеличить битность адреса, создатели IPv6 попытались впиндюрить в протокол кучу всякого бесполезного г@вна и полностью изменили идеологию использования адресного пространства. Фактически создатели IPv6 предлагают нам совершенно новый Интернет. Я абсолютно уерен, что все эти потуги тщетны и IPv6 не взлетит никогда!
И еще. 128 бит на адрес это оверкилл, такие адреса совершенно невозможно запоминать и администрировать. 64 бита для IP адреса более чем достаточно на ближайшую тысячу лет.
Aelliari
13.08.2023 10:47+5Имхо ipv6 вышел довольно стройным, и да, это совершенно новый интернет, но оно выглядит лучше чем добавление «октетов» в ipv4.
P.S. А нафига запоминать 128 бит адреса? Тебе нужно оперировать префиксами. Да и раздавая /64 на оконечное устройство - ты уже получишь упомянутое тобой 64 бита адреса. Кстати, вручную сконфигурированный адрес - может быть и легко запоминаемым, для примера - :face:b00c, ::8888. это куски без префикса
Semy
13.08.2023 10:47+3Про запоминание слышать странно. Как правило, у вас единственный префикс на всю организацию (который достаточно быстро запоминается), вместо нескольких сетей IPv4 с разными масками. Мне стало даже легче ориентироваться. SLAAC вам точно запоминать не придется, а шлюзы, DNS и пр. имеют простые адреса. Некоторые админы даже придумывают некоторые осмысленные имена, которые можно запихнуть в IPv6 типа face, dead beef и.т.д.
MiraclePtr
13.08.2023 10:47+5Некоторые админы даже придумывают некоторые осмысленные имена, которые можно запихнуть в IPv6 типа face, dead beef и.т.д.
bad:b1g:b00b:babe:aged::18
Aelliari
13.08.2023 10:47+3чайники и умные утюги будут смотреть наружу напрямую
А зачем им смотреть наружу? Им можно раздать только Link-local...
FSA
13.08.2023 10:47+19Пора пилить IPv7
Вы явно недооцениваете инженеров, которые проектировали IPv6.
Цитата из книги «IPv6 для знатоков IPv4», Ярослав Тихий, 31 декабря 2013 г.:
Попробуем для начала консервативный подход. Можно ли расширить адрес IP, не отказываясь от протокола IPv4 и, в частности, от его формата заголовка? Например, мы могли бы поместить новые, расширенные адреса в специальные опции IPv4. ARP справился бы с новыми адресами, так как длина адреса в нем явно указывается. С ICMP ситуация сложнее, так как некоторые типы сообщений ICMP включают в себя адреса IPv4. Наконец, фиксированное смещение адресов от начала заголовка облегчает быструю аппаратную маршрутизацию пакетов, тогда как размещение адресов в опциях значительно усложнило бы ее. Ну, и вообще говоря, опции потому так и называются, что они должны быть факультативными, то есть необязательными для исполнения. Это окончательный аргумент против того, чтобы новые адреса находились в опциях IPv4. В то же время, основной заголовок IPv4 рассчитан только на 32‑битные адреса. Вывод такой, что текущим форматом заголовка IPv4 нам все-таки придется пожертвовать, поскольку в нем нет места для новых адресов.
Теперь, когда мы готовы распрощаться с заголовком IPv4, у нас возникает противоположное искушение: не просто расширить адреса, а радикально переделать протокол IP, чтобы исправить в нем существующие недостатки и добавить новые возможности.
Там есть ответы на большинство вопросов, которые тут задают в комментариях. И почему именно 128 бит, и почему 64 бита на сеть, и почему IPv6 не совместим с протоколом IPv4, и даже почему именно так щедро в настоящее время распределяются адреса IPv6.
Не стоит недооценивать протокол IPv6. Кроме того, что его достаточно хорошо проработали и сделали таким каким он сейчас, учитывайте, что практически всё современное железо так или иначе может работать с этим протоколом. Да, потребности массовой пока нет, поэтому возможности железа ограничены. Но как только критическая масса наберётся и производители софта для железа увидят потребность, они наклепают вам всех необходимых возможностей, которые вам нужны и не нужны. С IPv4 также было. Софт в старых маршрутизаторах тоже был ограничен. Но когда маршрутизаторы стали требоваться почти всем, они обросли разухабистыми веб интерфейсами, где можно настроить кучу всего.
Сам протокол IPv6 по своей природе меньше грузит промежуточные узлы. Маршрутизаторам проще обрабатывать эти пакеты. Если вам нужно фильтровать пакеты, то нужно опять таки запоминать состояние. Но этого требует и NAT. Но при этом нам не нужно переписывать заголовки пакетов, а значит наш маршрутизатор будет меньше загружен при тех же самых возможностях, что есть в IPv4.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки.
Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме тех, что нужны для получения ответов. Получается та же схема, что и при работе NAT, только без NAT. Снаружи до вас не достучаться, но если вы откроете путь для себя изнутри, то пакеты до вас будут ходить. Вашему маршрутизатору не нужно хранить таблицу NAT (но при этом нужно всё так же хранить какие порты у вас активны) и модифицировать каждый пакет, который через него проходит. А уровень защиты получается на том же уровне.
DaemonGloom
13.08.2023 10:47+1Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме тех, что нужны для получения ответов.
Увы, ipv6 требует для работы разрешения ICMP пакетов входящих на узлы в вашей сети. Так что полной изоляции всё равно не получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке ICMP. Более того — когда-то такая точно найдётся. И защититься от неё вы уже не сможете.
FSA
13.08.2023 10:47+2Воспользуюсь вашим методом. А вы знаете, что в IPv4 используется ARP? Если ваше устройство не отвечает на ARP запросы, то оно не сможет работать, т.е. полной изоляции не получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке ARP. Так что срочно нужно отказаться от IPv4!
А если серьёзно, то никто не заставляет вас все ICMP направлять напрямую без какой-либо фильтрации на вашем брандмауэре. И есть вполне конкретные решения для защиты сети. Они другие, не такие как в IPv4. Но и протокол у нас другой, который учитывает ошибки в старом протоколе.DaemonGloom
13.08.2023 10:47+4И давно требуется отвечать на arp запросы от кого попало наружу из внутреннего периметра?
Все — никто не требует. Но конкретные виды ICMP сообщений направлять напрямую необходимо для работы протокола согласно https://www.rfc-editor.org/rfc/rfc4890. И что-то я пока не вижу IPS/IDS в распространённых домашних роутерах, чтобы пытаться блокировать запросы к известным уязвимостям.
Semy
13.08.2023 10:47Справедливости ради, ICMPv4 тоже не рекомендуется закрывать полностью.
powerman
13.08.2023 10:47+1Справедливости ради, ICMPv4 в локалку не требуется открывать из внешнего инета. Так что этот аргумент мимо.
Факт в том, что IPv6 требует более сложных настроек файрвола (которые мало кто умеет делать пока и которые вряд ли адекватно "из коробки" сделаны на всех домашних роутерах) и требует больше пропускать из инета в локалку - т.е. уровень защищённости локалки при использовании IPv6 падает.
slonopotamus
13.08.2023 10:47Факт в том, что IPv6 требует более сложных настроек файрвола
Одна галочка в роутере (которая и так прожата по дефолту - "не пущать коннекты снаружи". Абсолютно столько же телодвижений, как и при IPv4 NAT.
powerman
13.08.2023 10:47Телодвижений-то столько же, а вот качество результата несколько отличается, и не в сторону большей безопасности.
DreamingKitten
13.08.2023 10:47В каких попугаях вы измеряете «качество результата» ?
powerman
13.08.2023 10:47+1В количестве открытых векторов атак (пропускаемых пакетов, в данном случае). И в размере вероятности, что галочка настроит не настолько правильно, как можно/нужно было (в связи с увеличением сложности настройки, меньшим накопленным опытом как настраивать правильно, меньшим объёмом тестирования/обратной связи от взломов).
DreamingKitten
13.08.2023 10:47А как вы посчитали количество открытых векторов атак, размер вероятности и сложность настройки? Были какие-то эксперименты, контрольные группы, экспертные оценки или просто с потолка, "потому что мне так кажется" ?
powerman
13.08.2023 10:47+2А Вы в теоретические знания не верите, всё нужно проверять на практике? Документации про IPv6 более чем достаточно, и если её почитать, даже поверхностно, становится очевидно, что IPv6 больше и заметно сложнее и что он требует пропускать из инета в локалку часть трафика, который в IPv4 пропускать не требовалось (часть ICMP). Из этого вполне однозначно следует и то, что количество векторов атак увеличивается, и то, что корректно настроить файрвол для IPv6 будет сложнее (а, значит, в его настройке тоже будет совершаться больше ошибок). Ну и там других, менее очевидных, новых угроз хватает - напр. если использовать MAC для младших 64 бит адреса то это может создать новый способ утечки приватности, когда перемещение вашего устройства (ноута, например) между разными сетями IPv6 (дом/работа, например) смогут отслеживать даже вебсайты в интернете.
DreamingKitten
13.08.2023 10:47+1Главным образом я не верю в оценочные суждения, исходящие от предвзятых неосиляторов-теоретиков, которые вбили себе в голову, что «IPv6 это сложнаааа» и наворачивают вокруг этого тезиса целую мифологию о тысячах виртуальных уязвимостей в ICMPv6.
смогут отслеживать даже вебсайты в интернете
Не смогут, RFC 4941 вам в помощь.
powerman
13.08.2023 10:47+1Не смогут, RFC 4941 вам в помощь.
В помощь оно только тем, кто позаботится ручками явно включить его на конкретном интерфейсе. Потому что по умолчанию в линухе оно выключено (
networking/ip-sysctl.rst):use_tempaddr - INTEGER Preference for Privacy Extensions (RFC3041). * <= 0 : disable Privacy Extensions * == 1 : enable Privacy Extensions, but prefer public addresses over temporary addresses. * > 1 : enable Privacy Extensions and prefer temporary addresses over public addresses. Default: * 0 (for most devices) * -1 (for point-to-point devices and loopback devices)Кроме того, честно скажу в подробности я поленился вникнуть, но сходу попалась статья с цитатой:
The temporary addresses standardized in RFC 4941 were originally meant to mitigate some of the security and privacy issues discussed in this tip. However, we will see that they fail to mitigate a number of potential problems, while at the same time introducing additional complexity.
И такая ситуация вполне типична для самых разных аспектов IPv6 - это и есть как раз следствие его переусложнённости.
powerman
13.08.2023 10:47+1Не поленился прочитать ту статью. Автор, описав недостатки RFC 4941, предложил их решение в виде RFC 7217 (и оно реально выглядит уже значительно лучше, как на мой взгляд). К сожалению, в плане настроек по умолчанию ситуация не изменилась - оно выключено:
addr_gen_mode - INTEGER Defines how link-local and autoconf addresses are generated. = ================================================================= 0 generate address based on EUI64 (default) 1 do no generate a link-local address, use EUI64 for addresses generated from autoconf 2 generate stable privacy addresses, using the secret from stable_secret (RFC7217) 3 generate stable privacy addresses, using a random secret if unset = =================================================================
Aelliari
13.08.2023 10:47Так, стоп, при выключенном фаерволе, но активном NAT разве «сосед» не может на своей машине прописать маршрут для трафика на своей машине указав nexhop-ом ваш роутер, и спокойно гнать трафик в вашу сеть?
P.S. Кроме случая overload NAT/port adress translation, там, по идее сломается. Но это частный случай NAT
andreymal
13.08.2023 10:47+1Может, я экспериментировал с кинетиками, прокатывало. Поэтому меня очень печалят комментаторы, приписывающие NAT'у «свойства хорошего фаервола»
powerman
13.08.2023 10:47+2Лично я NAT файрволом не считаю, ни плохим ни хорошим. Но ещё я не считаю хорошей идеей выставлять все устройства из локалки в инет, ни полностью ни частично (от приёма ICMPv6 из инета и до публикации наружу количества устройств в локалке и их MAC-адресов).
Опять же. NAT есть и в IPv6. MAC использовать для младших 64 бит адреса тоже никто не заставляет. Это не вопрос того, что в IPv6 чего-то сделать нельзя. Это вопрос того, что настройка "по умолчанию из коробки" в случае IPv6 практически гарантированно окажется менее безопасной во-первых, и, из-за большей сложности IPv6, сделать её хотя бы идентично безопасной будет намного сложнее (и в процессе настройки будет допускаться много ошибок - сложность есть сложность, а людям свойственно ошибаться), и в-третьих из-за меньшей отлаженности IPv6 будет дополнительная кучка багов/уязвимостей в самой реализации сетевого стека для IPv6 в разных ОС/устройствах.
Иными словами, по факту, в первые годы массового перехода на IPv6 безопасность заметно упадёт у большинства. При этом именно массовый переход ещё даже не начался. А сейчас безопасность падает только у тех энтузиастов, которые уже сейчас пытаются использовать IPv6, не уделив при этом на порядок больше (чем требовалось для IPv4) времени и внимания вопросам безопасной настройки.
powerman
13.08.2023 10:47+2Не совсем. Из соседней локалки - сможет. Из инета - нет, потому что адреса локальных сетей в инете не роутятся (разве что конкретно ваш провайдер, при сильном желании забраться к вам в локалку - сможет). Но угроза, всё-таки, обычно либо из инета исходит, либо (в офисе, например) из собственной локалки, варианты когда это именно соседняя локалка встречаются реже, плюс в ситуациях когда рядом несколько локалок это обычно означает большое число клиентов (крупный офис, к примеру) и к ним обычно прилагается хоть какой-то живой админ, с квалификацией повыше домашнего пользователя.
titbit
13.08.2023 10:47+3В качестве прогноза, могу предположить, что полный переход с IPv4 не состоится никогда, скорее интернет распадется на сегменты, которые могут быть ограниченно связанные, при этом могут использоваться разные протоколы и будут всякие шлюзы то работающие, то нет. И это может стать реальной технической "катастрофой" кстати, потому что связанность сильно пострадает.
jershell
13.08.2023 10:47+15Native: 43.02% 6to4/Teredo: 0.00% Total IPv6: 43.02%
https://www.google.com/intl/en/ipv6/statistics.html
Не так уж и плохо, по 5% в год переползаем потихоньку.И даже +20% за последние три года вроде как.
aborouhin
13.08.2023 10:47Если там же посмотреть статистику по странам - видно, что всё это благолепие в основном за счёт... сюрприз, Индии. Ну и ещё несколько пионеров внедрения IPv6 есть (причём какой-то логики по географическому соседству, экономическому развитию, политической свободе и пр. не прослеживается - в списке как Франция с Германией, но без остальных стран ЕС, так и Малайзия и Саудовская Аравия, - так что, подозреваю, это результат стараний национальных регуляторов). А в подавляющем большинстве стран с внедрением IPv6 или просто грустно, или очень грустно.
Loggus66
13.08.2023 10:47Видимо, старость мы встретим в конфигурациях "v6 для клиентов, трансляция в v4, v4 внутри сетей", а NAT никуда не денется для LAN.
А вот работает ли фильтр интернета от РКН на IPv6, или не умеет?
GennPen
13.08.2023 10:47А вот работает ли фильтр интернета от РКН на IPv6, или не умеет?
Раньше, до определенного времени не умел работать и обход блокировок включался переходом на IPv6. Но сейчас уже и IPv6 фильтруют. Но, как правило, фильтруют единичными адресами, а не подсетями.
Inoriol
13.08.2023 10:47+12На работе у нас ipv6 внутренние сети (мобильный оператор в Японии, иметь больше 16 миллионов абонентов в подсети это потребность практически).
Так вот, пока самая заметная проблема ipv6 это как хреново на нём работает весь софт. Такое ощущение что половина тестов заканчивается на этапе дуал стака и поэтому когда софт кто-то актуально деплоит в ipv6-only начинаются пляски с конями. И часто никакая документация, по умолчанию отрубленная поддержка и так далее и в том же духе. Короче переход на ipv6 будет явно не простым...Я тут хотел пример привести докер, но оказалось что в июне где-то они таки наконец обновили документацию с тем как актуально запускать ipv6 без плясок с конями. А вот что там было до июня и это без правил маскарада работать по дефолту вообще не будет.
iskatel
13.08.2023 10:47те. в 2023 году кусок документации по V6 написали в одном из основных и важных сервисов, используемых по всему миру.
Ещё лет 10, и остальные... тоже там будут.
php7
13.08.2023 10:47-4Раньше просто взял и забанил IP "злоумышленника" в CF или nginx
Сейчас попробуй пойми, что банить
Зачем такими большими пачками выделять на устройство?
Не будет ли с ipv6 как с "640 килобайт хватит всем"?
Aelliari
13.08.2023 10:47+4Пачки по /64 на устройство - для корректной работы slaac, чтобы анонсировал префикс - а дальше оно само. В том числе с использованием Privacy extension для автогенерации временных адресов
А банить - точно так же, только не адресами, а префиксами
VADemon
13.08.2023 10:47Давно объяснено по-моему регистрами: Если текущая политика выделения адресов окажется ошибочной, её для следующего большого диапазона пересмотрят. У нас сейчас 2000/3 или что-то там.
Antra
13.08.2023 10:47Допустим, я хочу свою домашнюю сетку и кучу лаб в разных облаках перевести на IPv6.
Сейчас на IPv4 я планирую, какой кусочек из 10.x.x.x отдать в Azure, какой в AWS... Потом из них нарезаю помельче для разных VNet, pod CIDR, service CIDR... 192.168 (чтобы не путались) для Wireguard и прочих VPN и стыков... Естественно, никаких 169.254.0.0
C IPv6 это как должно выглядеть? Аналогично выделять внутри fdb0:42fa:e71d:48f3?
В чем тогда преимущество перед IPv4, если все равно может оказаться, что потом захочется связаться с коллегой, у которого такая же сетка?
Вот если можно свой блок IPv6 получить "для дома, для семьи" - другое дело. Только на ARIN вроде и есть про Requesting Space as an End User, но вроде все равно создавать организацию и т.п. Может, конечно, гуглится устаревшая информация, но там было, мол "для домашнего использования не даем".
DaemonGloom
13.08.2023 10:47Считается, что провайдер выдаст клиенту /64 сетку. И большинство нормальных так и сделает, кстати. Хотя есть и отдельные провайдеры, дающие всего один адрес на клиента — а дальше тот уже страдает с NAT.
slonopotamus
13.08.2023 10:47+2Для дома дают блок /64. А если не жадничают, то вообще /48.
Antra
13.08.2023 10:47+2Конкретный провайдер даст, когда научится в IPv6, а когда перееду отберет?
На такое я не готов завязываться, чтобы не менять всю адресацию в лабе и прочих хоум ассистантах.
Или вы можете подсказать, у кого можно для дома действительно собственный блок получить, который даже при переезде моим останется?
Я пока вижу только отдельные предложения типа
И вроде Hurricane Electric Free IPv6 Tunnel Broker что-то может выделить. Но это будет не "мое", а на него завязанное. Конечно, мои нужды не mission critical. Но...
aborouhin
13.08.2023 10:47+1Вот, кстати да. А ещё даже дома, а уж тем более в офисе неплохо бы иметь пару провайдеров для резерва. Если внутренние адреса выделять из подсети одного из них - как оно должно работать, если этот провайдер отвалился и внешний канал переключился на второго? Я же свой префикс /64 внешнему миру анонсировать по BGP не смогу всё равно.
DaemonGloom
13.08.2023 10:47+1С переключением адресов самое печальное. Более того, если вы попытаетесь выдавать адреса от обоих провайдеров сразу своим компьютерам — временами всё будет ломаться наиболее странным образом, когда маршрутизатор будет пытаться послать пакеты с обоих сетей по одному и тому же каналу. Тут остаётся только NAT66, но с ним почти не остаётся преимуществ самого IPv6.
aborouhin
13.08.2023 10:47если вы попытаетесь выдавать адреса от обоих провайдеров сразу своим компьютерам
К тому же, DHCP такой фокус просто не даст сделать.
slonopotamus
13.08.2023 10:47Если внутренние адреса выделять из подсети одного из них
Нет, не так. Получать по адресу от каждого провайдера.
aborouhin
13.08.2023 10:47Только DHCP не умеет выдавать одному клиенту больше одного адреса. А на смартфоне с Android я сходу не нашёл даже способа вручную два адреса одному интерфейсу задать (наверняка можно через командную строку, но не факт, что без рута, ну и вообще, вручную забивать на каждый девайс по два IPv6 адреса - так себе "упрощение"). Всякие принтеры и IoT-устройства тем более такой возможности с высокой вероятностью лишены.
В общем, как-то светлое будущее с IPv6 не вырисовывается... по крайней мере, пока, кроме возможности получить /64 от провайдера, для любого клиента (в т.ч. мелкого и частного) не станет такой же общераспространённой возможность анонсировать свою /64. Но что-то мне подсказывает, что если каждый продвинутый частник или офис на 10 человек начнёт свои префиксы анонсировать - тут уже BGP чем-то заменять придётся (не погружён в эту матчасть глубоко, так что это только в порядке дилетантской гипотезы)
slonopotamus
13.08.2023 10:47+4Я не знаю что там в BGP по поводу IPv6, но в IPv4 оно такое решето, что любой участник может завалить порядочный кусок сети соседям, анонсировав кривую информацию. Далеко не самый лучший протокол в мире.
vikarti
13.08.2023 10:47Изначальная идея — каждое устройство в сети получит по ДВА public IPv6 адреса(точнее 4 если это клиент — privacy адрес ж есть) и будет выбирать правильный в зависимости от адреса хоста назначения (там набор правил есть). И два шлюза по умолчанию. И все ходют по своим блокам.
Оно даже работает. Вот только если по какой то дури трафик пойдет на роутере не в тот интерфейс — будет весело, если алгоритм выбирает исходящий адрес не правильно (например не учитывая что часть адресов надо гнать через туннель и третьего блока который с туннеля — должен быть приоритет). Если же один из каналов сдохнет — если при этом анонсы с роутера пропадут — еще полбеды.
И чтобы это нормально использовать — желательно тот самый "нежелательный" NAT пусть и без трансляции портов.
slonopotamus
13.08.2023 10:47+2М.б. вы хотите ULA? Поясню, в контексте IPv6 это совершенно нормально что у устройств есть несколько адресов. Можно одновременно иметь link-local, global, ULA (а то и несколько) и т.д.
aborouhin
13.08.2023 10:47А чем ULA в IPv6 в практическом применении лучше приватных IPv4 адресов? Если всё равно городить свою внутреннюю адресацию (а судя по всему, таки придётся) - то смысл дёргаться, оно и с IPv4 так же работает?
slonopotamus
13.08.2023 10:47IPv6 сделали не ради приватных адресов, они действительно ничем не лучше. Всё это затеяно в первую очередь чтобы того чтобы иметь достаточное количество публичных.
aborouhin
13.08.2023 10:47+5Но получается, что в любой минимально сложной конфигурации нам без приватных адресов всё равно не обойтись. Несколько провайдеров или смена провайдера - см. выше. Необходимость защиты доступа к внутренней сети через VPN? Опять. Ну и т.п.
Т.е. пока адреса IPv4 в принципе поддерживаются и доступны не за миллион денег хотя бы в количестве 1 шт. на физическую локацию - практического смысла сейчас переводить свои внутренние сети на IPv6 (да и вообще поддерживать у себя IPv6) для конечного пользователя (дом, офис, любой небольшой бизнес) никакого.
А поскольку светлое будущее, в котором IPv4 уйдёт в историю, мне ничего хорошего, кроме лишнего геморроя, тоже, похоже, не принесёт, - то и поддерживать IPv6 из идейных соображений, приближая личным примером это будущее, тоже как-то не хочется :)
avitek
13.08.2023 10:47+3Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не нужно выполнять перерасчёт для каждого пакета.
Контрольная сумма вычисляется "на лету", по мере приёма, поэтому лишних затрат времени не требует.
А вот что насчёт контроля целостности пакетов? Это отдано на откуп чему (или кому)?
alex_www
13.08.2023 10:47+2это задача протоколов выше, например TCP
mpa4b
13.08.2023 10:47+2TCP никак не контролирует целостность всех полей IPv4. Только некоторыx. А все поля заголовка IPv4 тот контролирует сам, своей отдельной чексуммой. Из IPv6 зачем-то вообще контроль целостности заголовка выпилили, прикрываясь тем, что этим должен заниматься канальный уровень. Ну в 90ые или когда там IPv6 придумывали это было разумно, а сейчас, когда даже 5950x раз в месяц срёт в логи machine check'ом по поводу исправления ошибки в L3 кеше (или где там -- мне из логов не очень ясно), такое решение уже не выглядит очень разумным. Нынче на 5 нанометрах лишних/ненужных проверок целостности не бывает.
alex_www
13.08.2023 10:47+1И не надо! Почему? Потому что именно пэйлоад чексумится на TCP уровне (L4). Кроме того весь трафик в 100G Ethernet(L1) и далее (ну и почти все over the air интерфейсы), имеет FEC. Чексуминг на других уровнях между L1 и L4 на практике оказался малополезным.
mpa4b
13.08.2023 10:47FEC езернет может иметь только в проводе, а CRC есть только от момента формирования фрейма до момента приёма с обработкой другим концом. Далее внутри при обработке уже либо не имеется ничего (сетвушка заботливо сложила фреймы в память компа без ECC) либо собственные велосипеды. Флипнется битик заголовка какой на этапе отсутствия контроля -- и в лучшем случае коннект дропнется. Чексум на заголовок IPv4 -- хороший способ (был) для сквозного контроля целостности.
czz
13.08.2023 10:47+1Между узлами — контроль целостности пусть делает L2. End-to-end — на L4 и L7.
А что там происходит внутри узла, должно ли это заботить? У узла есть свои меры для предотвращения ошибок. Везде, где это важно, стоит ECC память. В стандарте DDR5 уже обязательный ECC. И даже в кэшах, как вы заметили, есть чексуммы. Так что возможностью флипа внутри узла возможно пренебречь (иначе это дефектный узел, и его стоит поменять).
Semy
13.08.2023 10:47И мы получаем разные алгоритмы подсчета для v4 и v6, хотя по логике OSI это не хорошо (но кого волнует?). Ну хотя бы для UDP CRC теперь mandatory, а не optional.
Survtur
13.08.2023 10:47Подскажите, сейчас я использую разные методы смены внешнего IP адреса, чтобы выгружать данные, например, из инстаграма. Активно работаю через мобильные прокси, чтобы избегать банов по IP.
Что будет, если вдруг всё начнёт работать по IPV6? Не станет ли адрес фиксированным?
UPD: Пока писал, подумал, что прокси на то и прокси, чтобы показывать свой адрес, а не мой адрес. И раз попадается реклама прокси IPV6, то жить можно.
Aelliari
13.08.2023 10:47+1фиксированным
Скорее всего, вне зависимости от метода получения ipv6 - на интерфейсе будет статический адрес (хотя и DHCPv6 дающий разные адреса не запрещён). Но, в случае SLAAC и работающего privacy extension - исходящие адреса будут генерироваться с некоторым промежутком по времени (или по запросу приложения, а также не будут подходить для входящих соединений если приложение открыв сокет - прекратит его прослушивать). Другой вопрос что никто не помешает поступить идеологически верно, и блокнуть подсеть /64 из которой ты обращаешься к ресурсу
ivankudryavtsev
13.08.2023 10:47При этом блоки ipv4 дешевеют.
Просто у техногиганты решили начать монетизировать. Малые и средние компании покупают блоки и закладывают в цену, при этом цены все равно ниже, чем у грандов.
Tzimie
13.08.2023 10:47А как там ipv6 и ddos? Помогает больше защищающимся или тому кто атакует?
kozlyuk
13.08.2023 10:47Сейчас IPv6 DDoS, по сути, нет. Атак на доступность не будет, если нет доступности (с) мем.
В перспективе:
Если NAT не будет распространен, можно банить /64, не опасаясь задеть легитим. Но выше пишут, что в организациях с резервными каналами NAT может и остаться.
И этих /64 станет больше, чем сейчас /32. Пресловутый бан по GeoIP останется актуальным.
Stateful пакетная обработка для IPv6 тяжелее, чем для IPv4, при прочих равных. State растет, так как больше легитимных адресов и больше сами адреса.
Сами атаки не изменятся — все интересное начинается с L4.
Agne
13.08.2023 10:47+1https://habr.com/ru/articles/501476/
Статья от 2020 года, изменений, к сегодняшнему дню, в сущности никаких. Может когда будет IPv7/IPv8 , что-то улучшится. Потребностей в IPv6 у пользователей нет.
slonopotamus
13.08.2023 10:47+3Потребностей в IPv6 у пользователей нет.
То что вам что-то не нужно, не значит что оно никому не нужно.
turbotankist
13.08.2023 10:47+5Как у меня бомбит от вроде бы умных людей, разбирающихся в айти, но только поверхностно знающих сети и говорящих, что ipv6 хуже ipv4. И молящихся на NAT (Я кстати тоже думал что он замечает фаервол, когда был зелёным CCNA).
Вся проблема ipv6 только в том, что куча инженеров думают, что он не нужен и я не буду поддерживать его в своей инфраструктуре. И как итог хочешь не хочешь нужно ipv4 в своей сети тоже иметь чтобы работать с такими коллегами, а если он есть и работает, то зачем что-то городить дополнительное.
Всё нормальное оборудование поддерживает ipv6 c 2007 года точно.
Кстати, у автора статьи нет главного отличия ipv6 от 4, которое первым пунктом во всех книжках - отсутствие бродкаста и замена его мультикастом.
Ноют умные инженеры, что с 6 версией им неудобно тащить свои костыли и велосипеды. А вы только подумайте сколько крутых решений не родилось, потому что ipv6 не распространён - никто не пишет софт, который может быть будет работать у 25% пользователей.
Antra
13.08.2023 10:47+4И молящихся на NAT (Я кстати тоже думал что он замечает фаервол, когда был зелёным CCNA).
Не заменяет, а служит дополнительным рубежом обороны. Так же, как отсутствие маршрутов к "жертве" существенно усложняет жизнь атакующему.
И так же, как фаервол не является "серебряной (золотой?) пулей", обеспечивающей 100% защиту, а нужно вкладываться и во всякие WAF, и обеспечивать безопасность цикла разработки...
Вся проблема ipv6 только в том, что куча инженеров думают, что он не нужен и я не буду поддерживать его в своей инфраструктуре.
Да у многих компаний в лабах он развернут. И даже в отдельных сегментах. Чисто опыта набраться. Ибо в продуктив выставлять действительно мотивации не особо много (за исключением кейсов типа "сотовый оператор").
Мне вот интересно было IPv6 пощупать, причем не на адресах, "какие сами назначутся", а более приближено к реальности. Взял сетку /56, которую Oracle Cloud раздает в рамках Always Free, побил на более мелкие, поиграл с ней на наскольких тестовых сайтах. На Российском VPS (где провайдер выдаетIPv6) поднял Nginx reverse proxy на IPv6...
Пощупал, поиграл, и на этом все закончил. ибо внятных кейсов, где это помогло бы мне или моим заказчикам, не придумал.
Совершенно новые (и при этом весьма большие) внедрения - ну возможно. Но переделывать существующее - очень вряд ли.
ValdikSS
13.08.2023 10:47+3Пока появляются такие статьи с аргументами буквально: «у меня не открылся Github, IPv6 отстой!» (видимо, электромашины тоже отстой, раз «заправок» сильно меньше), мир строит IPv6-only сети.
MaxSoniX
13.08.2023 10:47+2+1
Удивительно что такая статья была достойна перевода, видимо vps-хостниг пытались снова оправдать почему "IPv6 не нужОн". С такими тезисами что в статье, что в коментариях противников v6 спорить бесполезно т.к. люди не углубившись в протокол и в ситуацию, аналогично ситуации с 5G кричат с пеной у рта "оператор не поддерживает, моё устройство тоже - не нужон". На эмоциях можно было собрать все эти не существенные тезисы в статью "Неасилиляторы IPv6 или по существу", но на практике показало что это бесполезно, проблема не в протоколе, в железе или провайдере, только в голове (не желании разбираться с IPv6, а тупо пытаться натянуть практики v4 на v6(сову на глобус)).
@ValdikSSприглашаем вас =)
https://t.me/version6
https://t.me/version6_offtopic
bbc_69
13.08.2023 10:47+1Процесс перевода команд на IPv6 будет очень тернистым, преимущественно
из-за того, что никто ещё с этим не сталкивался. Мы многие годы
откладывали освоение этой технологии, и теперь придётся за это платить.Приямо как переход Питона со 2-го на 3-й. Давали не то 8, не то 10 лет, а перешли все по факту только после полного отключения поддержки. Люди такие люди.
FSA
13.08.2023 10:47Я тут так много участвовал в дискуссии на счёт протокола IPv6, что забыл одну важную деталь, которая касается посыла статьи! AWS начинает взимать плату за драгоценный ресурс, такой, как IPv4. Так что всего этого можно избежать просто заплатив за роскошь - возможность использовать IPv4. Т. е. если ваш ресурс для вас ценен, просто оплатите услугу и забейте на все сложности, которые могут возникнуть при переходе на IPv6.
И вот что мне показалось странным. Неужели Amazon не предоставляет услуги NAT64? По мне так это самый логичный вариант. Пользователи услуги будут пользоваться готовыми шлюзами в IPv4 сеть и получать все необходимые ресурсы, при этом почти не почувствуют отсутствие IPv4, кроме разве что того, что их сервисы недоступны через IPv4. DNS для этих нужд есть у Googe и Cloudflare, например. NAT64 со специально выделенным диапазоном 64:ff9b::/96 должен предоставить ваш провайдер. Очень странно, что Amazon так не делает. У кого есть возможность, проверьте, должно быть.
Antra
13.08.2023 10:47Неужели Amazon не предоставляет услуги NAT64? По мне так это самый логичный вариант. Пользователи услуги будут пользоваться готовыми шлюзами в IPv4 сеть и получать все необходимые ресурсы
Не совсем понял кейс. Если речь об исходящем трафике, т.е. инстанс с приватным адресом лезет в Инет через какой-шлюз (неважно, полноценный фаервол и простой NAT gateway), то какая разница из какого семейства его приватный адрес? Вряд ли AWS берет деньги за 10.11.12.13
Skykharkov
Если коротко пересказать статью - то что IPv6 представляли как "серебряную пулю" получилось, пока что, как пуля совсем из другого мягкого материала... А еще миллионы (если не миллиарды) сетевых железяк, которые никак IPv6 не поддерживают, и никто их обновлять не будет, за дурные деньги и так далее... В идеале, если с нуля делать, то конечно оно супер будет. Но долго еще сисадмины будут седеть в поисках стабильных решений скрещивания того что есть с IPv6. А так идея, разумеется великолепная... Я про саму концепцию IPv6.
DreamingKitten
Кто представлял?
Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6.
Дуалстэк прекрасно работает годами. Отказываться от него пока рано.
iskatel
"Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6."
как человек с более чем 20-летним опытом и присутствовавший на семинарах RIPE в 2002 и 2003г., где тогда активно обсуждался и продвигался "новый классный протокол", могу сказать : массовой поддержки V6 20 лет назад не было, и в последующие годы тоже не было, тогда она была фрагментарной.
Даже в серьёзном сетевом железе полная (те. не "ой, смотрите, вот у нас что-то запустилось и пакетиуи бегают!") поддержка появилась позднее.
Ну и массовая поддержка V6 в огромном кол-ве сетевых сервисов и софте - это уже 2010е гг., где-то в районе 2015го, +- пара лет.
Причём 100% поддержки нет по сей день.
vikarti
IPv6 NAT у Mikrotik появился в RouterOS7 только (речь про NPTv6 конечно же). Зачем нужен NAT в IPv6? А потому что какой еще нормальный вариант с мультихомингом если нет возможности BGP поднимать с провайдерами?
Про /48 на сайт — ну вы это провайдерам объясните. Которых в рекомендации RIPE тыкаешь что хотя бы /56 надо но им пофиг, хватит клиенту и /64?
Это если IPv6 вообще — есть.
С DNS — если у провайдера есть возможность задавать rDNS для IPv4-адресов, совсем не факт что будет аналогичная возможность для IPv6 хоть в каком то виде.
Вот и получается что проще — туннель до he.net но тут скорость падает.
DreamingKitten
RFC 6275
Выбирайте брокера поближе
https://ru.wikipedia.org/wiki/Список_брокеров_IPv6