Комментарии 127
vk.com, доступен только по IPv4
ВКонтакте много лет назад успешно работал по IPv6, но его отключили, по утверждениям техподдержки, из-за спамеров
А есть подробности? Не могу понять, как ipv6 мог помочь спамерам
Помню, как давным-давно вышел IPv6 с заголовками: "IPv4 скоро умрет", и вот прошло 10 лет, до сих пор умирает.
Я этот заголовок видел в 1997 году.
абсолютно уверен что в 2037 IPv4 будет еще существовать у большинства провайдеров. А во внутренних сетях - так еще с полвека не меньше.
Это все NAT животворящий его на плаву держит
К другим преимуществам нового стандарта (IPv6) следует отнести простоту конфигурации сети
Вот из за этой "простоты" настройки его и не юзают.
Дыр в своей сети понаделать - раз плюнуть, а профита для небольших сетей вообще никакого.
Причём настраивать придётся и IPv4 и IPv6 одновременно.
Это старая традиция в мире айти (на самом деле и не только здесь) что-то хоронить. Я вот скоро на пенсию выйду, а венду тоже все хоронят)
ipv6 крутая технология.
её конечно довольно сложно понять чисто теоретически. можно читать статьи, можно пытаться прикинуть что к чему пытаясь провести параллели с тем как всё в твоей лично сети устроено и как бы это было с ipv6, но всё равно самый крупный толчок ты получаешь начав что-то делать.
когда у меня появился ipv6 адрес от провайдера это стало отправной точкой чтобы подумать "так, ну вот адрес как бы уже есть, может попытаться уже сделать что-то?". и всё оказалось довольно просто и понятно и действительно удобно.
что меня больше всего поражает, это то, о чём почему-то никто не пишет во всех этих огромных статьях, но что знакомо каждому сетевику который делал хоть сколько-нибудь сложные сети. это то, как протокол грамотно выбирает исходных адрес при установке связи. каждый, кто пытался настроить сеть, когда на интерфейсе есть глобальный адрес, пара локальных и ещё впн, поймёт о чём я. в ipv4 есть адрес интерфейса с которого он будет выплёвывать все пакеты, и, чтобы заставить его правильно выбрать исходный айпишник, надо понаколотить всяких правил, чтобы пакеты в какой-нибудь туннель уходили откуда надо. в ipv6 это всё работает из коробки само собой. у меня сейчас на интерфейсе глобальный адрес (аналог внешнего айпишника), локальный адрес (что-то среднее между 127.0.0.1 и 192.168.0.0 - адреса которые существуют только между соседями и роутером, и никогда не выходят за роутер) и два немаршрутизируемых адреса (аналог 192.168.0.0 - два впн-а), и всё это работает вообще без всяких дополнительных настроек без всяких проблем. куда бы я ни коннектился, мой исходящих айпишник всегда тот, от которого до цели ближе всего по маске. вот это прямо крутая фишка ради которой я перевёл все свои внутренние соединения на ipv6, это прямо реально делает жизнь легче.
плюс по мелочи типа SLAAC, это такая недо-DHCP технология, когда роутер может объявлять себя роутером, и устройства в сети буду автоматически подхватывать нужные адреса и цепляться к этому роутеру. в сочетании с пунктом выше это делает ipv6 сети прямо практически магически рабочими. достаточно настроить роутер в сети и любое косое кривое неадекватное устройство прицепится и будет работать как надо.
Звучит интересно, но я все равно не понял преимуществ "для дома, для семьи".
Не для "простых" задач, а именно для продвинутых. Когда нужны "входящие", установить связь с какими-то другими своими ресурсами. Вот как увас - несколько интерфейсов, туннели куда-то...
Пример:
Есть дом (роутер, сетка, 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.
На сколько помню, из-того что читал про ipv6, по нынешним стандтам /64 подсеть неделимая..
т.е. в вашем случае вы должны получить от провайдера сеть больше чем /64, например /56 (на сколько помню именно /56 рекомендуется выдавать конечному абоненту) и разделить ее на сети по /64 для домашней сети/гостевого wifi/"серверной"..
У вас правильное направление мышления, но всё ещё закостенелое под "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, так чтобы всех было видно по именам.
Кстати, навели меня на мысль, что IPv6 действительно можно получить от Oracle Cloud через тот же wireguard (действительно поддерживает). И OCI выдает /56
Спасибо!
Да, причём в 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
Тогда еще вопрос:
Допустим, я получу от своего ISP (или OCI) блок IPv6, и сделаю на нем всю домашнюю инфраструктуру. Это блок же их будет. Если я потом перейду куда-то, по идее. надо будет все переделывать.
Я понимаю, что DNS и все такое. НО можно ли каким-то образом свой блок ухватить? Скажем, первая попавшаяся ссылка предлагает
Регистрация PI IPv6
• Консультация по получению IPv6
• Подготовка документов на получение
• Регистрация объектов в RIPE
• Взаимодействие с RIPE NCC5000.00RUB
Если это одноразово и на всю жизнь, можно подумать. Если же ежегодно так платить - нафиг.
По концепции не очень положено. В IPv6 все задумывалось так, что адресное пространство по возможности прибито географически, что облегчает агрегацию маршрутов.
А домашняя инфраструктура должна при подключении к другому провайдеру принять от него префикс, добавить свою часть и быстренько сменить адреса на всех нужных интерфейсах уже под нового оператора. А если нужно что постоянное — то оно DNS именем адресуется, где привязанный адрес тоже должен смениться при смене оператора.
С мобилками/телевизором проблем со сменой адресов не будет.
Интерфейс ESXi назначать динамически - ну ОК. Хотя серверам я и предпочитаю статику ставить. Как минимум, чтобы паение dhcp серевера их не рушило.
Но разбить новую сетку на кучу сегментов (и адреса, и DHCP пулы на них), обновить кучу интерфейсов не только на Микротике, но и на VyOS (на ESXi) - не знаю, как автоматически сделать. Потребует усилий
Нужность DHCP в IPv6 сетях заметно снижена. Всем этим железкам Route Advertisement от маршрутизатора и SLAAC не хватит, чтобы адрес получить? И никаких пулов настраивать не придется.
Хорошо, пусть это будет не 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?
Внешний адрес на маршрутизаторе тут должен интересовать только провайдера. Нам интересно, какую он нам сетку отдал.
Пусть это 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 -> префикс от нового оператора.
в конфиге входного маршрутизатора и в конфиге хоста виртуалок.
А ни хосты домашней сетки, ни виртуальные машины переконфигурировать не надо.
Это радует.
Тогда чтобы я уж точно правильно понял - Почему наш внешний адрес интересует только провайдера?
Типа он мне даст /56 именно бонусом для внешней сети, а для подключения к нему еще один адрес из другой подсети? И по идее может только им и ограничиться, а /56 не дать, это совсем отдельный вопрос, который ему надо задавать?
Тогда чтобы я уж точно правильно понял - Почему наш внешний адрес интересует только провайдера?
Потому что все сервисы, что должны быть доступны извне, вешаются на адреса /56. А то что на внешнем интерфейсе - пусть как хочет в соответствии с перестройкой топологии собственной сетки меняет, лишь бы эту /56 правильно маршрутизировал. Собственно, тот, что внешний - при известном умении и витиеватости мышления оператора может вообще 'серым' быть. Уж не знаю, для чего это понадобиться может. Или его может не быть вовсе, если технология подключения абонентского маршрутизатора - точка-точка, а не etherner-о подобная шина. Или другой вариант - перезд в рамках этого же оператора. Внешний адрес изменился (потому что выдается в соответствии с портом коммутатора или что-нибудь похожее), а /56 - так абоненту и пробрасывается.
Типа он мне даст /56 именно бонусом для внешней сети, а для подключения к нему еще один адрес из другой подсети? И по идее может только им и ограничиться, а /56 не дать, это совсем отдельный вопрос, который ему надо задавать?
Эта /56 нее должна быть бонусом. А должны выдаваться всегда. А те, кто ограничиваются /64 на внешний интерфейс - это какое-то бессмысленное недоразумение делают.
На чью таблицу нагрузка? У провайдера запись в таблице маршрутизации одна: такую-то /56 кидай-то в такой-то порт/в такой-то ONU/на такой-то адрес (который оператор знает и менять его так быстро ему смысла нет). И этот адрес не предназначен для того, чтобы его как-то абонент трогал.
А то что внутри этой /56 сервисы как попало прыгают - его это не особо волнует.
На чью таблицу нагрузка? У провайдера запись в таблице маршрутизации одна: такую-то /56 кидай-то в такой-то порт/в такой-то ONU/на такой-то адрес (который оператор знает и менять его так быстро ему смысла нет
ну, справедливости ради, обычно доступ к таблице маршрутизации кэшируется, и при ротации адресов всеми клиентами раз в миллисекунду нагрузка и правда вырастет.
Я все-таки этого аргумента не понимаю. Ну да, если таким образом ротировать — маршрутизаторам может поплохеть. Но вот из каких соображений оператор так делать будет?
Наоборот, в IPv6 как выдал префикс/адрес клиенту — так он время существования договора и использует. А маршрут хоть как-то меняется только если меняется железка/порт, куда абонент цепляется.
Ладно, если терминал мобильный (натуральный сотовый телефон), и он по базовым станциям скачет. Ну так у такого оператора и маршрутизаторы на такое рассчитаны by desigh. А для обычного стационарного доступа — оператор вроде как сам себе дополнительную головную боль придумывать не должен.
вы невнимательно читали, речь про то, что абонент может устроить мини-дос на сетевую инфраструктуру.
Как? Ну вот в примере выше 2001:db8:1234:5600::/56 выдали абоненту. Прибили к порту. Оператор вписал этот маршрут в свою железку. В результате при маршрутизации пакета вот только на эти биты и нужно смотреть, а остальные просто игнорируются и тупо копируются 'как есть'
Как абонент чем-то напрячь оператора может?
я могу ошибаться, с устройством роутеров можно сказать незнаком, поэтому можете считать, что это мои предоположения.
ходить каждый раз в таблицу маршрутизации дорого, поэтому есть кэширующая хэш-таблица, условно «хэш ip: интерфейс + mac».
и вот эта таблица имеет лимиты по размеру, 2^(128-56) записей в неё точно не поместится )
Оно же иерархическое. Грубо говоря, ближе к центру сети есть маршруты на /48 (их мало) + какие-то исключения от тех, кто переехал с оригинальной точки доступа.
На маршрутизаторах ближе к клиенту — уже /56.
Половина IPv6 сделана для того, чтобы было удобно так делить и маршрутизатору не нужно было на слишком много бит адреса смотреть.
Половина IPv6 сделана для того, чтобы было удобно так делить и маршрутизатору не нужно было на слишком много бит адреса смотреть.
а как тут ipv6 улучает ситуацию с сравнении с ipv4?
Битов в адресе больше, поэтому легче уровни иерархии адресов нарезать.
Самих адресов больше, поэтому от всяческой динамики выдачи адреса клиента можно отказаться, а делать вот так тупо, как я писал — прибить выдаваемый адрес/префикс к порту коммутатора прямо на этапе его установки и больше не дергаться.
Собственно, тот, что внешний - при известном умении и витиеватости мышления оператора может вообще 'серым' быть.
Точно, тут же было уже, что можно даже next hop делать "дальше", а не из той же подсети
Если это одноразово и на всю жизнь, можно подумать. Если же ежегодно так платить — нафиг.
нет, ежегодно тоже придётся платить, сумму лень искать.
плюс договариваться с провайдерами о bgp-пиринге, что для частного клиента малореально.
Я уже понял, что тут очень сильно все по другому. И мне надо сперва много чего изучить прежде, чем вопросы задавать :)
Сейчас, к примеру, 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 познакомиться, не представляю.
адреса ipv6 (точнее префиксы и т.п.) раздаются с помощью ra, так что вам нужен radvd.
когда проектировали ipv6 хотели избавиться от dhcp вовсе, но не получилось, через ra не все настройки можно раздавать, так что теперь имеем связку radvd+dhcpd )
Я ориентировался на
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;
}
В общем, в итоге все сделал через dnsmasq. И обычный dhcp, и для ipv6, и SLAAC для мобилолок (кто оба варианта понимает просто получают два IPv6 адреса).
И DNS резолвит для выданных адресов. Причем для разных подсетей с разными субдоменами (ну типа в отдельном VLAN резолвится на xx.lab.xx.xx)
B итоге через туннель wireguard из дома уходит по IPv6 на VPS и дальше в Интернет (ибо у домашнего провайдера IPv6 нет)
А так можно делать и в Windows и в Linux?
А не присоветуете статью или статьи, где был бы описан алгоритм селекции интерфейса в IPv6
и явно описаны допустимые ограничения при выборе next hop или default gateway?
Я сколько ни рылся, не могу найти внятного изложения хоть где-то.
О, спасибо за наводку!
Вчера как раз глянул, убедился, что возможность такая есть, но что где конкретно прописывать интуитивно не понятно было. На выходные отложил.
Кровавый энтерпрайз во всей красе.
Честно говоря, я вообще Oracle Cloud воспринимал как ориентированный на огромный энтерпрайз. Не жду, что он будет прикладывать усилия, чтобы было удобно частнику типа меня. Дал халяву - и молодец, воспользуюсь :)
А в огромном энтерпрайзе, вероятно, по их мнению, должны быть специально обученные их интерфейсу и идеологии люди.
Он не делится не технически. Он не делится организационно.
Best practice такой. Для понимания можно пройти курс (он супер короткий) от Ripe NCC скажем. https://academy.ripe.net/
Отпадёт большинство вопросов. Там и про размеры сетей когда и где применять. И как оно работает и так далее. Короче курс реально короткий. Ну пол часа чтения текста с картинками как максимум.
Оптика приходит в провайдерскую коробочку. Если даже ей и дадут публичный IP
Зачем провайдерскому свичу выдавать внешний адрес, это коммут, а не роутер.
хотя там по дороге еще 3 хопа на 172.16
Тоже не играет роли
Дома публичный IPv4 получить сложно.
Это конечно от провайдера зависит, но многие дают такую услугу (хотя зачастую за отдельные деньги. Конечно в ситуации когда провайдер один и такой услуги нет - это проблема
еще свой Mikrotik.
Ну тут, как говорится, мои полномочия всё =( только портфорвардить
Зачем провайдерскому свичу выдавать внешний адрес, это коммут, а не роутер.
Таки роутер. На внешнем интерфейсе у него 10.0.0.0, в сторону Микротика смотрит 192.168.1.0
Публичный адрес за деньги сравнимые с омими 80Mbps можно заказать (провайдер только один в районе), но проблемы с портфорвардингом сохранятся. Поэ
Потому и сделал вншений Nginx
Мой провайдер IPv6 пока не дает, но белый IPv4 позволил настроить 6to4 и даже с таким костылем все эти плюшки можно использовать.
vk.ru - не имеет ничего общего с vk.com :))) там конфеты продают
NAT спасает. Практически повсеместно используется NAT, к нему уже все так привыкли, что воспринимают его даже, как часть архитектуры безопасности ИТ-среды, хотя таковым он не является. Одной из сложностей перехода на IPv6 будет замена корпоративной NAT-адресации на новые стандарты с прямым TCP/IP соединением.
Не вижу в этом ничего сложного. Достаточно в роутере включить политику блокирования по умолчанию и все соединения по умолчанию будут резаться. Или есть такие отчаянные люди которые все входящие соединения по умолчанию разрешают?
Учитывая что людям раздают не адреса, а целые подсети, то с таким подходом и ipv6 может вскоре закончиться.
не может. Адрес ipv6 — 128 бит. Раздают подсети /64. Несложная математика подсказывает что существует 2^64 таких подсетей, что примерно равно 10^20. Людей на Земле, порядка 10^10. Выходит 10 миллиардов подсетей на лицо
Рекомендуют раздавать /56 подсети, либо вообще /48. Но многие провайдеры в упор не хотят раздавать подсети выше /64 и из-за этого приходится использовать сервисы типа Hurricane Electric, если нужно делать IPv6 для нескольких подсетей.
Это какая-то слишком в лоб математика. Организации обычно выделяют сеть /32. Так, что раздать она может немного более 4 млн /64. Это уже не миллиарды. Для небольшого оператора это нормально, но большому уже надо больше чем /32. Ну и вы куда-то выкинули зарезервированные адреса: fc00::/7, ff00::/8, fec0::/10, fe80::/10, 2002::/16, 2001::/32 - это только самые крупные.
Организации обычно выделяют сеть /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
В дополнение, сейчас выдают айпишники только из диапазона 2ххх.хххх
То есть 1/8 из возможных. если окажется, что сейчас раздали адресу неправильно - есть ещё 7 попыток.
Я конечно не понял зачем делать адрес длиной 128 бит, чтобы уж точно хватило всем? IPv6 штука конечно интересная, интересно было почитать разобраться, настроить. Так что теперь мне провайдер на мою скромненькую домашнюю сеточку из трех устройств выдает префикс аж /64, что ну так самую малость больше, чем все iv4 адреса в мире. Я конечно рад такой щедрости, но не особо понимаю действительно ли полезно с точки зрения реализации и использования протокола гонять все эти лишние байты.
Скорее всего выдали 64к адресов
И хороший и основательный учебник с теорией, немного устаревший но не сильно
sites.google.com/site/yartikhiy/home/ipv6book
Я поддержу, похоже на разбазаривание.
Когда я получил от провайдера /64, думал, сейчас побью домашнюю сеть на несколько сетей для удобства. Оказалось, что нет, из за EUI-64 это все не будет нормально работать. То есть, провайдер еще и пожадничал и нужно еще шире сетку, еще больше адресов уйдет в небытие.
как я понимаю, идея изначально была в том, чтобы отказаться от необходимости хранения сопоставление mac-адресов ip-адресам просто включив макадрес в ip-адрес. то есть адрес составлялся из префикса, полученного от провайдера, и макадреса, зашитого производителем оборудования.
потом дошло, что это дурацкая идея и сейчас фактически от использования макадресов в ip-адресах отказались.
Идея то не дурацкая, только как и в случае Wi-Fi, MAC-адрес лучше подделывать. И хорошо бы было вообще отказаться от коммутаторов в пользу маршрутизаторов с поддержкой ndp-proxy. В таком случае даже destination unreachable будет отсылаться сразу при выключении порта, а не улетать в blackhole. И петли не приведут к broadcast-шторму. И QoS в пределах своей сети будет работать. И мультикаст, который для IPv6 очень желателен, но практически нигде в коммутаторах нормально не реализован. И сканирования сети не приведёт к переполнению ndp-таблиц. IPv6 достаточно прост, чтобы сложность его обработки была не сильно выше сложности коммутации пакетов. Но производители железа не пошли на поводу у разработчиков стандарта, ибо им будет сложно потом обосновать почему маршрутизаторы стоят так дорого.
Даже не все московские провайдеры внедряют IPv6. Несколько лет назад разговаривал с QWERTY насчёт использования IPv6 для клиентского оборудования и они даже не планировали ничего делать. И сейчас ничего не поменялось.
Провайдеры, которые поддерживают - https://version6.ru/isp.
IPv6 - пример технологии, которая никому не нужна. Если за 10 лет на нее не перешли, то дальше точно не перейдут. Скорее всего будет что-то другое.
Если за 10 лет на нее не перешлиВообще-то не за 10, а за 25 с лишним: IPv6
Не нужна пока есть костыли в виде NAT для IPv4.
Лично мне дома проще открыть порт на нужную машину по IPv6, чем возиться с пробросом портов на IPv4.
NAT для IPv4 хоть объясним. А как вам такое: https://datatracker.ietf.org/doc/html/draft-mrw-behave-nat66-01
NAT - решает не только проблему нехватки адресов. Он одно из лучших средств изоляции корпоративной сети от Интернет. Поэтому в IPv6-to-IPv6 NAT нет ничего удивительного, IMHO, ИБ-шники его продавили.
Он одно из лучших средств изоляции корпоративной сети от Интернет.
Так а в чем проблема на роутере блокировать входящие подключения для подсети IPv6?
Преимущество NAT в сравнении с простой блокировкой в том, что:
1) скрывается структура внутренней сети;
2) немного увеличивается защищенность от "открытия сети в Интернет", возникающая в результате ошибок администрирования.
P.S. Я говорю про изоляцию NAT-ом "потребителей" трафика (пользовательские компы). Прятать за NAT сервера смысла не имеет, тут действительно лучше использовать роутер.
1) скрывается структура внутренней сети;
Как можно узнать структуру сети, если входящие запросы будут блокироваться?
Если исходящие не через NAT, а с "внутренних" IP, становится видна структура сети - какие есть подсети с клиентами... Если сервер полез за обновлением - серверные подсети.
Лучше удалять заголовки X-Forward-For, поставленный вашим прокси при покидании сети компании. Чистить заголовки цепочки серверов, чтобы снаружи был виден только финальный почтовик, а не цепочка Эксчейнджей...
Это все само по себе не смертельно. И полагаться исключительно на Security through obscurity - дело гиблое. Но зачем облегчать жизнь злоумышленнику?
NAT не имеет ничего общего с безопасностью. То, о чём вы говорите, это Stateful Firewall и Connection Tracking. Всё это ровно так же делается и в IPv6.
Это как сказать. Конечно, называть NAT "средством безопасности" странно.
Но сравните две конфигурации:
1) Сервер в DMZ, имеет публичный IP и от внешнего мира защищентолько фаерволом.
2) Сервер в ЛВС на приватном IP за Hide NAT и фаерволом
В первом случае одно неверное движение, и сервер окажется доступным из Интернета. Админ вполне может ошибиться.
Во втором случае, чтобы сервер оказался доступным из Интернета, надо не только "убрать правило, блокирующее подключения извне", но и выделить серверу публичный IP... Случайно такое сложно сотворить. Надо прицельно создававть для кого-то доступ и перепутать серверы.
Никакой разницы нет.
NAT для своей работы требует Connection Tracking чтобы помнить какие соединения "изнутри" были созданы.
Этот же механизм используется и в Stateful Firewall - который обычно включен вместе с NAT.
Если взять тот же Linux, то в iptables, упрощённо, будут правила:
Транслировать адреса из приватных в публичные (-j MASQUERADE / SNAT)
Обратно пропускать только пакеты, относящиеся к уже установленным соединениям (-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT)
Остальные входящие пакеты рубить (-P DROP)
В итоге в IPv6 мы просто убираем правило #1 SNAT/MASQUERADE и всё продолжает работать как раньше - входящие соединения извне на хосты в локалке дропаются.
Зачем вы упорно на технический аспект упираете? Нат - требует действий для того, что бы внутренний ресурс был доступен. Ipv6 - требует действий что бы внутренний ресурс был НЕ доступен.
В общем и целом обычно желательнее, что бы внутренний ресурс НЕ был доступен.
Вот и все.
Построение систем в которых возможность пользовательской ошибки меньше благодаря архитектуре - мне кажется азы понятные любому, потому что люди ВСЕГДА будет ошибаться.
Ipv6 и создавался то для другого, как раз что бы доступно было ВСЕ. А в реальности далеко не всем людям это нужно, вот и едет внедрение.. как едет.
Потому что люди не понимают что такое NAT/conntrack и как это работает вместе.
Если использовать просто NAT (без правил, которые отсекают пакеты, не относящиеся к установленным соединениям) - к тебе в локалку сможет залезть практически любой, просто отправив твоему роутеру пакет предназначенный для какого-нибудь 192.168.0.x
Ибо роутер он чтобы роутить пакеты - и он сроутит, согласно правилам файрволла и таблицам маршрутизации.
Так что это не безопасность, а её иллюзия. Поэтому во всех (нормальных) домашних роутерах есть нужные правила, которые это дело блокируют. И если убрать IPv4+NAT и заменить это IPv6 - ничего не поменяется.
Если использовать просто NAT (без правил, которые отсекают пакеты, не относящиеся к установленным соединениям) — к тебе в локалку сможет залезть практически любой, просто отправив твоему роутеру пакет предназначенный для какого-нибудь 192.168.0.x
небольшая ремарка: у большинства провайдеров сейчас клиенты сидят в раздельных сегментах l2, так что под «любой» на практике подходит только сам провайдер (ну или хакер, который проник в его внутренную сеть).
Во втором случае, чтобы сервер оказался доступным из Интернета, надо не только "убрать правило, блокирующее подключения извне"
Это какой-то немного странный firewall. В правильном это правило стоит всегда и убрать его нельзя. А добавляется как раз разрешающие.
Коль скоро мы тут в основном про домашние сетки говорим (по крайней меряе я), рассмотрим подключение типичного пользователя:
Воткнуть маршрутизатор
Прописать на внешнем интерфейсе адрес, что дал провайдер
При необходимости поправить адрес на внутреннем интерфейсе
Если не заработает, еще и включить NAT на внешнем интерефейсе.
Никаким ошибками не удастся легко и непринужденно выставить все домашние ресурсы наружу.
Скорее наоборот, для того, чтобы выставить какой-то внутренний сервер наружу, придется заморачиваться с Port Forwarding и т.п.
При наличии же глобально маршрутизируемых адресов во внутренней сети я уже не был бы спокоен и правила своего Микротика перепроверял бы тысячекратно.
Есть куча не самых маленьких компаний с таким же Микротиком, как у меня, вручную задающие правила его фаервола. Если же говорить об энтерпрайзе, там часто используются удобные управлялки с GUI, Web интерфейсом... При наличии правила типа Src: Internet / Dst: Web_server / Service: HTTPS / Accept вполне можно случайно удалить "Web_server". И во многих случаях значение в пустой яейке станет Any, открыв в случае глобально маршрутизируемых адресов всю внутреннюю сетку (в данном случае только по HTTPS, но это не принципиально).
Конечно, это не всегда так. Скажем, в последних версиях Check Point вместо Any станет None, и политика не установится. Так я и не говорю, что "с IPv6 мы все умрем". Но риски повышаются, как ни крути. От некоторых ошибок NAT защищает (снижает риск).
В контексте IPv6 именно домашние маршрутизаторы, что его умеют почти поголовно (у них, кажется, это в правилах сертификации какой-то вписано) как раз закрывают по умолчанию коннекты снаружи внутрь.
Mikrotik- ни разу не домашний. Так что проверяем, да.
А у ентерпрайзов всякие системы анализа вторжения просто истошно завопят (что, впрочем, не означает, что пользователь, а не безопасники это увидят) когда увидят прошедший коннект снаружи внутрь. Так что подобную ошибку быстро починять.
А у ентерпрайзов всякие системы анализа вторжения просто истошно завопят
Я бы не был столь оптимистичен. Скажем, применительно к филиалу банка, заметят скорее после того, как из этого филиала по сети начнет зараза расползаться.
В целом-то я, безусловно согласен. Если мне скажут "NAT - это средство безопасности", сам же и ухмыльнусь.
Допустим, у фаервола помимо внешнего интерфейса есть еще два (DMZ и LAN). Понятно, что надо строить двухуровневую защиту и т.п. Но реальность такова, что даже в филиалах банков вполне себе ограничиваются одним FW.
И, если раньше действительно по указанному правилу открывался доступ только к web серверу в DMZ, то после случайного удаления этого объекта и глобальной маршрутизации наружу выставится вся ЛВС в том числе.
Поэтому я и говорю, что если серверы в ЛВС сидят за NAT (Hide NAT), это уменьшает риски в случае ошибки в правилах фаервола по сравнению с "сидят на глобально маршрутизируемых Ipv6 адресах"
Допустим, у фаервола помимо внешнего интерфейса есть еще два (DMZ и LAN).Нет, не допустим. Так должна быть построена DMZ. Если это не так, то это уже не DMZ.
Но реальность такова, что даже в филиалах банков вполне себе ограничиваются одним FW.Одного правильно настроенного фаервола с несколькими интерфейсами вполне достаточно.
NAT для IPv4 хоть объясним. А как вам такое: https://datatracker.ietf.org/doc/html/draft-mrw-behave-nat66-01
вот смотрите, у меня есть два аплинка и локалка.
«дедовская» схема с ipv4: хосты в локалке имеют серые адреса, роутер делает snat в адрес того аплинка, через котого уходит пакет.
в случае с ipv6 можно обойтись без nat: я могу анонсировать два префикса в локалку, но в этом случае выбор префикса (читай аплинка) для каждого соединения будет осуществляться на клиентских устройствах, что может быть очень неудобно.
Компания МТС объявило о переходе на новый сетевой протокол ещё в июне 2017 г. Данная услуга доступна на территории большей части России, а с 20.04.2020 интернет по IPv6 предоставляется автоматически. Однако такое подключение будет содержать ограничения по well-known TCP/UDP портам, для того чтобы от них избавиться, нужно подключить услугу IPv6+.
Немного подробнее: МТС запустил вариант подключения с NAT64. Для его использования нужно поменять в свойствах подключения тип APN c IPv4v6 на IPv6. При этом телефон или модем получает только IPv6 адрес, и чтобы подключиться к сайтам без IPv6 адреса используется NAT64 (по IPv6 протоколу запрос уходит на шлюз оператора, который его уже NATит в IPv4, при этом IPv4 адресам соответствуют IPv6 адреса в определённом префиксе).
При этом, трафик не фильтруется: не работает ни операторский DPI, ни роскомнадзоровское ТСПУ.
Господа, а что у IPv6 с безопасностью? Он по прежнему сливает конечного пользователя по умолчанию и требует танцев с бубном для анонимности?
Для меня преимущество IPv6 на МТС было в том, что это даёт открытый порт наружу для всяких децентрализованных сетей типа I2P и Retroshare. Как известно, IPv4 нынче у провайдеров "серые", по крайней мере на 4G-модеме у меня всегда был адрес "за NAT". Выделенный IP можно взять только за дополнительную плату. Наличие же IPv6 на модеме сразу давало обход NAT.
Назовите мне хоть одного провайдера, предлагающего доступ по IPv6 для дома
Дом.ру даёт IPv6 /64 сетку, правда, с динамическим адресом.
Skynet в СПб предоставляет ipv6 в тестовом режиме
у них не далеко не во всех районах доступно..
я по двум адресам находящимся в разных частях города спрашивал, и там, и там было не доступно.. а список где доступен ipv6 они отказались предоставить.
Можно немного поплакаюсь — техподдержка по телефону мне обещала, что IPv6 у скайнета якобы уже есть, а на практике я его уже четвёртый год жду :(
Ростелек бывший онлайм в Москве выдаёт ipv6 уже лет 5
Вычисление контрольной суммы пакета на сетевом оборудовании занимает определённое время, а вместе с Network Address Translation обсчёт производится дважды
Все эти подсчёты делаются прямо сетевыми картами уже миллион лет. Они влияют только на задержку (и то, не значительно), но не на пропускную способность
Так как количество IPv6 адресов огромно — 2^128, то отпадает нужда в NAT.
Нужда в NAT отпадает, а нужда в отслеживании соединений остаётся. Что дороже, подменить исходящий адрес или найти соединение в списке соединений?
К другим преимуществам нового стандарта следует отнести простоту конфигурации сети, так как в IPv6 поддерживается автоматическая настройка сетевого адреса.
Спорно. Дело в том, что маршрутизатор раздаёт адреса не просто так, а из подсети, которую он получил от маршрутизатора более высокого уровня. И это тоже надо настроить. Кроме того, через SLAAC нельзя указать альтернативный маршрутизатор. В общем, иногда DHCP проще. В мобильных сетях ситуация ещё интереснее: раз, два.
Ещё одна страшилка про исчерпание ipv4 адресов тоже не очень-то страшная. Уже 25 лет исчерпываются, да всё никак не исчерпаются. Особенно, с тех пор как пол-интернета хостится на амазоне, а вторая половина на cloudfare.
Это я не к тому, что IPv6 плохой или бесполезный. Это я к тому, что у медленного внедрения есть объективные причины. Провайдеры не дураки, они считают свои деньги и сравнивают доходы с расходами от тех или иных действий. Пока расходы превышают, ничего не произойдёт.
Все эти подсчёты делаются прямо сетевыми картами уже миллион лет.
Но это всё равно требует вычислительных ресурсов, что для 100 Гбит/с существенны, даже если их считает специализированный микроконтроллер.
Что дороже, подменить исходящий адрес или найти соединение в списке соединений?
Так как, для подмены адреса и порта так же необходимо найти соединение, а затем ещё и пересчитать TCP и UDP чексуммы из за изменения номера порта, помимо IP-чексуммы, то очевидно, что подмена дороже. Даже NAT66 дешевле классического NAPT44.
Спорно. Дело в том, что маршрутизатор раздаёт адреса не просто так, а из подсети, которую он получил от маршрутизатора более высокого уровня
Но маршрутизатор может это сделать автоматически, на основе префикса полученного от маршрутизатора более высокого уровня и порядкого номера интерфейса. Возможно только делегирование и DNS потребуют некоторой настройки и скриптописания.
В общем, иногда DHCP проще.
DHCPv6 без SLAAC вообще не работает. Префикс локальной сети и адрес шлюза передаются только через SLAAC.
Уже 25 лет исчерпываются, да всё никак не исчерпаются
И поэтому любая мобилка может передать любой мобилке в мире файл любого размера (на самом деле нет).
Так как, для подмены адреса и порта так же необходимо найти соединение, а затем ещё и пересчитать TCP и UDP чексуммы из за изменения номера порта, помимо IP-чексуммы, то очевидно, что подмена дороже. Даже NAT66 дешевле классического NAPT44.
Вы не правильно меня поняли. NAT состоит из двух частей: найти соединение и подменить адрес. Очевидно, что поиск соединения это более дорогая операция, чем собственно подмена адреса. Контрольные суммы пересчитываются сетевой картой и на пропускную способность не влияют
Но маршрутизатор может это сделать автоматически, на основе префикса полученного от маршрутизатора более высокого уровня и порядкого номера интерфейса.
Может. Только его надо настроить для этого. В линуксе, например, придётся написать скрипт.
И поэтому любая мобилка может передать любой мобилке в мире файл любого размера (на самом деле нет).
И очень хорошо. Вряд ли кому-то понравится, если любая мобилка пришлёт ему файл любого размера
Есть такая вещь как NAT64, который позволяет программам умеющим работать с IPv6, подключаться к серверам у которых в DNS не прописан ни один IPv6-адрес. Web-страничкам этого хватает за глаза. К сожалению программы, которые в принципе не умеют работать с IPv6 всё ещё пишутся. Вот им понадобиться дополнительный набор костылей, чтобы работать.
Сквозь тернии к IPv6