Эмблема дня запуска IPv6.
Несмотря на все эти дни и юбилеи, в практическом плане для полноценного глобального перехода на IPv6 и отказа от IPv4 сделано не так уж много. Инфраструктура сети Интернет в основном уже поддерживает и использует IPv6. Так, все корневые серверы DNS и, за малым исключением, все домены верхнего уровня (TLD) могут работать с IPv6. Их доля составляет 98.4% согласно отчёту. То же касается автономных систем (AS), а также Tier-1 и Tier-2 операторов.
Однако многие предприятия все ещё работают на старом протоколе не только на внутренних каналах, но и на периферии. Компании из списка Fortune-500 застряли где-то на полпути в переходе на новый стандарт. Согласно последнему исследованию The DNS Institute 270 компаний из списка Fortune 500 имели по крайней мере один домен, который не отвечал на запросы по IPv6. Кроме того, около 57% доменов не содержали всех серверов имён, доступных для IPv6.
Между тем отсрочка перехода на новый протокол чревата ростом издержек для компаний. В частности, капитальные и операционные расходы, a․k․a․ CAPEX и OPEX, будут со временем возрастать из-за роста стоимости таких решений, как Carrier-Grade-NAT и Large-Scale-NAT. Помимо этого, скорость передачи данных в определённых сценариях выше на IPv6 соединениях. В той же презентации Пол Сааб из Facebook сообщил, что одним из ключевых препятствий внедрения IPv6 является то, что код Java часто пишется исключительно для использования IPv4.
Откуда берётся такой выигрыш производительности? Теоретически, это можно понять, взглянув на структуру двух протоколов. Для такого сравнения пригодится утилита с говорящим названием:
|12:09:41|admin@redeye:[~]> protocol ip
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|12:09:45|admin@redeye:[~]> protocol ipv6
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Беглому взгляду видно, что в IPv6 отсутствуют некоторые поля IPv4, например:
Header Checksum, Padding и Protocol. Вычисление контрольной суммы пакета на сетевом оборудовании занимает определённое время, а вместе с Network Address Translation обсчёт производится дважды. Так как количество IPv6 адресов огромно — 2128, то отпадает нужда в NAT. Остальные усовершенствования нового стандарта, могут упростить работу сетевых инженеров, но вряд ли влияют на скорость передачи данных.
К другим преимуществам нового стандарта следует отнести простоту конфигурации сети, так как в IPv6 поддерживается автоматическая настройка сетевого адреса. Узел может создавать собственный IP-адрес, преобразуя MAC-адрес в Extended Universal Identifier (EUI) формат и записав его в 64-битный префикс идентификатора интерфейса. Никаких широковещательных ARP-пакетов, DHCP — по желанию.
Иногда к достоинствам IPv6 ошибочно относят более высокий уровень безопасности по сравнению с IPv4 на сетевом уровне OSI. Источником заблуждения может служить тот факт, что IPSEC является частью спецификаций нового стандарта. Несмотря на это, наличие протокола IPSEC не является обязательным условием реализации IPv6 соединений.
В какой-то степени повсеместное использование IPv6 адресации во внутренней сети могло бы снизить вероятность сканирования TCP/UPD портов, но для этого схема адресации должна быть рандомной и не иметь записи в DNS. Однако это же условие делает использование такой адресации крайне неудобной для системного администрирования. Кроме того, наличие IPv4 адресов сводит на нет даже эти преимущества.
▍ Чемпионы внедрения IPv6
В вышеупомянутом мероприятии World IPv6 Launch приняли участие крупные провайдеры и ИТ-компании:
- Akamai
- AT&T
- Cisco
- Comcast
- D-Link
- Free Telecom
- Internode
- KDDI
- Limelight
- Microsoft Bing
- Time Warner Cable
- XS4ALL
- Yahoo!
Из этих компаний с переходом на новые технологии довольно успешно справляются некоторые Tier-1 операторы.
За кадром графиков с идущими в горы показателями остаётся огромный объём кропотливой работы по замене и настройке сетевого и серверного оборудования. Компаниям пришлось также модернизировать сети абонентского доступа. В случае Comcast потребовалось обновить большое количество CMTS, в то время как T-Mobile заменил системы мобильной связи 4G.
▍ Российские реалии
Не все страны одинаково продвинулись на пути внедрения нового протокола. Единого и точного реестра всех IP-адресов на всех устройствах ни у кого пока нет, однако статистика крупнейших интернет-компаний может служить некоторым приближением. Можно воспользоваться сервисом Google IPv6 для беглого знакомства с раскладом по странам и версии IP. Чемпионом мира в этой номинации является Индия, где на данный момент более 62% всех подключений к службам Google используют IPv6.
На европейском континенте лидируют Германия (более 50%) и Греция (около 48%). Примечательно, что нет прямой связи между ВВП на душу населения и распространением IPv6. В Испании и Италии показатели хуже, чем в России. Родоначальники интернета США план выполнили меньше, чем наполовину (почти 46%).
Приблизительно ту же картину можно увидеть на графиках Akamai. Те же самые страны в лидерах и аутсайдерах внедрения нового протокола. Самое время задаться вопросом почему же в России тормозит переход на IPv6?
Локомотивом перехода на новый протокол, помимо государственных структур, должны быть крупнейшие операторы телефонии и интернет-провайдеры, которые в РФ с некоторых пор стали совпадать. Кроме того, среди первопроходцев обязательно должны были быть гиганты отечественного ИТ. В свое время было высказано много пожеланий, однако в практическом плане, сделано пока совсем немного.
Компания МТС объявило о переходе на новый сетевой протокол ещё в июне 2017 г. Данная услуга доступна на территории большей части России, а с 20.04.2020 интернет по IPv6 предоставляется автоматически. Однако такое подключение будет содержать ограничения по well-known TCP/UDP портам, для того чтобы от них избавиться, нужно подключить услугу IPv6+. Лентел подключает по новому протоколу жителей Санкт-Петербурга и Ленинградской области. Некоторые региональные интернет-провайдеры предоставляют подключение по IPv6 лишь в тестовом режиме.
Что касается крупнейших интернет-ресурсов Рунета, то и тут не всё радужно. Лишь двое из крупнейших поддерживают IPv6. Проверка с помощью команды из набора bind-utils, например:
|11:15:00|admin@redeye:[~]> host example.com
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 0 .и мы видим, что example.com имеет IPv6 адрес в базе данных DNS. Теперь то же самое для российских топ интернет-ресурсов:
- lenta.ru доступен только по IPv4
- mail.ru, доступен по IPv6
- ok.ru доступен только по IPv4
- sberbank.ru доступен только по IPv4
- vk.com, доступен только по IPv4
- yandex.ru, доступен по IPv6
Так что мешает ускоренному переходу российских компаний на новый стандарт IP протокола?
- Дороговизна. Пожалуй, это главная причина, ведь требуется замена оборудования огромного количества коммутаторов и маршрутизаторов, изначально рассчитанных только на IPv4. Нужно выделить бюджет на замену всего этого, также нужно предоставить обоснование для замены: и так ведь, всё работает.
- NAT спасает. Практически повсеместно используется NAT, к нему уже все так привыкли, что воспринимают его даже, как часть архитектуры безопасности ИТ-среды, хотя таковым он не является. Одной из сложностей перехода на IPv6 будет замена корпоративной NAT-адресации на новые стандарты с прямым TCP/IP соединением.
- Подожду остальных. На новые стандарты выгодно переходить не с самого начала, а когда большинство уже перешло на него. Это верно для одно отдельной компании, но для индустрии в целом, это тупиковый путь. Зачинщиками изменений выступают лидеры индустрии, но российские пока что осторожничают.
- Цензура. Правительство РФ, в лице РКН, всё ещё не забросило сомнительную, во всех смыслах, практику введения ограничений доступа к ресурсам сети Интернет, наоборот с каждым днём появляются новые инициативы. Повсеместный переход на адресацию и маршрутизацию IPv6 усложнит работу интернет-цензоров и разумно будет предположить, что гос․ органы по крайней мере не будут в ближайшее время способствовать ускоренному переходу на новый стандарт.
- Сложность. Переход организации на новый протокол — дело хлопотное. Отсутствие обратной совместимости между IPv6 и IPv4 создаёт немало проблем. В крупной компании такой переход может занять не один год и нужно чтобы бизнес-процессы не прерывались всё это время.
▍ Итоги и прогноз
Несмотря на солидный возраст и несомненные преимущества, как для пользователей, так и для поставщиков услуг сети Интернет, стандарт IPv6 всё ещё не стал повсеместным явлением на наших вычислительных устройствах. В последние несколько лет, правда темпы роста ускорились и в некоторых странах переход идёт без проволочек и скоро будет завершён. В России по ряду причин темпы распространения до сих пор остаются низкими. Помимо компании Яндекс мало кто начинал перевод внутренних служб и ресурсов на IPv6.
Несмотря на инерцию индустрии и скрытое противодействие со стороны регулирующих организаций, ситуация медленно, но верно будет двигаться в сторону непрерывного замещения IPv4 на IPv6. Процесс будет распространяться с внешнего периметра крупнейших интернет-провайдеров, серверов DNS, межсетевых экранов и устройств безопасности на внутренние структуры и уровень пользовательского доступа. По мере накопления опыта и подготовки соответствующих кадров в консалтинге крупнейших системных интеграторов, темп перехода будет расти.
Дополнительные материалы:
- Hexabuild IPv6 adoption report
- IPv6 deployment guide
- Меморандум Федерального CIO США с рекомендациями по IPv6
- version6.ru
Комментарии (127)
Francyz
14.10.2021 12:28+7Помню, как давным-давно вышел IPv6 с заголовками: "IPv4 скоро умрет", и вот прошло 10 лет, до сих пор умирает.
scruff
14.10.2021 14:10+6абсолютно уверен что в 2037 IPv4 будет еще существовать у большинства провайдеров. А во внутренних сетях - так еще с полвека не меньше.
dimaaannn
15.10.2021 00:54+7К другим преимуществам нового стандарта (IPv6) следует отнести простоту конфигурации сети
Вот из за этой "простоты" настройки его и не юзают.
Дыр в своей сети понаделать - раз плюнуть, а профита для небольших сетей вообще никакого.
Причём настраивать придётся и IPv4 и IPv6 одновременно.
P6i
15.10.2021 15:05+1Это старая традиция в мире айти (на самом деле и не только здесь) что-то хоронить. Я вот скоро на пенсию выйду, а венду тоже все хоронят)
Mnemonik
14.10.2021 12:29+13ipv6 крутая технология.
её конечно довольно сложно понять чисто теоретически. можно читать статьи, можно пытаться прикинуть что к чему пытаясь провести параллели с тем как всё в твоей лично сети устроено и как бы это было с ipv6, но всё равно самый крупный толчок ты получаешь начав что-то делать.
когда у меня появился ipv6 адрес от провайдера это стало отправной точкой чтобы подумать "так, ну вот адрес как бы уже есть, может попытаться уже сделать что-то?". и всё оказалось довольно просто и понятно и действительно удобно.
что меня больше всего поражает, это то, о чём почему-то никто не пишет во всех этих огромных статьях, но что знакомо каждому сетевику который делал хоть сколько-нибудь сложные сети. это то, как протокол грамотно выбирает исходных адрес при установке связи. каждый, кто пытался настроить сеть, когда на интерфейсе есть глобальный адрес, пара локальных и ещё впн, поймёт о чём я. в ipv4 есть адрес интерфейса с которого он будет выплёвывать все пакеты, и, чтобы заставить его правильно выбрать исходный айпишник, надо понаколотить всяких правил, чтобы пакеты в какой-нибудь туннель уходили откуда надо. в ipv6 это всё работает из коробки само собой. у меня сейчас на интерфейсе глобальный адрес (аналог внешнего айпишника), локальный адрес (что-то среднее между 127.0.0.1 и 192.168.0.0 - адреса которые существуют только между соседями и роутером, и никогда не выходят за роутер) и два немаршрутизируемых адреса (аналог 192.168.0.0 - два впн-а), и всё это работает вообще без всяких дополнительных настроек без всяких проблем. куда бы я ни коннектился, мой исходящих айпишник всегда тот, от которого до цели ближе всего по маске. вот это прямо крутая фишка ради которой я перевёл все свои внутренние соединения на ipv6, это прямо реально делает жизнь легче.
плюс по мелочи типа SLAAC, это такая недо-DHCP технология, когда роутер может объявлять себя роутером, и устройства в сети буду автоматически подхватывать нужные адреса и цепляться к этому роутеру. в сочетании с пунктом выше это делает ipv6 сети прямо практически магически рабочими. достаточно настроить роутер в сети и любое косое кривое неадекватное устройство прицепится и будет работать как надо.
Anrikigai
14.10.2021 13:27+1Звучит интересно, но я все равно не понял преимуществ "для дома, для семьи".
Не для "простых" задач, а именно для продвинутых. Когда нужны "входящие", установить связь с какими-то другими своими ресурсами. Вот как увас - несколько интерфейсов, туннели куда-то...
Пример:
Есть дом (роутер, сетка, ESXi, в нем несколько сегментов - VLAN)
Есть сервер (в частности, Always Free в Oracle Cloud с Ipv4 и IPv6)
Сейчас до него установлен туннель wireguard с Микротика
На OCI сервере крутится докер контейнер с Nginx Reverse Proxy + LetsEncrypt. Просто через туннель пробрасывает входящие запросы по именам на внутренние web-серверы (NextCloud в контейнере и проч), которые крутятся уже дома на ESXi.
Что мне нужно для IPv6 и что это даст?
Дома публичный IPv4 получить сложно. Оптика приходит в провайдерскую коробочку. Если даже ей и дадут публичный IP (хотя там по дороге еще 3 хопа на 172.16), у меня же в реальности еще свой Mikrotik.
Но если бы провайдер изо всех сил хотел меня осчастливить, что мне нужно опросить и как построить? Например:
Подсеть IPv6 (64 адреса), а дальше традиционно, как в IPv4?
На внешнем интерфейсе провайдерской коробочки прописать один из них
На внутреннем, подключенном к Mikrotik, "откусить" из них 4 адреса.
Оставшиеся хитро побить для домашней сети (WiFi, провод к TV, NAS, внешний интерфейс ESXi, гостевой WiFi...)
Остатки побить на несколько подсетей для VLAN внутри ESXi
Если все так, то становится гораздо сложнее. Либо нужен огромный блок IPv6, либо надо тщательнейшим образом думать, в какой VLAN ESXi сколько адресов отдать. Даже при том, что в реальности они мне в "публичном доступе" не нужны.
Ну т.е. зачем серверу в ЦОД нужен IPv6 я понимаю. Много таких серверов, требующих доступа к ним извне, требуют кучи публичных адресов. Но для дома и семьи зачем? Да и энтерпрайзу совершенно не нужно всю свою внутреннюю кухню делать маршрутизируемой извне (в т.ч. и в облаке незачем публичный IP вешать на MongoDB). Единственное вижу - захватить себе огромный уникальный блок адресов для внутренней сетки, чтобы потом не мучиться с overlapped IP при объединении с другой компанией на таких же адресах. А выход "наружу" все равно через NAT.
Incognito90
14.10.2021 13:51+4На сколько помню, из-того что читал про ipv6, по нынешним стандтам /64 подсеть неделимая..
т.е. в вашем случае вы должны получить от провайдера сеть больше чем /64, например /56 (на сколько помню именно /56 рекомендуется выдавать конечному абоненту) и разделить ее на сети по /64 для домашней сети/гостевого wifi/"серверной"..
Mnemonik
14.10.2021 13:55+7У вас правильное направление мышления, но всё ещё закостенелое под "ipv4" типа "зачем выделять так много адресов небольшому сегменту?". В парадигме ipv6 имеет значение префикс, всё примерно до /64, все остальные /64 это локальный блок, который выделяют не глядя иногда даже и на одно устройство. Суть в том, что ipv6 адреса уже нереально запоминать, мало того некоторые устройства их рандомно меняют (это тоже часть стандарта направленная на безопасность). В ipv6 сети надо полагаться на DNS, без этого уже никак. И если полагаться на DNS уже всё равно сколько там у кого каких адресов.
В вашем случае если я верно понял описание, что можно было бы сделать - так это например сделать wireguard туннель поддерживающим и ipv6 и выдать внутри вашей сети дома внешние айпишники вход на которые на хостинге кому надо. так можно было бы добиться доступности снаружи по ipv6 без всяких проблем для устройств внутри, раз вы переживаете что для дома не выбить свой ipv4. с ipv6 без проблем.
В моём случае у меня умный дом на две квартиры и загородный дом, это три подсети. Всего в одном месте есть реальный ipv4 (повезло с провайдером) из двух других мест туда wireguard туннели, и внутри всё по ipv6. три сегмента ipv6 /64, общая внутренняя /48 сеть, из любого места видно любое устройство, и что самое главное с ipv6 - это реально просто работает. если с ipv4 мне бы пришлось точно знать где у кого какой адрес в каких подсетях, какие там адреса в туннелях и так далее, настраивать роутинг на всех трёх роутерах чтобы один видел оба, а с двух друхи было видно всё через центральный, с ipv6 достаточно было настроить адреса на трех роутерах, и все устройства внутри получили свои адреса и сразу увидели друг друга, то есть не пришлось заморачиваться со сложным роутингом (он как бы так и остался сложным, но с ipv6 это заработало без проблем, включая то что я описал выше - некоторые интерфейсы имет по три разных айпишника, и всегда правильно выбирают с какого адреса выплёвывать пакеты в зависимости от того куда они идут). Отлично работает локализация трафика, не важно где я со своим айпадом, выплёвывается трафик в интернет из локального мне роутера (в одном месте есть внешний ipv6), мой внутренний трафик до устройств ходит внутри сети, где надо и через два хопа).
Сложность из заморочек с роутингом сместилась в сторону грамотно настроить DNS, так чтобы всех было видно по именам.
Anrikigai
14.10.2021 14:05Кстати, навели меня на мысль, что IPv6 действительно можно получить от Oracle Cloud через тот же wireguard (действительно поддерживает). И OCI выдает /56
Спасибо!
Mnemonik
14.10.2021 14:19Да, причём в ipv6 можно прокидывать айпишник используя роутеры с внутренними айпишниками по пути.
То есть можно дать устройству айпишник типа 2001:x:x:x:x:x:x:x и указать что default gateway fd00::1 какой-нибудь (роутер с wireguard которому не обазательно выдавать внешний адрес) и это совершенно нормальная ситуация. Это как дать устройству ipv4 212.1.1.1/32 и указать гейтом 192.168.1.1 (не получится), а в ipv6 работает.
Правда тут конечно придётся слега уже приколотить роутинг от и до этого айпишника через туннель. но всему же есть предел =D
Anrikigai
14.10.2021 14:57Тогда еще вопрос:
Допустим, я получу от своего ISP (или OCI) блок IPv6, и сделаю на нем всю домашнюю инфраструктуру. Это блок же их будет. Если я потом перейду куда-то, по идее. надо будет все переделывать.
Я понимаю, что DNS и все такое. НО можно ли каким-то образом свой блок ухватить? Скажем, первая попавшаяся ссылка предлагает
Регистрация PI IPv6
• Консультация по получению IPv6
• Подготовка документов на получение
• Регистрация объектов в RIPE
• Взаимодействие с RIPE NCC5000.00RUB
Если это одноразово и на всю жизнь, можно подумать. Если же ежегодно так платить - нафиг.
inkelyad
14.10.2021 15:09По концепции не очень положено. В IPv6 все задумывалось так, что адресное пространство по возможности прибито географически, что облегчает агрегацию маршрутов.
А домашняя инфраструктура должна при подключении к другому провайдеру принять от него префикс, добавить свою часть и быстренько сменить адреса на всех нужных интерфейсах уже под нового оператора. А если нужно что постоянное — то оно DNS именем адресуется, где привязанный адрес тоже должен смениться при смене оператора.
Anrikigai
14.10.2021 15:39С мобилками/телевизором проблем со сменой адресов не будет.
Интерфейс ESXi назначать динамически - ну ОК. Хотя серверам я и предпочитаю статику ставить. Как минимум, чтобы паение dhcp серевера их не рушило.
Но разбить новую сетку на кучу сегментов (и адреса, и DHCP пулы на них), обновить кучу интерфейсов не только на Микротике, но и на VyOS (на ESXi) - не знаю, как автоматически сделать. Потребует усилий
inkelyad
14.10.2021 17:08Нужность DHCP в IPv6 сетях заметно снижена. Всем этим железкам Route Advertisement от маршрутизатора и SLAAC не хватит, чтобы адрес получить? И никаких пулов настраивать не придется.
Anrikigai
14.10.2021 17:51Хорошо, пусть это будет не DHCP, а что-то другое. Вероятно я действительно мыслю категориями сетей и маршрутизации IPv4, а здесь сильно иначе. Я не вникал в IPv6 именно потому, что пока не видел особых преимуществ. Вполне возможно, здесь меня ждут приятные сюрпризы. Как я в свое время удивлялся UDR в Azure: "Как это для сети 10.2.2.0/24 я укажу шлюз 10.1.1.1??"
Можете вкратце описать процесс перехода от одной сети IPv6, полученной от провайдера, к другой?
Для меня (по аналогии с IPv4) это выглядит так:
На внешнем интерфейсе Mikrotik заменить адрес из сети старого провайдера, на сеть нового. Ну примерно как сейчас 192.168.1.2 поменять.
Что сделать со внутренним интерфейсом? На него остальные адреса новой IPv6 сети сами приедут, или надо руками спланировать?
Сделать это на всех внутренних интерфейсах (LAN, WiFi, WiFI-Guest, Servers)?
Допустим, серверы (ESXi и др), сами подхватили новые IPv6 адреса, и DNS записи для них обновились. Я их просто ребутнул, и все. Виртуальные машины из этого внешнего сегмента (vCenter...) тоже подхватили новые адреса, тут все ОК.
Но "внутри ESX" у меня крутится VyOS с десятком сегментов (просто VM от разных стендов, vSAN, vMotion, Frontend, Backend, Workload от Tanzu CE, Nested virtualization...).
На эти сегменты мне придется самому прописывать новые сетки? Или оно само побьет условные /56 на много /64 чудесным образом? Я не про "не надо перенастраивать DHCP" на каждом интерфейсе. Я про "неужели IPv6 адреса (default gateways для каждого сегмента) самостоятельно обновятся и на всех внутренних интерфейсах?
Если бы по какой-то причине я захотел поменять свои внутренние сетки с 192.168.128.0/18 на 172.16.0.0/18 - это было бы очень много работы. Аналогичная замена для IPv6 выйдет существенно проще?
Просто для IPv4 вероятность такой замены маловероятна.И уж точно не со сменой провайдера связана. Разве что захочу подключить свою лабу к корпоративной, и напорюсь на пересекающиеся IP,..
А в случае IPv6 будет странно остаться в домашней сети на адресах старого ISP. Если же для домашней сети сразу использовать IPv6 из Unique local address (или как там это называется) и делать NAT для выхода в Инет, то в чем преимущество перед 192.168?
inkelyad
14.10.2021 20:19+2Внешний адрес на маршрутизаторе тут должен интересовать только провайдера. Нам интересно, какую он нам сетку отдал.
Пусть это 2001:db8:1234:5600::/56
Дальше я бы делал приблизительно так:
2001:db8:1234:5600::1/64 используем для внешних сервисов, живущих на самом маршрутизаторе.
C 2001:db8:1234:5601::1/64 по 2001:db8:1234:561f::1/64 - для интерфейсов/сегментов, уходящих с маршрутизатора во внутреннюю сеть. Компы в этих сегментах получают свои адреса и default route по SLAAC. Соответствующее присваивание адресов нормальный IPv6 маршрутизатор по идее должен уметь делать по "полученный префикс + номер интерфейса"
2001:db8:1234:56c0::1/58 (64 штуки /64) - маршрутизируем в сторону хоста вируталок. Это, скорее всего, придется делать руками преимущественно потому что с демонами, нужными для автоматизации, возиться не охота.
Этот хост виртуалок, работая как маршрутизатор, точно так же (с такой же способностью перенумерации, если отдаваемый префикс изменился) навешивает адреса на интерфейсы виртуальных сегментов. (2001:db8:1234:56c1::1/64 -- 2001:db8:1234:56ff::1/64)
Виртуальный машины точно так же получают свои адреса и default router по SLAAC
Остались свободные 2001:db8:1234:5620::1/64 -- 2001:db8:1234:56bf::1/64, которые можно раскидать в качестве внутренних адресов на сервисы, живущие в облаках.
Теперь тут видно, что даже если у нас никакая автоматизация вида "получить префикс от вышестоящего маршрутизатора, взять номер интерфейса и получить адрес интерфеса" не работает, то все равно вся перенумерация делается тупым find/replace в паре конфигов. Т.е.
2001:db8:1234:56 -> префикс от нового оператора.
в конфиге входного маршрутизатора и в конфиге хоста виртуалок.
А ни хосты домашней сетки, ни виртуальные машины переконфигурировать не надо.
Anrikigai
14.10.2021 21:00Это радует.
Тогда чтобы я уж точно правильно понял - Почему наш внешний адрес интересует только провайдера?
Типа он мне даст /56 именно бонусом для внешней сети, а для подключения к нему еще один адрес из другой подсети? И по идее может только им и ограничиться, а /56 не дать, это совсем отдельный вопрос, который ему надо задавать?
inkelyad
14.10.2021 21:07Тогда чтобы я уж точно правильно понял - Почему наш внешний адрес интересует только провайдера?
Потому что все сервисы, что должны быть доступны извне, вешаются на адреса /56. А то что на внешнем интерфейсе - пусть как хочет в соответствии с перестройкой топологии собственной сетки меняет, лишь бы эту /56 правильно маршрутизировал. Собственно, тот, что внешний - при известном умении и витиеватости мышления оператора может вообще 'серым' быть. Уж не знаю, для чего это понадобиться может. Или его может не быть вовсе, если технология подключения абонентского маршрутизатора - точка-точка, а не etherner-о подобная шина. Или другой вариант - перезд в рамках этого же оператора. Внешний адрес изменился (потому что выдается в соответствии с портом коммутатора или что-нибудь похожее), а /56 - так абоненту и пробрасывается.
Типа он мне даст /56 именно бонусом для внешней сети, а для подключения к нему еще один адрес из другой подсети? И по идее может только им и ограничиться, а /56 не дать, это совсем отдельный вопрос, который ему надо задавать?
Эта /56 нее должна быть бонусом. А должны выдаваться всегда. А те, кто ограничиваются /64 на внешний интерфейс - это какое-то бессмысленное недоразумение делают.
kovserg
14.10.2021 21:26А что мне мешает каждую милисекунду менять ipv6 адрес внутри такого здорового допустимого диапазона? Тем самым создавая нагрузку та таблицу маршрутизации. Какие требования к маршрутизаторам должны быть?
inkelyad
14.10.2021 21:35+1На чью таблицу нагрузка? У провайдера запись в таблице маршрутизации одна: такую-то /56 кидай-то в такой-то порт/в такой-то ONU/на такой-то адрес (который оператор знает и менять его так быстро ему смысла нет). И этот адрес не предназначен для того, чтобы его как-то абонент трогал.
А то что внутри этой /56 сервисы как попало прыгают - его это не особо волнует.
inkelyad
14.10.2021 22:19Не понял вопроса. Ситуация ничем не отличает от того, что сейчас оператор знает, в какой порт какого коммутатора слать мой IPv4 /32. Который агрегируется со всеми остальными абонентами и уходит в 'большой' интернет здоровенными кусками.
edo1h
18.10.2021 00:27На чью таблицу нагрузка? У провайдера запись в таблице маршрутизации одна: такую-то /56 кидай-то в такой-то порт/в такой-то ONU/на такой-то адрес (который оператор знает и менять его так быстро ему смысла нет
ну, справедливости ради, обычно доступ к таблице маршрутизации кэшируется, и при ротации адресов всеми клиентами раз в миллисекунду нагрузка и правда вырастет.
inkelyad
18.10.2021 09:08Я все-таки этого аргумента не понимаю. Ну да, если таким образом ротировать — маршрутизаторам может поплохеть. Но вот из каких соображений оператор так делать будет?
Наоборот, в IPv6 как выдал префикс/адрес клиенту — так он время существования договора и использует. А маршрут хоть как-то меняется только если меняется железка/порт, куда абонент цепляется.
Ладно, если терминал мобильный (натуральный сотовый телефон), и он по базовым станциям скачет. Ну так у такого оператора и маршрутизаторы на такое рассчитаны by desigh. А для обычного стационарного доступа — оператор вроде как сам себе дополнительную головную боль придумывать не должен.
edo1h
18.10.2021 09:24вы невнимательно читали, речь про то, что абонент может устроить мини-дос на сетевую инфраструктуру.
inkelyad
18.10.2021 09:30Как? Ну вот в примере выше 2001:db8:1234:5600::/56 выдали абоненту. Прибили к порту. Оператор вписал этот маршрут в свою железку. В результате при маршрутизации пакета вот только на эти биты и нужно смотреть, а остальные просто игнорируются и тупо копируются 'как есть'
Как абонент чем-то напрячь оператора может?
edo1h
18.10.2021 09:38я могу ошибаться, с устройством роутеров можно сказать незнаком, поэтому можете считать, что это мои предоположения.
ходить каждый раз в таблицу маршрутизации дорого, поэтому есть кэширующая хэш-таблица, условно «хэш ip: интерфейс + mac».
и вот эта таблица имеет лимиты по размеру, 2^(128-56) записей в неё точно не поместится )
inkelyad
18.10.2021 10:00Оно же иерархическое. Грубо говоря, ближе к центру сети есть маршруты на /48 (их мало) + какие-то исключения от тех, кто переехал с оригинальной точки доступа.
На маршрутизаторах ближе к клиенту — уже /56.
Половина IPv6 сделана для того, чтобы было удобно так делить и маршрутизатору не нужно было на слишком много бит адреса смотреть.
edo1h
18.10.2021 10:17Половина IPv6 сделана для того, чтобы было удобно так делить и маршрутизатору не нужно было на слишком много бит адреса смотреть.
а как тут ipv6 улучает ситуацию с сравнении с ipv4?
inkelyad
18.10.2021 10:26Битов в адресе больше, поэтому легче уровни иерархии адресов нарезать.
Самих адресов больше, поэтому от всяческой динамики выдачи адреса клиента можно отказаться, а делать вот так тупо, как я писал — прибить выдаваемый адрес/префикс к порту коммутатора прямо на этапе его установки и больше не дергаться.
edo1h
18.10.2021 10:30Битов в адресе больше, поэтому
… в таблицах маршрутизации потенциально на порядки больше записей
как я писал — прибить выдаваемый адрес/префикс к порту коммутатора прямо на этапе его установки и больше не дергаться
на практике домру так не делает, выдаёт каждый раз новую сеть /64
Anrikigai
14.10.2021 21:29Собственно, тот, что внешний - при известном умении и витиеватости мышления оператора может вообще 'серым' быть.
Точно, тут же было уже, что можно даже next hop делать "дальше", а не из той же подсети
edo1h
18.10.2021 00:23Если это одноразово и на всю жизнь, можно подумать. Если же ежегодно так платить — нафиг.
нет, ежегодно тоже придётся платить, сумму лень искать.
плюс договариваться с провайдерами о bgp-пиринге, что для частного клиента малореально.Anrikigai
18.10.2021 09:47Я уже понял, что тут очень сильно все по другому. И мне надо сперва много чего изучить прежде, чем вопросы задавать :)
Сейчас, к примеру, isc-dhcp-derver прекрасно работает на ipv4, обновлет bind. А вот от isc-dhcp-server6 ни Alpine, ни Ubuntu адресочек получить не могут.
Если статически прописать - нормально взаимодействуют.
Если запустить на них
dhclient -6 -d eth0адрес получают.Он потом виден вip a. А вот при старте нифига/ Причем ладно Alpine, там я мог ошиьиться вiface eth0 inet6 dhcp(или auto). Но при установке Ubuntu server просто включаю enable Ipv6 DHCP, и он крутит, крутит, и никаких следов в логах isc-dhcp-server6...Казалось бы, простейшая операция. По dhclient все работает, а вот поди ж ты...
Идеологически тоже не понимаю. Вряд ли стоит ожидать, что каждая (небольшая, средняя) организация будет получать свои PI (/48). Даже не во всех банках BGP AS имеется, и ничего, живут. В том числе имея 2-3 ISP.
Если же небольшая компания всю свою внутреннюю сетку сделает на PA, как ей потом провайдера менять? Как по мне, серверам лучше статика, зачем лишнее звено в виде DHCP сервера. Но статически прописывать, как сейчас, точно не стоит. А динамически - при смене сервера (привязка к MAC?) появятся сложности.
Или, допустим, большая контора таки получила свой PI (/48). Раздала по филиалам по всей стрнае, к примеру, /56. Дальше надо договариваться, c ISP в разных точках (Москва, Уфа, Владивосток), соответствующие подсетки маршрутизировать через них. Суммаризировать нельзя. Самарская /56 иногда может через Москву пойти, иногда через Уфу. Провайдеры возьмут /56 для такого?
Если как сетки делятся я еще разберусь, то как с best practices познакомиться, не представляю.
edo1h
18.10.2021 10:12адреса ipv6 (точнее префиксы и т.п.) раздаются с помощью ra, так что вам нужен radvd.
когда проектировали ipv6 хотели избавиться от dhcp вовсе, но не получилось, через ra не все настройки можно раздавать, так что теперь имеем связку radvd+dhcpd )Anrikigai
18.10.2021 11:02Я ориентировался на
stateful DHCPv6 (IPv6 through dhcpv6 + dns + domain)
stateless DHCPv6 (IPv6 through SLAAC + dns + domain)
И рассчитывал только на верхний вариант (без SLAAC).
Ок, попробую еще и radvd добавить. А можно в таком случае будет без isc-dhcp-server6 обойтись? Или он нужен, чтобы bind обновлять? (типа простыv клиентfv типа телефона досточно radvd, а если сервер, которому нужна запись в DNS, тогда без dhcp никак)
И все равно непонятно, почему через dhclient он адрес получает (без radvd), а просто при старте не может.
Сейчас еще обратил внимание, что в конфиге описано /64, а получил /128. В общем, буду разбираться.
subnet6 2603:c022:XXXX:XX08::/64 {
range6 2603:c022:XXXX:XX08::20 2603:c022:XXXX:XX08::EE;
}Anrikigai
26.10.2021 19:04В общем, в итоге все сделал через dnsmasq. И обычный dhcp, и для ipv6, и SLAAC для мобилолок (кто оба варианта понимает просто получают два IPv6 адреса).
И DNS резолвит для выданных адресов. Причем для разных подсетей с разными субдоменами (ну типа в отдельном VLAN резолвится на xx.lab.xx.xx)
B итоге через туннель wireguard из дома уходит по IPv6 на VPS и дальше в Интернет (ибо у домашнего провайдера IPv6 нет)
ivandeex
18.10.2021 16:47А так можно делать и в Windows и в Linux?
А не присоветуете статью или статьи, где был бы описан алгоритм селекции интерфейса в IPv6
и явно описаны допустимые ограничения при выборе next hop или default gateway?
Я сколько ни рылся, не могу найти внятного изложения хоть где-то.
dartraiden
15.10.2021 03:42+1К слову, включить IPv6 в Oracle Cloud это тот ещё квест.
Anrikigai
15.10.2021 08:21О, спасибо за наводку!
Вчера как раз глянул, убедился, что возможность такая есть, но что где конкретно прописывать интуитивно не понятно было. На выходные отложил.
dartraiden
15.10.2021 19:51Это ешё цветочки по сравнению с включением двухфакторной авторизации, до настроек которой сначала надо добраться, затем разрешить использовать конкретные вторые факторы, после чего появится возможность их настроить (например, добавить QR-код в мобильный аутентификатор) и, так как вторые факторы лишь разрешены, теперь нужно настроить политику авторизации, сделав второй фактор обязательным. И всё это настраивалось по мануалу в каком-то блоге на корейском языке, где картинки автор любезно свалил в кучу после текста.
Кровавый энтерпрайз во всей красе.Anrikigai
15.10.2021 21:02Честно говоря, я вообще Oracle Cloud воспринимал как ориентированный на огромный энтерпрайз. Не жду, что он будет прикладывать усилия, чтобы было удобно частнику типа меня. Дал халяву - и молодец, воспользуюсь :)
А в огромном энтерпрайзе, вероятно, по их мнению, должны быть специально обученные их интерфейсу и идеологии люди.
vvadzim
14.10.2021 13:59Если получили /64, то дальше не делится, но всё равно всё работает. У меня дома в беларуси работало. Промежуточные роутеры просто работают как хабы, всё как бы в одну подсеть собирается. Мне единственное что было нужно - доступ снаружи к любому устройству без лишних танцев. Соответственно, моя задача была решена.
ramyalexis
14.10.2021 19:45+2Он не делится не технически. Он не делится организационно.
Best practice такой. Для понимания можно пройти курс (он супер короткий) от Ripe NCC скажем. https://academy.ripe.net/
Отпадёт большинство вопросов. Там и про размеры сетей когда и где применять. И как оно работает и так далее. Короче курс реально короткий. Ну пол часа чтения текста с картинками как максимум.
CherryPah
14.10.2021 14:20Оптика приходит в провайдерскую коробочку. Если даже ей и дадут публичный IP
Зачем провайдерскому свичу выдавать внешний адрес, это коммут, а не роутер.
хотя там по дороге еще 3 хопа на 172.16
Тоже не играет роли
Дома публичный IPv4 получить сложно.
Это конечно от провайдера зависит, но многие дают такую услугу (хотя зачастую за отдельные деньги. Конечно в ситуации когда провайдер один и такой услуги нет - это проблема
еще свой Mikrotik.
Ну тут, как говорится, мои полномочия всё =( только портфорвардить
Anrikigai
14.10.2021 14:53Зачем провайдерскому свичу выдавать внешний адрес, это коммут, а не роутер.
Таки роутер. На внешнем интерфейсе у него 10.0.0.0, в сторону Микротика смотрит 192.168.1.0
Публичный адрес за деньги сравнимые с омими 80Mbps можно заказать (провайдер только один в районе), но проблемы с портфорвардингом сохранятся. Поэ
Потому и сделал вншений Nginx
Sly_tom_cat
15.10.2021 11:21Мой провайдер IPv6 пока не дает, но белый IPv4 позволил настроить 6to4 и даже с таким костылем все эти плюшки можно использовать.
GennPen
15.10.2021 12:526to4 имеет меньший приоритет трафика. Лучше посмотри в сторону тоннеля от Hurricane Electric. Их адреса определяются как нативные и выдают подсети /64 + /48.
Incognito90
15.10.2021 14:00а если настроить 6to4, через 6in4? (в смысле в настройках роутера выбрать "6in4" и указать "192.88.99.1" в качестве адреса сервера)
GennPen
14.10.2021 13:00NAT спасает. Практически повсеместно используется NAT, к нему уже все так привыкли, что воспринимают его даже, как часть архитектуры безопасности ИТ-среды, хотя таковым он не является. Одной из сложностей перехода на IPv6 будет замена корпоративной NAT-адресации на новые стандарты с прямым TCP/IP соединением.
Не вижу в этом ничего сложного. Достаточно в роутере включить политику блокирования по умолчанию и все соединения по умолчанию будут резаться. Или есть такие отчаянные люди которые все входящие соединения по умолчанию разрешают?
p4s5w0r9
14.10.2021 13:00-1Учитывая что людям раздают не адреса, а целые подсети, то с таким подходом и ipv6 может вскоре закончиться.
event1
14.10.2021 15:55+1не может. Адрес ipv6 — 128 бит. Раздают подсети /64. Несложная математика подсказывает что существует 2^64 таких подсетей, что примерно равно 10^20. Людей на Земле, порядка 10^10. Выходит 10 миллиардов подсетей на лицо
GennPen
14.10.2021 17:02Рекомендуют раздавать /56 подсети, либо вообще /48. Но многие провайдеры в упор не хотят раздавать подсети выше /64 и из-за этого приходится использовать сервисы типа Hurricane Electric, если нужно делать IPv6 для нескольких подсетей.
Semy
14.10.2021 17:04Это какая-то слишком в лоб математика. Организации обычно выделяют сеть /32. Так, что раздать она может немного более 4 млн /64. Это уже не миллиарды. Для небольшого оператора это нормально, но большому уже надо больше чем /32. Ну и вы куда-то выкинули зарезервированные адреса: fc00::/7, ff00::/8, fec0::/10, fe80::/10, 2002::/16, 2001::/32 - это только самые крупные.
event1
14.10.2021 19:02+1Организации обычно выделяют сеть /32. Так, что раздать она может немного более 4 млн /64
В одну /32 влезает 2^32 /64 или чуть 4-х миллиардов. Одну оставит себе остальные раздаст. Три таких провайдера покроют все личные и корпоративные сети в мире в обозримом будущем
Ну и вы куда-то выкинули зарезервированные адреса: fc00::/7, ff00::/8, fec0::/10, fe80::/10, 2002::/16, 2001::/32 - это только самые крупные.
Справедливо. Исправляюсь. Всего зарезервированных адресов /64-подсетей порядка 10^17. Вычитаем из 10^20. Получаем 10^20
turbotankist
14.10.2021 16:48В дополнение, сейчас выдают айпишники только из диапазона 2ххх.хххх
То есть 1/8 из возможных. если окажется, что сейчас раздали адресу неправильно - есть ещё 7 попыток.
Firelander
14.10.2021 13:06+1Я конечно не понял зачем делать адрес длиной 128 бит, чтобы уж точно хватило всем? IPv6 штука конечно интересная, интересно было почитать разобраться, настроить. Так что теперь мне провайдер на мою скромненькую домашнюю сеточку из трех устройств выдает префикс аж /64, что ну так самую малость больше, чем все iv4 адреса в мире. Я конечно рад такой щедрости, но не особо понимаю действительно ли полезно с точки зрения реализации и использования протокола гонять все эти лишние байты.
sidorovmax
14.10.2021 13:44Скорее всего выдали 64к адресов
psycho-coder
14.10.2021 15:50Довольно подробный курс по введению в ipv6 www.networkeducation.ru/video/track/ipv6
И хороший и основательный учебник с теорией, немного устаревший но не сильно
sites.google.com/site/yartikhiy/home/ipv6book
Semy
14.10.2021 17:27Я поддержу, похоже на разбазаривание.
Когда я получил от провайдера /64, думал, сейчас побью домашнюю сеть на несколько сетей для удобства. Оказалось, что нет, из за EUI-64 это все не будет нормально работать. То есть, провайдер еще и пожадничал и нужно еще шире сетку, еще больше адресов уйдет в небытие.
edo1h
18.10.2021 00:33как я понимаю, идея изначально была в том, чтобы отказаться от необходимости хранения сопоставление mac-адресов ip-адресам просто включив макадрес в ip-адрес. то есть адрес составлялся из префикса, полученного от провайдера, и макадреса, зашитого производителем оборудования.
потом дошло, что это дурацкая идея и сейчас фактически от использования макадресов в ip-адресах отказались.none7
18.10.2021 14:07Идея то не дурацкая, только как и в случае Wi-Fi, MAC-адрес лучше подделывать. И хорошо бы было вообще отказаться от коммутаторов в пользу маршрутизаторов с поддержкой ndp-proxy. В таком случае даже destination unreachable будет отсылаться сразу при выключении порта, а не улетать в blackhole. И петли не приведут к broadcast-шторму. И QoS в пределах своей сети будет работать. И мультикаст, который для IPv6 очень желателен, но практически нигде в коммутаторах нормально не реализован. И сканирования сети не приведёт к переполнению ndp-таблиц. IPv6 достаточно прост, чтобы сложность его обработки была не сильно выше сложности коммутации пакетов. Но производители железа не пошли на поводу у разработчиков стандарта, ибо им будет сложно потом обосновать почему маршрутизаторы стоят так дорого.
estet
14.10.2021 13:58+1Даже не все московские провайдеры внедряют IPv6. Несколько лет назад разговаривал с QWERTY насчёт использования IPv6 для клиентского оборудования и они даже не планировали ничего делать. И сейчас ничего не поменялось.
Провайдеры, которые поддерживают - https://version6.ru/isp.
imbasoft
14.10.2021 14:53+5IPv6 - пример технологии, которая никому не нужна. Если за 10 лет на нее не перешли, то дальше точно не перейдут. Скорее всего будет что-то другое.
GennPen
14.10.2021 17:05Не нужна пока есть костыли в виде NAT для IPv4.
Лично мне дома проще открыть порт на нужную машину по IPv6, чем возиться с пробросом портов на IPv4.
Semy
14.10.2021 17:30NAT для IPv4 хоть объясним. А как вам такое: https://datatracker.ietf.org/doc/html/draft-mrw-behave-nat66-01
imbasoft
14.10.2021 18:22-3NAT - решает не только проблему нехватки адресов. Он одно из лучших средств изоляции корпоративной сети от Интернет. Поэтому в IPv6-to-IPv6 NAT нет ничего удивительного, IMHO, ИБ-шники его продавили.
GennPen
14.10.2021 19:02+4Он одно из лучших средств изоляции корпоративной сети от Интернет.
Так а в чем проблема на роутере блокировать входящие подключения для подсети IPv6?
imbasoft
15.10.2021 09:25Преимущество NAT в сравнении с простой блокировкой в том, что:
1) скрывается структура внутренней сети;
2) немного увеличивается защищенность от "открытия сети в Интернет", возникающая в результате ошибок администрирования.
P.S. Я говорю про изоляцию NAT-ом "потребителей" трафика (пользовательские компы). Прятать за NAT сервера смысла не имеет, тут действительно лучше использовать роутер.
GennPen
15.10.2021 12:54+21) скрывается структура внутренней сети;
Как можно узнать структуру сети, если входящие запросы будут блокироваться?
Anrikigai
15.10.2021 18:06Если исходящие не через NAT, а с "внутренних" IP, становится видна структура сети - какие есть подсети с клиентами... Если сервер полез за обновлением - серверные подсети.
Лучше удалять заголовки X-Forward-For, поставленный вашим прокси при покидании сети компании. Чистить заголовки цепочки серверов, чтобы снаружи был виден только финальный почтовик, а не цепочка Эксчейнджей...
Это все само по себе не смертельно. И полагаться исключительно на Security through obscurity - дело гиблое. Но зачем облегчать жизнь злоумышленнику?
JerleShannara
15.10.2021 20:55Зачем удалять, я стёба ради туда мусор генерирую, некоторые сайты плющить начинает от IP типа 666.666.666.JOPPA
blind_oracle
14.10.2021 19:10+4NAT не имеет ничего общего с безопасностью. То, о чём вы говорите, это Stateful Firewall и Connection Tracking. Всё это ровно так же делается и в IPv6.
Anrikigai
14.10.2021 19:40+1Это как сказать. Конечно, называть NAT "средством безопасности" странно.
Но сравните две конфигурации:
1) Сервер в DMZ, имеет публичный IP и от внешнего мира защищентолько фаерволом.
2) Сервер в ЛВС на приватном IP за Hide NAT и фаерволом
В первом случае одно неверное движение, и сервер окажется доступным из Интернета. Админ вполне может ошибиться.
Во втором случае, чтобы сервер оказался доступным из Интернета, надо не только "убрать правило, блокирующее подключения извне", но и выделить серверу публичный IP... Случайно такое сложно сотворить. Надо прицельно создававть для кого-то доступ и перепутать серверы.
blind_oracle
14.10.2021 20:23+5Никакой разницы нет.
NAT для своей работы требует Connection Tracking чтобы помнить какие соединения "изнутри" были созданы.
Этот же механизм используется и в Stateful Firewall - который обычно включен вместе с NAT.
Если взять тот же Linux, то в iptables, упрощённо, будут правила:
Транслировать адреса из приватных в публичные (-j MASQUERADE / SNAT)
Обратно пропускать только пакеты, относящиеся к уже установленным соединениям (-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT)
Остальные входящие пакеты рубить (-P DROP)
В итоге в IPv6 мы просто убираем правило #1 SNAT/MASQUERADE и всё продолжает работать как раньше - входящие соединения извне на хосты в локалке дропаются.
Oll123
15.10.2021 19:10+2Зачем вы упорно на технический аспект упираете? Нат - требует действий для того, что бы внутренний ресурс был доступен. Ipv6 - требует действий что бы внутренний ресурс был НЕ доступен.
В общем и целом обычно желательнее, что бы внутренний ресурс НЕ был доступен.
Вот и все.
Построение систем в которых возможность пользовательской ошибки меньше благодаря архитектуре - мне кажется азы понятные любому, потому что люди ВСЕГДА будет ошибаться.
Ipv6 и создавался то для другого, как раз что бы доступно было ВСЕ. А в реальности далеко не всем людям это нужно, вот и едет внедрение.. как едет.
blind_oracle
16.10.2021 10:45+2Потому что люди не понимают что такое NAT/conntrack и как это работает вместе.
Если использовать просто NAT (без правил, которые отсекают пакеты, не относящиеся к установленным соединениям) - к тебе в локалку сможет залезть практически любой, просто отправив твоему роутеру пакет предназначенный для какого-нибудь 192.168.0.x
Ибо роутер он чтобы роутить пакеты - и он сроутит, согласно правилам файрволла и таблицам маршрутизации.
Так что это не безопасность, а её иллюзия. Поэтому во всех (нормальных) домашних роутерах есть нужные правила, которые это дело блокируют. И если убрать IPv4+NAT и заменить это IPv6 - ничего не поменяется.
edo1h
18.10.2021 00:46Если использовать просто NAT (без правил, которые отсекают пакеты, не относящиеся к установленным соединениям) — к тебе в локалку сможет залезть практически любой, просто отправив твоему роутеру пакет предназначенный для какого-нибудь 192.168.0.x
небольшая ремарка: у большинства провайдеров сейчас клиенты сидят в раздельных сегментах l2, так что под «любой» на практике подходит только сам провайдер (ну или хакер, который проник в его внутренную сеть).
blind_oracle
18.10.2021 08:06Ну, про большинство - я бы не был так уверен. В РФ до сих пор куча провайдеров где клиенты сидят в /16 сетях, все видят всех и авторизуются по PPTP/PPPoE.
У меня в Подмосковье у родителей два провайдера - и оба таких.
Так что я бы не надеялся на безопасность за счёт провайдера - тут как повезёт.
inkelyad
14.10.2021 20:42+1Во втором случае, чтобы сервер оказался доступным из Интернета, надо не только "убрать правило, блокирующее подключения извне"
Это какой-то немного странный firewall. В правильном это правило стоит всегда и убрать его нельзя. А добавляется как раз разрешающие.
Anrikigai
14.10.2021 21:16+2Коль скоро мы тут в основном про домашние сетки говорим (по крайней меряе я), рассмотрим подключение типичного пользователя:
Воткнуть маршрутизатор
Прописать на внешнем интерфейсе адрес, что дал провайдер
При необходимости поправить адрес на внутреннем интерфейсе
Если не заработает, еще и включить NAT на внешнем интерефейсе.
Никаким ошибками не удастся легко и непринужденно выставить все домашние ресурсы наружу.
Скорее наоборот, для того, чтобы выставить какой-то внутренний сервер наружу, придется заморачиваться с Port Forwarding и т.п.
При наличии же глобально маршрутизируемых адресов во внутренней сети я уже не был бы спокоен и правила своего Микротика перепроверял бы тысячекратно.
Есть куча не самых маленьких компаний с таким же Микротиком, как у меня, вручную задающие правила его фаервола. Если же говорить об энтерпрайзе, там часто используются удобные управлялки с GUI, Web интерфейсом... При наличии правила типа
Src: Internet / Dst: Web_server / Service: HTTPS / Acceptвполне можно случайно удалить "Web_server". И во многих случаях значение в пустой яейке станетAny, открыв в случае глобально маршрутизируемых адресов всю внутреннюю сетку (в данном случае только по HTTPS, но это не принципиально).Конечно, это не всегда так. Скажем, в последних версиях Check Point вместо Any станет None, и политика не установится. Так я и не говорю, что "с IPv6 мы все умрем". Но риски повышаются, как ни крути. От некоторых ошибок NAT защищает (снижает риск).
inkelyad
14.10.2021 21:26+1В контексте IPv6 именно домашние маршрутизаторы, что его умеют почти поголовно (у них, кажется, это в правилах сертификации какой-то вписано) как раз закрывают по умолчанию коннекты снаружи внутрь.
Mikrotik- ни разу не домашний. Так что проверяем, да.
А у ентерпрайзов всякие системы анализа вторжения просто истошно завопят (что, впрочем, не означает, что пользователь, а не безопасники это увидят) когда увидят прошедший коннект снаружи внутрь. Так что подобную ошибку быстро починять.
Anrikigai
14.10.2021 21:59А у ентерпрайзов всякие системы анализа вторжения просто истошно завопят
Я бы не был столь оптимистичен. Скажем, применительно к филиалу банка, заметят скорее после того, как из этого филиала по сети начнет зараза расползаться.
В целом-то я, безусловно согласен. Если мне скажут "NAT - это средство безопасности", сам же и ухмыльнусь.
jok40
14.10.2021 21:34+1Есть и обратная сторона медали: в первом случае сервер стоит в DMZ, а значит отгорожен фаерволом не только от интернета, но и от локальной сети. При проникновении злоумышленника на этот сервер скомпрометированным окажется только этот сервер — в локалку он не сможет зайти, уткнувшись в глухую стену фаервола. Именно для этого этот сервер и выносили в DMZ. Во втором же случае сервер стоит внутри локалки и в случае его взлома врагу становится доступна вся локальная сеть со всеми её вкусненькими потрохами.
Anrikigai
14.10.2021 21:42Допустим, у фаервола помимо внешнего интерфейса есть еще два (DMZ и LAN). Понятно, что надо строить двухуровневую защиту и т.п. Но реальность такова, что даже в филиалах банков вполне себе ограничиваются одним FW.
И, если раньше действительно по указанному правилу открывался доступ только к web серверу в DMZ, то после случайного удаления этого объекта и глобальной маршрутизации наружу выставится вся ЛВС в том числе.
Поэтому я и говорю, что если серверы в ЛВС сидят за NAT (Hide NAT), это уменьшает риски в случае ошибки в правилах фаервола по сравнению с "сидят на глобально маршрутизируемых Ipv6 адресах"
jok40
14.10.2021 22:07+1Допустим, у фаервола помимо внешнего интерфейса есть еще два (DMZ и LAN).
Нет, не допустим. Так должна быть построена DMZ. Если это не так, то это уже не DMZ.Но реальность такова, что даже в филиалах банков вполне себе ограничиваются одним FW.
Одного правильно настроенного фаервола с несколькими интерфейсами вполне достаточно.
scarab
17.10.2021 00:26+1То, что Вы описываете - это упрощённый вариант. Классическая реализация DMZ предполагает два файрволла и цепочку:
Inet — FW1 — DMZ — FW2 — LAN.
В этом случае перестаёт быть уязвимым местом сам файрволл. Скажем, если это разные железки разных вендоров.
edo1h
18.10.2021 00:41NAT для IPv4 хоть объясним. А как вам такое: https://datatracker.ietf.org/doc/html/draft-mrw-behave-nat66-01
вот смотрите, у меня есть два аплинка и локалка.
«дедовская» схема с ipv4: хосты в локалке имеют серые адреса, роутер делает snat в адрес того аплинка, через котого уходит пакет.в случае с ipv6 можно обойтись без nat: я могу анонсировать два префикса в локалку, но в этом случае выбор префикса (читай аплинка) для каждого соединения будет осуществляться на клиентских устройствах, что может быть очень неудобно.
dartraiden
15.10.2021 03:28Компания МТС объявило о переходе на новый сетевой протокол ещё в июне 2017 г. Данная услуга доступна на территории большей части России, а с 20.04.2020 интернет по IPv6 предоставляется автоматически. Однако такое подключение будет содержать ограничения по well-known TCP/UDP портам, для того чтобы от них избавиться, нужно подключить услугу IPv6+.
Немного подробнее: МТС запустил вариант подключения с NAT64. Для его использования нужно поменять в свойствах подключения тип APN c IPv4v6 на IPv6. При этом телефон или модем получает только IPv6 адрес, и чтобы подключиться к сайтам без IPv6 адреса используется NAT64 (по IPv6 протоколу запрос уходит на шлюз оператора, который его уже NATит в IPv4, при этом IPv4 адресам соответствуют IPv6 адреса в определённом префиксе).
При этом, трафик не фильтруется: не работает ни операторский DPI, ни роскомнадзоровское ТСПУ.
MAXH0
15.10.2021 09:41Господа, а что у IPv6 с безопасностью? Он по прежнему сливает конечного пользователя по умолчанию и требует танцев с бубном для анонимности?
Darkhon
15.10.2021 11:09+1Для меня преимущество IPv6 на МТС было в том, что это даёт открытый порт наружу для всяких децентрализованных сетей типа I2P и Retroshare. Как известно, IPv4 нынче у провайдеров "серые", по крайней мере на 4G-модеме у меня всегда был адрес "за NAT". Выделенный IP можно взять только за дополнительную плату. Наличие же IPv6 на модеме сразу давало обход NAT.
dmitryvolochaev
15.10.2021 11:39Назовите мне хоть одного провайдера, предлагающего доступ по IPv6 для дома
plumbum
15.10.2021 12:07+1Дом.ру даёт IPv6 /64 сетку, правда, с динамическим адресом.
asukms
15.10.2021 15:50Теперь статическим. Нужно отключить в ЛК ipv6, и потом снова включить. Выдаст статику. но 64 мало, да...
GennPen
15.10.2021 17:19Статичный префикс выдает только при подключении статичного IPv4. Причем делают это довольно топорным способом. Выделяет в 2a03:1ac0::/32, далее идет префикс в зависимости от выданного IPv4, например для 123.45.67.89 будет префикс 2a03:1ac0:7b2d:4359::/64
dartraiden
15.10.2021 19:54+1Но даёт только при PPPoE-подключении. В то время как новых абонентов сразу подключают по IPoE, где IPv6 не предоставляется.
Manrus
15.10.2021 12:12Skynet в СПб предоставляет ipv6 в тестовом режиме
Incognito90
15.10.2021 13:07у них не далеко не во всех районах доступно..
я по двум адресам находящимся в разных частях города спрашивал, и там, и там было не доступно.. а список где доступен ipv6 они отказались предоставить.
andreymal
15.10.2021 13:49Можно немного поплакаюсь — техподдержка по телефону мне обещала, что IPv6 у скайнета якобы уже есть, а на практике я его уже четвёртый год жду :(
event1
15.10.2021 13:59+2Вычисление контрольной суммы пакета на сетевом оборудовании занимает определённое время, а вместе с Network Address Translation обсчёт производится дважды
Все эти подсчёты делаются прямо сетевыми картами уже миллион лет. Они влияют только на задержку (и то, не значительно), но не на пропускную способность
Так как количество IPv6 адресов огромно — 2^128, то отпадает нужда в NAT.
Нужда в NAT отпадает, а нужда в отслеживании соединений остаётся. Что дороже, подменить исходящий адрес или найти соединение в списке соединений?
К другим преимуществам нового стандарта следует отнести простоту конфигурации сети, так как в IPv6 поддерживается автоматическая настройка сетевого адреса.
Спорно. Дело в том, что маршрутизатор раздаёт адреса не просто так, а из подсети, которую он получил от маршрутизатора более высокого уровня. И это тоже надо настроить. Кроме того, через SLAAC нельзя указать альтернативный маршрутизатор. В общем, иногда DHCP проще. В мобильных сетях ситуация ещё интереснее: раз, два.
Ещё одна страшилка про исчерпание ipv4 адресов тоже не очень-то страшная. Уже 25 лет исчерпываются, да всё никак не исчерпаются. Особенно, с тех пор как пол-интернета хостится на амазоне, а вторая половина на cloudfare.
Это я не к тому, что IPv6 плохой или бесполезный. Это я к тому, что у медленного внедрения есть объективные причины. Провайдеры не дураки, они считают свои деньги и сравнивают доходы с расходами от тех или иных действий. Пока расходы превышают, ничего не произойдёт.
none7
16.10.2021 16:21Все эти подсчёты делаются прямо сетевыми картами уже миллион лет.
Но это всё равно требует вычислительных ресурсов, что для 100 Гбит/с существенны, даже если их считает специализированный микроконтроллер.
Что дороже, подменить исходящий адрес или найти соединение в списке соединений?
Так как, для подмены адреса и порта так же необходимо найти соединение, а затем ещё и пересчитать TCP и UDP чексуммы из за изменения номера порта, помимо IP-чексуммы, то очевидно, что подмена дороже. Даже NAT66 дешевле классического NAPT44.
Спорно. Дело в том, что маршрутизатор раздаёт адреса не просто так, а из подсети, которую он получил от маршрутизатора более высокого уровня
Но маршрутизатор может это сделать автоматически, на основе префикса полученного от маршрутизатора более высокого уровня и порядкого номера интерфейса. Возможно только делегирование и DNS потребуют некоторой настройки и скриптописания.
В общем, иногда DHCP проще.
DHCPv6 без SLAAC вообще не работает. Префикс локальной сети и адрес шлюза передаются только через SLAAC.
Уже 25 лет исчерпываются, да всё никак не исчерпаются
И поэтому любая мобилка может передать любой мобилке в мире файл любого размера (на самом деле нет).
event1
16.10.2021 17:46Так как, для подмены адреса и порта так же необходимо найти соединение, а затем ещё и пересчитать TCP и UDP чексуммы из за изменения номера порта, помимо IP-чексуммы, то очевидно, что подмена дороже. Даже NAT66 дешевле классического NAPT44.
Вы не правильно меня поняли. NAT состоит из двух частей: найти соединение и подменить адрес. Очевидно, что поиск соединения это более дорогая операция, чем собственно подмена адреса. Контрольные суммы пересчитываются сетевой картой и на пропускную способность не влияют
Но маршрутизатор может это сделать автоматически, на основе префикса полученного от маршрутизатора более высокого уровня и порядкого номера интерфейса.
Может. Только его надо настроить для этого. В линуксе, например, придётся написать скрипт.
И поэтому любая мобилка может передать любой мобилке в мире файл любого размера (на самом деле нет).
И очень хорошо. Вряд ли кому-то понравится, если любая мобилка пришлёт ему файл любого размера
wormball
21.10.2021 23:19А вот скажите чайнику, можно ли в своей домашней сети настроить только ipv6 и ходить на сайты как ipv6, так и ipv4? Если нельзя, то тогда понятно, почему его так долго внедрить не могут — кто ж будет настраивать два протокола, когда можно настроить один, и всё будет работать.
none7
22.10.2021 04:30Есть такая вещь как NAT64, который позволяет программам умеющим работать с IPv6, подключаться к серверам у которых в DNS не прописан ни один IPv6-адрес. Web-страничкам этого хватает за глаза. К сожалению программы, которые в принципе не умеют работать с IPv6 всё ещё пишутся. Вот им понадобиться дополнительный набор костылей, чтобы работать.
andreymal
ВКонтакте много лет назад успешно работал по IPv6, но его отключили, по утверждениям техподдержки, из-за спамеров
SergeiMinaev
А есть подробности? Не могу понять, как ipv6 мог помочь спамерам
andreymal
Поддержка отказалась мне рассказывать, типа чтобы не подсказывать спамерам ¯\_(ツ)_/¯
acc0unt
Назло спамерам отморозим уши. Браво, VK!
4aba
Как я понял у них были фейковые реги, брут аккаунтов, спам изза того что все блокировки завязано на ip, а у ipv6 адресов у ботов дофига, и проще отключить ipv6 чем думать как банить