Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 348
апокалибздец
Ну хоть не останемся в 2012-м без обещанного апокалипсиса
Вот мне и интересно, а не закончатся ли они случаем 21 декабря 2012?
У меня день рождения в этот день.
Нет, политика 'last /8' приведёт к крайне медленному исчерпанию резервов RIPE NCC. Зато приведёт к острой нехватке адресов у некоторых организаций.
Процесс исчерпания адресов будет очень плавным и очень неизбежным.
Процесс исчерпания адресов будет очень плавным и очень неизбежным.
Hапрашивается объяснение, что жрецы майя связывали с окончанием бактуна кардинальное обновление мироздания, а не его гибельВот вам и обновление мироздания.
Во-первых, у них не так уж и много адресов. Условно говоря, плюс пол-года год. Во-вторых уйдёт оно в американский сегмент, а не в европейский. В третьих — а с какой стати они должны отдавать эти адреса? Они их получали наравне с остальными — и я уверен, что они легко предъявят списки оборудования для каждого из выделенных IP-адресов. (одно из условий RIPE для выделения новых адресов — что ранее выделенные используются на оборудовании).
Там далеко не только IBM и Microsoft. Куча преимущественно американских корпораций плюс военные.
en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks
Ни за что не поверю, что хотя бы 1% всех некогда распределённых им адресов используется по прямому назначению и для общедоступных ресурсов, а не в качестве замены приватным.
en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks
Ни за что не поверю, что хотя бы 1% всех некогда распределённых им адресов используется по прямому назначению и для общедоступных ресурсов, а не в качестве замены приватным.
Полностью согласен.
В начале 90-е годы сети класса А раздавали налево и направо корпорациям, а сети В вообще никто не считал.
Потом спохватились, когда они понадобились тем, кому действительно нужно — провайдерам.
А половину адресов уже разбазарили…
Раскулачить буржуев и раздать страждущим — и наступит счастливая жизнь!
Ура, товарищи!
В начале 90-е годы сети класса А раздавали налево и направо корпорациям, а сети В вообще никто не считал.
Потом спохватились, когда они понадобились тем, кому действительно нужно — провайдерам.
А половину адресов уже разбазарили…
Раскулачить буржуев и раздать страждущим — и наступит счастливая жизнь!
Ура, товарищи!
Когда ещё только начинали говорить про смерть IPv4 слышал что 85% IP-шников просто банально проданы организациям, свободны и не используются. Напрашивается мысль: а так ли всё плохо? Просто коммерческие организации начнут торговать IP-адресами.
не используются != свободны.
Посмотрите на свой ip адрес. Если маска сети 255.255.255.0, то адрес .0 и .255 не используется. Но при этом, они не свободны. В мелкопровайдерском бизнесе раздача /29 — норма, а там степень «просёра» адресов составляет 25%.
Посмотрите на свой ip адрес. Если маска сети 255.255.255.0, то адрес .0 и .255 не используется. Но при этом, они не свободны. В мелкопровайдерском бизнесе раздача /29 — норма, а там степень «просёра» адресов составляет 25%.
Имел ввиду не используются, конечно.
Я о чём, в данный момент к примеру, HP принадлежат 2 сети класса «A»:
15.0.0.0/8
16.0.0.0/8
При том, что сотрудников всего 350 тысяч. Имеет ли смысл говорить о том, что вероятнее всего, более 30 млн IP-адресов тупо не используются?
Сверху выкладывали списки крупнейших компаний-владельцев подобных сетей. Тот же Ксерокс, к примеру. Зачем им 16 млн IP-адресов, если основное их направление — принтеры и копиры, а штат всего 136 тыс человек?
Не знаю как вы, а у меня складывается впечатление что крупнейшие компании держат такие диапазоны IP только с одной целью — продать их подороже когда закончатся IP-адреса.
Не могут 4 млрд IP-адресов просто взять и кончиться, скорее создают искусственный дефицит.
Я о чём, в данный момент к примеру, HP принадлежат 2 сети класса «A»:
15.0.0.0/8
16.0.0.0/8
При том, что сотрудников всего 350 тысяч. Имеет ли смысл говорить о том, что вероятнее всего, более 30 млн IP-адресов тупо не используются?
Сверху выкладывали списки крупнейших компаний-владельцев подобных сетей. Тот же Ксерокс, к примеру. Зачем им 16 млн IP-адресов, если основное их направление — принтеры и копиры, а штат всего 136 тыс человек?
Не знаю как вы, а у меня складывается впечатление что крупнейшие компании держат такие диапазоны IP только с одной целью — продать их подороже когда закончатся IP-адреса.
Не могут 4 млрд IP-адресов просто взять и кончиться, скорее создают искусственный дефицит.
А теперь рассказываю как эти адреса распределяются (это не факты, это пример того, что «число IP-адресов не равно числу узлов сети):
Допустим, у HP 30 филиалов. С учётом, что число филиалов может возрасти, мы зарезервируем один бит из номера сети и пять бит из подсети для номера филиала.
Каждый филиал получает, таким образом, сеть размера /12. Такие же сети получает IT-департамент для связи с внешним миром и прочих нужд типа веб-сайтов, центральных серверов и т.д.
Внутри филиала мы разделяем сети по кампусам. Мы полагаем, что в филиале не может быть больше 16 кампусов (если так, филиалу выделяется 2 и более филиальные сети). Таким образом, кампус получает сеть /16.
Внутри кампуса сеть делится 16 сетей (маска /20). Нулевая сеть уходит на внутренние management-интерфейсы оборудования, последняя сеть резервируется для временных коммуникаций. Каждому этажу назначается своя /20, которая делится по числу помещений, полагаем, что число помещений не больше 128. Таким образом, на каждое помещение выделяется /27 (то есть всего лишь 30 IP-адресов). А что там в бухгалтерии не 30 компьютеров, а всего 4, плюс два принтера, плюс пара резервных розеток — это никого не волнует.
Это нормальный numbering plan. Именно такие сейчас пишутся (я сам такой писал) для IPv6. Когда грамотность планирования инфраструктуры и агрегация значат больше, чем консолидация.
И никто против такого numbering plan'а не возразит. Особенно те, кто по крохам резал 10/8 по куче филиалов и матерился на нехватку битов.
Допустим, у HP 30 филиалов. С учётом, что число филиалов может возрасти, мы зарезервируем один бит из номера сети и пять бит из подсети для номера филиала.
Каждый филиал получает, таким образом, сеть размера /12. Такие же сети получает IT-департамент для связи с внешним миром и прочих нужд типа веб-сайтов, центральных серверов и т.д.
Внутри филиала мы разделяем сети по кампусам. Мы полагаем, что в филиале не может быть больше 16 кампусов (если так, филиалу выделяется 2 и более филиальные сети). Таким образом, кампус получает сеть /16.
Внутри кампуса сеть делится 16 сетей (маска /20). Нулевая сеть уходит на внутренние management-интерфейсы оборудования, последняя сеть резервируется для временных коммуникаций. Каждому этажу назначается своя /20, которая делится по числу помещений, полагаем, что число помещений не больше 128. Таким образом, на каждое помещение выделяется /27 (то есть всего лишь 30 IP-адресов). А что там в бухгалтерии не 30 компьютеров, а всего 4, плюс два принтера, плюс пара резервных розеток — это никого не волнует.
Это нормальный numbering plan. Именно такие сейчас пишутся (я сам такой писал) для IPv6. Когда грамотность планирования инфраструктуры и агрегация значат больше, чем консолидация.
И никто против такого numbering plan'а не возразит. Особенно те, кто по крохам резал 10/8 по куче филиалов и матерился на нехватку битов.
План хороший, конечно. Но вот смысл всем железкам в огромной организации иметь белые адреса? Никакого!
Что еще более обидно — таки оно в таком виде и не используется. А куда используется — хрен знает.
Вот у меня в относительно крупной организации на мою подсеть было выделено два блока /24. Пару лет назад меня урезали до одного /25. С одной стороны мне пофик, у меня внешних адресов надо штук 30, если по-хорошему. С другой — куда и зачем ушло почти 400 адресов я не знаю. Внутри все сети серые. белые адреса нужны только внешним серверам и столько их явно не надо (учитывая, что у компании их таки было много, не зря мне изначально 500 адресов отвалили).
Так что раскулачивать крупные компании таки можно. Возможно, имеет смысл выделить еще одну сеть /8 под серые адреса. Но как подумаешь сколько всего для этого надо переделать (переписать RFC, переписать весь софт, переписать все конфиги) — проще перейти на IPv6.
Что еще более обидно — таки оно в таком виде и не используется. А куда используется — хрен знает.
Вот у меня в относительно крупной организации на мою подсеть было выделено два блока /24. Пару лет назад меня урезали до одного /25. С одной стороны мне пофик, у меня внешних адресов надо штук 30, если по-хорошему. С другой — куда и зачем ушло почти 400 адресов я не знаю. Внутри все сети серые. белые адреса нужны только внешним серверам и столько их явно не надо (учитывая, что у компании их таки было много, не зря мне изначально 500 адресов отвалили).
Так что раскулачивать крупные компании таки можно. Возможно, имеет смысл выделить еще одну сеть /8 под серые адреса. Но как подумаешь сколько всего для этого надо переделать (переписать RFC, переписать весь софт, переписать все конфиги) — проще перейти на IPv6.
Что значит «белые адреса»? Организации были выделены блоки IP-адресов для нумерации устройств в сети, подключенной к Интернет. Что они и делают.
А вам наты и серые IP, которые ломают коннективити в сети, мозг съели.
Ничего, несколько лет реабилитации с IPv6 и вы вполне поймёте, что в интернете все адреса должны быть белыми.
А вам наты и серые IP, которые ломают коннективити в сети, мозг съели.
Ничего, несколько лет реабилитации с IPv6 и вы вполне поймёте, что в интернете все адреса должны быть белыми.
Так в том-то и дело, что НЕ делают. Организации, которым хватает «белых» адресов на все устройства в сети все равно используют «серые» адреса. И не просто используют между делом, а 95% всех устройств таки живут с серыми адресами. А для выхода в Интернет (который большому количеству устройств все равно не нужен) таки используют nat. Даже если нет проблем с белыми адресами.
Это последствия консолидации. Если бы не NAT'ы, адерса были бы исчерпаны (не помню цифру, но где-то к 2000ому, кажется).
В случае с ipv6 никаких серых адресов не будет. Будут link-local и global. site-local выпилили из стандарта, к счастью.
Идеей интернета была возможность связаться «каждого с каждым». Можете ли вы сидя за натом связаться с своей рабочей станцией на работе? Нет, нужно городить стопятьсот выпыэнов. И это зло, которое сдерживает адекватную IP-телефонию, кучу других сервисов, которые могли бы рассчитывать на возможность адекватного callback на клиента, а не гадания «туда ли я попаду?».
Собственно, задумайтесь: все IM-протоколы держат TCP-соединение. Всегда. Нахрена, спрашивается? Потому что иначе сервер не может сказать клиенту, что пришло новое сообщение.
А ведь могла бы быть куда более культурная схема — когда сервер обращается к клиенту с новым сообщением. Без «TCP с keepalive'ами».
В случае с ipv6 никаких серых адресов не будет. Будут link-local и global. site-local выпилили из стандарта, к счастью.
Идеей интернета была возможность связаться «каждого с каждым». Можете ли вы сидя за натом связаться с своей рабочей станцией на работе? Нет, нужно городить стопятьсот выпыэнов. И это зло, которое сдерживает адекватную IP-телефонию, кучу других сервисов, которые могли бы рассчитывать на возможность адекватного callback на клиента, а не гадания «туда ли я попаду?».
Собственно, задумайтесь: все IM-протоколы держат TCP-соединение. Всегда. Нахрена, спрашивается? Потому что иначе сервер не может сказать клиенту, что пришло новое сообщение.
А ведь могла бы быть куда более культурная схема — когда сервер обращается к клиенту с новым сообщением. Без «TCP с keepalive'ами».
Будут серые адреса, называются они unique-local (fc00::/7), их ввели вместо site-local.
tools.ietf.org/html/rfc4193
Префикс будет псевдо рандомный для того, чтобы в случае extranet VPN не было проблем с совпадающими префиксами.
tools.ietf.org/html/rfc4193
Префикс будет псевдо рандомный для того, чтобы в случае extranet VPN не было проблем с совпадающими префиксами.
Будут серые адреса, называются они unique-local (fc00::/7), их ввели вместо site-local.
Их теоретически не предполагается NATить. На данный момент не существует стандарта по трансляции v6 адреса в v6 адрес.
Что, конечно, не значит, что NAT 6to6 не будет поддерживаться всем сетевым железом…
Я нигде и не говорил, что их будут NATить.
Просто если у вас все адреса — глобальные, то как между собой будут общаться устройства в домашней LAN? Через домашний роутер всегда? Это диапазон играет ту же роль, что и site-local или Private сети в IPv4.
А NAT не имеет смысла для IPv6, потому что интерфейсу по стандарту разрешено иметь несколько IPv6 адресов одновременно.
Просто если у вас все адреса — глобальные, то как между собой будут общаться устройства в домашней LAN? Через домашний роутер всегда? Это диапазон играет ту же роль, что и site-local или Private сети в IPv4.
А NAT не имеет смысла для IPv6, потому что интерфейсу по стандарту разрешено иметь несколько IPv6 адресов одновременно.
как между собой будут общаться устройства в домашней LAN?
Не понял, в чем проблема.
Для общения в пределах VLAN предполагается всегда использовать link-local адреса, и роутер при этом вообще никак не задействован, его может и не быть вовсе.
А роутить между VLANами — какая разница, какая там будет сеть?
Ничто не мешает вам и сейчас использовать дома 1.1.1.0/24 вместо 192.168.0.0/24. Просто это засорит вам чакры, а также если вдруг в интернете кто-то задействует эту сеть, то для вас она будет недоступной.
интерфейсу по стандарту разрешено иметь несколько IPv6 адресов одновременно.
Да и IPv4 такое никто не запрещал, любая ОС позволяет назначить адаптеру хоть сколько адресов.
Если у вас организация и LAN, вы хотите контролирумую раздачу адресов по DHCP. И вы хотите знать, какому имени хоста какой IPv6 адрес соответствует. И вы хотите дипазон, который вы контролируете.
Link-local вы вообще не можете задать.
Я вообще даже в своей домашней IPv6 сети хочу иметь unique-local адреса, чтобы знать, где у меня NAS, где сетевой МФУ и у какого компьютера и гаджета дома какой IPv6 адрес.
В IPv4 нет возможности выдать больше одного IPv4 адреса по DHCP. То есть можно ручками можно рисовать secondary. но вы теряете возможность автоматизированного управления.
Link-local вы вообще не можете задать.
Я вообще даже в своей домашней IPv6 сети хочу иметь unique-local адреса, чтобы знать, где у меня NAS, где сетевой МФУ и у какого компьютера и гаджета дома какой IPv6 адрес.
В IPv4 нет возможности выдать больше одного IPv4 адреса по DHCP. То есть можно ручками можно рисовать secondary. но вы теряете возможность автоматизированного управления.
Если у вас организация и LAN, вы хотите контролирумую раздачу адресов по DHCP.
DHCP — протокол класса «мне плевать, какая машина какой адрес получит». Можно делать резервации, но лучше не делать. В моей организации неважно, какой у кого IP адрес, в том числе адреса принтеров и прочего. Во всех известных мне организациях — аналогично.
В IPv6 DHCP нужен лишь по одной причине: иных способов выдать компьютеру адреса DNS серверов почему-то не придумали (и меня это удивляет: почему нельзя было включить соответствующее поле в RA?). В отдельных случаях нужно дать и другие опции, но как правило обходятся без них.
Я вообще даже в своей домашней IPv6 сети хочу иметь unique-local адреса, чтобы знать, где у меня NAS, где сетевой МФУ и у какого компьютера и гаджета дома какой IPv6 адрес.
Необоснованные хотелки. За исключением одного случая — когда нужно проковырять дырку в файрволе для доступа снаружи. В случае корпоративной сети такая задача исключена, все доступные снаружи машины находятся в DMZ и, разумеется, имеют статически заданные адреса.
И почему именно unique-local? Домашнему пользователю примерно всегда будут давать /64 сеть, вполне себе глобально маршрутизируемую. У меня такая уже есть — бесплатно, от Hurricane Electric. Адресного пространства там вдоволь, развлекайтесь как хотите — хоть по SA, хоть по DHCP, хоть статикой, неважно.
В IPv4 нет возможности выдать больше одного IPv4 адреса по DHCP.
В IPv6 тоже.
Еще раз: в стандарте IPv6 предполагается, что все общение между хостами в одном широковещательном домене будет идти по link-local адресам. Не вижу смысла отказываться от такого.
Имхо же было расширение, позволяющее в RA включить данные о DNS.
Не видел. Везде говорят «хочешь дать клиентам DNS? Подымай DHCP». Причем DHCPv6, если мне память не изменяет, может выдавать клиентам исключительно одну опцию, адреса при этом не трогая.
Есть такое расширение, но на нем свет клином не сошелся. DHCP передает кучу другой полезной информации типа — имени домена, адреса SIP сервера, адреса шлюза и прочая.
RA полезен, но он кроме IA_NA и DNS ничего не передает.
А если у вас абоненты с маршрутизаторами, то там /64 или /128 не обойдешься, нужно делегировать префикс. А это делается только через DHCP опцию IA_PD.
RA полезен, но он кроме IA_NA и DNS ничего не передает.
А если у вас абоненты с маршрутизаторами, то там /64 или /128 не обойдешься, нужно делегировать префикс. А это делается только через DHCP опцию IA_PD.
1. DHCP расшифровывается как Dynamic Host Configuration Protocol. Именно поэтому IETF решила не плодить сущностей и оставить все сверх анонса префиксов в DHCP
2. Хотелка вполне обоснованная, пусть даже у вас таких задач нет — в жизни они встречаются. И это — удобно. Тем более, что когда у вас вживую будет IPv6 адресация в сети, вам очень захочется привести адреса к человеческому и читаемому виду. Link-local имеют неудобоваримый suffix сляпанный из MAC адреса. А DHCP позволяет выдавать адреса линейно, начиная с prefix + ::0001.
3. Абонентам (если мы говорим про операторский бизнес, а не про компы) выдают /56, для того, чтобы вы могли иметь несколько подсетей в своем домене (не говорю про всякий геморрой типа 4o6 решений)
4. /64 выдается хосту или его конкретному интерфейсу.
2. Хотелка вполне обоснованная, пусть даже у вас таких задач нет — в жизни они встречаются. И это — удобно. Тем более, что когда у вас вживую будет IPv6 адресация в сети, вам очень захочется привести адреса к человеческому и читаемому виду. Link-local имеют неудобоваримый suffix сляпанный из MAC адреса. А DHCP позволяет выдавать адреса линейно, начиная с prefix + ::0001.
3. Абонентам (если мы говорим про операторский бизнес, а не про компы) выдают /56, для того, чтобы вы могли иметь несколько подсетей в своем домене (не говорю про всякий геморрой типа 4o6 решений)
4. /64 выдается хосту или его конкретному интерфейсу.
DHCP расшифровывается как Dynamic Host Configuration Protocol. Именно поэтому IETF решила не плодить сущностей и оставить все сверх анонса префиксов в DHCP
Но ведь теперь роутер сам сообщает клиенту, в какую тот попал сеть. Клиент сам назначает себе адрес. Половина задачи конфигурирования клиента уже выполнено. Так почему бы не добавить в RA указание на DNS сервера (критический параметр) и сделать DHCP ненужным в большинстве случаев?
Можно назначать клиентам адреса по DHCPv6, но зачем?
Хотелка вполне обоснованная
Не увидел, чем таким она обоснованная.
вам очень захочется привести адреса к человеческому и читаемому виду.
Зачем?
Link-local имеют неудобоваримый suffix сляпанный из MAC адреса.
Еще раз: link local является штукой обязательной. Любой v6 интерфейс ОБЯЗАН иметь link-local адрес. И этот адрес не может маршрутизироваться за пределы сети.
DHCP позволяет выдавать адреса линейно, начиная с prefix + ::0001.
Еще раз: DHCP принято использовать там, где абсолютно неважно, какой адрес схватит клиент. Резервация — костыль.
Абонентам (если мы говорим про операторский бизнес, а не про компы) выдают /56, для того, чтобы вы могли иметь несколько подсетей в своем домене
На здоровье.
/64 выдается хосту или его конкретному интерфейсу.
Хосту или его интерфейсу можно выдать хоть /126. В пределах выделенного вышестоящим оператором блока владелец — полный хозяин. Он может задействовать EUI-64, а может и нет.
Еще раз. Link-local имеет scope не выходящий за рамки link.
link-local вы не знаете. Он просто есть. Вы будете читать arp таблицу компов? Переписывать MAC адреса?
А если у вас несколько линков или несколько LAN, которые вы хотите единообразно администрировать?
И если вы гарантированно не хотите утечки внутренного обмена данными в интернет?
Inter-LAN/VLAN маршрутизацию на link-local вы не сделаете.
unique-local — это отличное решение проблемы:
1. Диапазон известный
2. Его легко фильтровать на border маршрутизаторах не допуская утечки
link-local вы не знаете. Он просто есть. Вы будете читать arp таблицу компов? Переписывать MAC адреса?
А если у вас несколько линков или несколько LAN, которые вы хотите единообразно администрировать?
И если вы гарантированно не хотите утечки внутренного обмена данными в интернет?
Inter-LAN/VLAN маршрутизацию на link-local вы не сделаете.
unique-local — это отличное решение проблемы:
1. Диапазон известный
2. Его легко фильтровать на border маршрутизаторах не допуская утечки
link-local вы не знаете.
Я и глобальный знать не должен.
Но ipconfig подскажет.
А если у вас несколько линков или несколько LAN, которые вы хотите единообразно администрировать?
Не понял вопрос. Сформулируйте пожалуйста поточнее. И скажите — с какой стати меня должно заботить, у какого из внутренних компьютеров какой будет адрес (разумеется, в пределах заданной мной подсети)?
И если вы гарантированно не хотите утечки внутренного обмена данными в интернет?
А файрволы на что?
Вы ведь понимаете, что NAT ни в коей мере не является средством безопасности, верно? Максимум — сокрытия адресации, не более того.
Inter-LAN/VLAN маршрутизацию на link-local вы не сделаете.
Конечно.
Допустим, я отжал себе PI блок /48. Что конкретно помешает мне разбить его на массу более мелких блоков и распихать их по разным VLANам?
Я просто честно не понимаю, что вы хотите сказать…
unique-local — это отличное решение проблемы:
1. Диапазон известный
2. Его легко фильтровать на border маршрутизаторах не допуская утечки
Свой собственный блок еще проще зафильтровать на периметре: он один. Но в каком смысле зафильтровать? Не принимать анонсы его снаружи?
DHCP принято использовать там, где абсолютно неважно, какой адрес схватит клиент
У нас DHCP выдаёт фиксированный адрес (соответствующий MAC).
Иначе как реализовывать хотелки начальства типа «А закрой (открой) ЭТОМУ компу в отделе полный доступ в инет»
Неизвестным MAC-ам выдаётся адрес из пула, который никуда не имеет доступ.
У нас DHCP выдаёт фиксированный адрес (соответствующий MAC).
На IPv4? Все скопы состоят из резерваций? Охренеть дизайн…
Иначе как реализовывать хотелки начальства типа «А закрой (открой) ЭТОМУ компу в отделе полный доступ в инет»
Никак — это глупая хотелка. Доступы должны выдаваться-отбираться не компьютерам, а пользователям.
На IPv4? Все скопы состоят из резерваций? Охренеть дизайн…
Конечно, v4. Я сейчас не скажу точное название технологии, но DHCP-сервер один, а свичи умеют его как бы проксировать в сети отделов.
Доступы должны выдаваться-отбираться не компьютерам, а пользователям.
И как это сделать, если клиенты — Windows, а шлюз — FreeBSD либо RouterOS?
DHCP-сервер один, а свичи умеют его как бы проксировать в сети отделов.
Все так делают.
(хотя обычно серверов все-таки две штуки ставят)
И как это сделать, если клиенты — Windows, а шлюз — FreeBSD либо RouterOS?
Вопрос неправильный. Правильный вопрос — «что поставить, чтобы оно заработало как надо». Вариантов много. Для HTTP без вариантов NTLM аутентификация, по остальным протоколам у всех свое придумано. Хотя в случае подавляющего большинства пользователей других протоколов не потребуется.
Подход «у меня есть две чайные ложки и тапки, как мне используя все это открыть банку килек?» малость ущербен :)
Значит, примерно то на то и выходит.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
http-прокси привязывать к IP легче, чем к NTLM.
Потому что каждый второй автор опен-сорс мнит себя супер-кодером и http-стек делает сам на сокетах, вместо вызова неправославного WinInet.DLL. в итоге, если поддержка прокси и есть, то либо basic, либо md5 digest.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
http-прокси привязывать к IP легче, чем к NTLM.
Потому что каждый второй автор опен-сорс мнит себя супер-кодером и http-стек делает сам на сокетах, вместо вызова неправославного WinInet.DLL. в итоге, если поддержка прокси и есть, то либо basic, либо md5 digest.
Юс-кейсы типа «дружбану Васе надо открыть Квейк и Старкрафт» приводят к тому, что потребуется-таки фиксировать его IP в DHCP
Поставить нормальный прокси/файрвол — и не придется фиксировать IP пользователей в DHCP.
http-прокси привязывать к IP легче, чем к NTLM
Нет.
каждый второй автор опен-сорс
Вывод — использовать нормальный софт, а не наколенные поделки. У компании должна быть выработана политика, в которой перечислены разрешенные к употреблению приложения.
Всегда есть вариант SOCKS proxy клиента, который прозрачно для конечного приложения перенаправит любой трафик на сервер, да еще и аутентифицируется доменной УЗ. Есть варианты, связанные с агентом на компьютере, который будет сообщать файрволу «сейчас за таким-то IP адресом сидит Вася Пупкин», и файрвол в зависимости от этого настроит правила для IP адреса компьютера. Вариантов полно. И наверняка многие можно даже на опенсорсе настроить.
У компании должна быть выработана политика, в которой перечислены разрешенные к употреблению приложения.
Политика вырабатывается не админом, а спускается сверху.
Есть установка делать хорошо работнику, а не превращать рабочее место в тюрьму, особенно когда ничего секретного нет. Оплата за качество и количество сделанной работы, плюс комфорт (всегда можно отвлечься и отдохнуть) делают чудеса: юзеры не отсиживают с 9 до 18 и галопом по звонку домой, а могут без напряга и до 22 поработать. В результате все в выигрыше.
Вариантов полно
Не понимаю, в чём зло фиксированных адресов, что вы готовы столько костылей нагородить в их защиту. При заведении рабочео места просто адрес берётся из соответствующего диапазона, который везде прописан для какой-то политики и всё. Единственный минус, когда за компом могут работать в разные смены, но как правило политика для таких юзеров общая (а если нет, дешевле отдельный комп поставить, и работнику будет комфортнее)
Политика вырабатывается не админом, а спускается сверху.
Политика вырабатывается руководством IT и IT Security.
Есть установка делать хорошо работнику, а не превращать рабочее место в тюрьму
Отлично — работник может залогиниться на любом компьютере и получить одни и те же права. Причем тут тюрьма?
Не понимаю, в чём зло фиксированных адресов, что вы готовы столько костылей нагородить в их защиту.
А зачем тогда вообще DHCP?
И какие еще костыли? Есть задача: пользователю (человеку) предоставить определенные права. Правильное решение — назначить права его учетке. Костыль — работать на уровне IP адресов. Это просто нелогично.
Единственный минус, когда за компом могут работать в разные сменыАга. А еще пользователь может сесть за чужой компьютер по какой-либо причине. И много других сценариев. Работа на уровне IPшников добавляет массу головной боли и убирает всякую гибкость.
В моей компании нет резерваций в DHCP пулах. Совсем нет. Неважно, какой адрес схватит компьютер, принтер и т.д. Это называется «грамотный дизайн».
Отлично — работник может залогиниться на любом компьютере и получить одни и те же права. Причем тут тюрьма?
И какие еще костыли? Есть задача: пользователю (человеку) предоставить определенные права. Правильное решение — назначить права его учетке. Костыль — работать на уровне IP адресов. Это просто нелогично.Я не спорю, что правильная аутентификация — по учётке. На внутренних сервисах (Exchange, Sharepoint) так и есть. Но для доступа в сеть из зоопарка кривых программ (настройте-ка uTorrent по NTLM) фильтр по IP подходящий компромис.
А зачем тогда вообще DHCP?Наверное, чтобы не бегать по машинам, переконфигурируя интерфейс, если внезапно PDC и DNS перенесли в другую сеть.
а? что? торренты? на работе? торренты на работе идут лесом, да.
Кроме особо выделенных случаев.
Кроме особо выделенных случаев.
uTorrent по NTLM
Я не ослышался?
ок, пусть будет не торрент.
Чисто по работе. Есть такие тётеньки гуманитарные — контент-менеджеры, и они хотят заливать картинки по FTP на хостинг. Про SOCKS они слышать не хотят, админу тоже нежелательно локально что-то настраивать. Поэтому политика по IP
Чисто по работе. Есть такие тётеньки гуманитарные — контент-менеджеры, и они хотят заливать картинки по FTP на хостинг. Про SOCKS они слышать не хотят, админу тоже нежелательно локально что-то настраивать. Поэтому политика по IP
Есть такие тётеньки гуманитарные — контент-менеджеры, и они хотят заливать картинки по FTP на хостинг.
Как ни странно, любой файрвол умеет аутентифицировать не только HTTP, но и FTP. И NTLM везде подерживается для него.
Про SOCKS они слышать не хотят
Администратору должно быть плевать на мнение пользователей по поводу дизайна инфраструктуры. Как хочет, так и делает. Пользователь тут априори некомпетентен.
SOCKS — штука прозрачная.
Как ни странно, любой файрвол умеет аутентифицировать не только HTTP, но и FTP. И NTLM везде подерживается для него.
Вообще для меня новость. Не подскажете, какой RFC регламентирует применение NTLM в FTP-прокси?
SOCKS — штука прозрачная.
Вообще-то, Socks это протокол.
Видимо подразумевается какое-то решение типа sockscap (проприетарное, x86-only) может прозрачно заставить некоторые tcp-приложения юзать socks-прокси (и то, если протокол требует несколько согласованных tcp-соединений, как ftp в активном режиме, работать не будет)
Не подскажете, какой RFC регламентирует применение NTLM в FTP-прокси?
Разумеется, понятия не имею.
Вообще-то, Socks это протокол.
Это отменяет тот факт, что транспорт данных приложения поверх данного протокола может происходить прозрачно для приложения?
Видимо подразумевается какое-то решение типа sockscap (проприетарное, x86-only) может прозрачно заставить некоторые tcp-приложения юзать socks-прокси (и то, если протокол требует несколько согласованных tcp-соединений, как ftp в активном режиме, работать не будет)
По опыту, 100% проверенных приложений работали либо посредством похожей программы, либо заданием настроек SOCKS в самом приложении.
Как ни странно, любой файрвол умеет аутентифицировать не только HTTP, но и FTP. И NTLM везде подерживается для него.
Стоп-стоп. Firewall или Proxy?
Firewall ничего не может аутентифицировать, потому что в трафике ftp-протокола нет аутентифицирующей информации (там логин на удалённый хост).
С заходом на ftp в IE через прокси у меня был такой опыт: можно скачивать, но нельзя закачивать. Браузер кидает в проксю обычный HTTP GET но с ftp-шным url-ом (HFTP)
Следовательно, полноценная работа контент-менеджера с ftp через http-прокси с NTLM-авторизацией невозможна
Стоп-стоп. Firewall или Proxy?
habrahabr.ru/post/151518/#comment_5142094
Следовательно, полноценная работа контент-менеджера с ftp через http-прокси с NTLM-авторизацией невозможна
supportforums.cisco.com/thread/2050857
1) Ну как бы Microsoft не называл свой продукт «проксифаирволом», а проксирование и firewall — это разные технологии (firewall не модифицирует трафик, он только запрещает/разрешает), нежелательно смешивать их в одну кучу, иначе мы друг друга не поймём
2) Вот оно как. Теперь я понял, почему у меня не upload работал. Дело в том, что https-прокси это фактически socks, т.е. проксирует любой tcp-коннект. Чтобы юзеры не использовали его не по назначению для другого софта, админ запретил все порты для https, кроме 443.
2) Вот оно как. Теперь я понял, почему у меня не upload работал. Дело в том, что https-прокси это фактически socks, т.е. проксирует любой tcp-коннект. Чтобы юзеры не использовали его не по назначению для другого софта, админ запретил все порты для https, кроме 443.
Если нашлись деньги на Exchange с Sharepoint и управляемые коммутаторы, то почему не поставить TMG?
Кроме авторизации на уровне пользователей и приложений, сможете проверять трафик антивирусом и мониторить SSL. Всяко лучше костыля с резервацией.
Кроме авторизации на уровне пользователей и приложений, сможете проверять трафик антивирусом и мониторить SSL. Всяко лучше костыля с резервацией.
Несколько лет назад, когда были квоты у работника на кол-во трафика, не смогли настроить квоты в TMG
А сейчас то же самое с пайпами.
На unix-like роутерах легко давать правила типа «эта группа (ip-адресов) в этом пайпе и в сумме у них 1 мегабит», «а каждый юзер из это группы — по 2 мбита»
На unix-like роутерах легко давать правила типа «эта группа (ip-адресов) в этом пайпе и в сумме у них 1 мегабит», «а каждый юзер из это группы — по 2 мбита»
На unix-like роутерах легко давать правила типа «эта группа (ip-адресов) в этом пайпе и в сумме у них 1 мегабит», «а каждый юзер из это группы — по 2 мбита»
Тоже некрасиво. Скорость должна не рубиться, а гарантироваться. Тому юзеру гарантируем столько-то процентов от полосы, той группе — столько. Ваша схема приводит к неоптимальному использованию полосы. Если канал на 10мбит загружен на 1мбит, и юзер хочет что-то скачать или закачать, надо предоставить ему ширину, максимально близкую к 9мбит/с/ но он сразу подвинется, как только кто-то еще начнет качать. С исходящим трафиком это проще пареной репы, со входящим сложнее, но тоже реализуемо.
Существуют расширения для TMG, умеющие что угодно.
Любопытно, а если на машине запущено несколько сетевых программ под разными учётками, TMG сможет понять, какой трафик от какой учётки, чтобы применить политики?
Вы путаете протокол DHCP (неуправляемая выдача айпишников всем подряд) и протокол DHCP (автоматическая, централизованная выдача сетевых настроек нужным устройствам)
компьютерам тоже. Бывают системные процессы с правом лимитированного выхода куда-то за обновлениями.
Это где такое написано? (Я без наезда, просто прочитать).
А то половина литературы про Ipv6 намертво устарела и те фичи были выпилены до приёма в продакт. А книжки про них остались.
А то половина литературы про Ipv6 намертво устарела и те фичи были выпилены до приёма в продакт. А книжки про них остались.
Можете ли вы сидя за натом связаться с своей рабочей станцией на работе?
В любой нормальной компании доступ напрямую из интернета до рабочей станции будет запрещен вне зависимости от наличия или отсутствия NATа…
Кроме того, наличие приватной адресации скрывает внутреннюю топологию сети. Сомнительный, но все же элемент безопасности.
Хотя я знаю одну средних размеров компанию, где все (или по крайней мере многие) пользовательские компьютеры имеют глобально маршрутизируемые адреса. Буржуи…
А ведь могла бы быть куда более культурная схема — когда сервер обращается к клиенту с новым сообщением. Без «TCP с keepalive'ами».
Кипалайвы полезны. Без них сервер будет долго слать сообщения в пустоту, если клиент закрыл аську, или выключил компьютер.
TCP предоставляет какую-никакую, но защиту от спуфинга.
TCP хорош для сообщений тем, что дает гарантию доставки. Да, можно реализовать ACKи на уровне приложения, работающего поверх UDP — чтобы обнаружить, что изобретен велосипед.
В общем, так себе пример :)
Да кто-бы спорил? Конечно, прямая адресация всего и везде — это удобно. И это так должно быть.
Я о том, что даже в организациях, где белых адресов достаточно — все равно используют серые. Это такая сложилась good practice. И все ей следуют.
Лично я всеми руками за полноценный переход на IPv6. Но давайте не будем это обосновывать тем, что IPv4 закончились. Проблема не в том, что они закончились, а в том, что их не хватает для прямой адресации. С NAT-ами мы на IPv4 можем еще много лет протянуть. Но таки неудобно, да. И тянуть это за собой смысла нет. Потому надо переходить. Просто потому, что надо.
Я о том, что даже в организациях, где белых адресов достаточно — все равно используют серые. Это такая сложилась good practice. И все ей следуют.
Лично я всеми руками за полноценный переход на IPv6. Но давайте не будем это обосновывать тем, что IPv4 закончились. Проблема не в том, что они закончились, а в том, что их не хватает для прямой адресации. С NAT-ами мы на IPv4 можем еще много лет протянуть. Но таки неудобно, да. И тянуть это за собой смысла нет. Потому надо переходить. Просто потому, что надо.
даже в организациях, где белых адресов достаточно — все равно используют серые. Это такая сложилась good practice.
На самом деле паршивая практика. Любая NATилка обязана понимать на уровне приложения десятки различных протоколов, иначе они сломаются в процессе трансляции.
Во-первых, НАТилки прекрасно (почти) всё понимают, во-вторых, не работают через НАТ только изначально ущербные протоколы, вроде FTP/SIP/RTSP.
Что-то вот не припомню никаких проблем ни у DNS, ни у HTTP, ни у XMPP.
Что-то вот не припомню никаких проблем ни у DNS, ни у HTTP, ни у XMPP.
не работают через НАТ только изначально ущербные протоколы, вроде FTP/SIP/RTSP
А почему ущербные? Под «SIP» можно понимать весь VOIP. Протоколы на самом деле отличные, просто не предназначенные для NATа.
Они работают, но с костылями. Однажды я столкнулся с тем, что h.323 отказался работать — немного некорректно отрабатывало инспектирование h.245 на NATилке…
На самом деле организации, имеющие PI блоки достаточных размеров, предпочитают выдавать глобально маршрутизируемые адреса всем системам, которые будут общаться с внешним миром по каким-либо протоколам, более сложным, чем HTTP. Ну или просто всем тем, к которым может быть осуществлен доступ снаружи. NAT не является средством безопасности ни под каким видом — так зачем лишние сложности?
NAT не является средством безопасности ни под каким видом — так зачем лишние сложности?
JDima — Я бы так не сказал — это один из дополнительных методов не пускать нежелательный трафик
это один из дополнительных методов не пускать нежелательный трафик
Ни в малейшей степени.
Если я не хочу, чтобы десктопные машинки попадали в инет мимо прокси — я выключаю нат.
если я хочу чтобы машинка с клиентбанком напрямую лазяла только на хост сервера КБ — я её это разрешу.
почему это не элемент безопасности?
как минимум защита от того, что даже если на рабочей станции есть вирус. станция не будет заниматься ddos'ом или рассылкой спама…
если я хочу чтобы машинка с клиентбанком напрямую лазяла только на хост сервера КБ — я её это разрешу.
почему это не элемент безопасности?
как минимум защита от того, что даже если на рабочей станции есть вирус. станция не будет заниматься ddos'ом или рассылкой спама…
Если я не хочу, чтобы десктопные машинки попадали в инет мимо прокси — я выключаю нат.
А просто правила файрвола — это уже не модно? Они малость функциональнее будут.
почему это не элемент безопасности?
По той причине, что любые правила доступа настраиваются файрволом. Если вы отключаете NAT и выпускаете наружу нетранслированные пакеты, и таким образом ограничиваете доступ — ну что же, в мире много всяких извращений, так что я не особо удивлен.
политики фаервола на рабочих станциях это одно, а политика фаервола на роутере и политика NAT'е это всё же немного другое, не находите?
политики фаервола на рабочих станциях
Зачем? Он там вообще не нужен. Защиту рабочих станций должны осуществлять периметровые файрволы и понатыканные тут и там IPSы.
а политика фаервола на роутере и политика NAT'е это всё же немного другое
И по-моему, очевидно, что предоставлением доступов должен заниматься именно периметровый файрвол, на котором нередко и NAT поднимают.
Или вы прямо на компьютере пользователя говорите «запретить одноклассников»? Тогда все еще более печально.
я не считаю, что firewall на рабочих станциях не нужен.
Точно так же не считаю что стоит пускать кого попало в мир через NAT.
а для закрытия одноклассников есть прокси, логи прокси по части разных попыток добраться туда, куда не надо и выписанные пилюли от начальства
Точно так же не считаю что стоит пускать кого попало в мир через NAT.
а для закрытия одноклассников есть прокси, логи прокси по части разных попыток добраться туда, куда не надо и выписанные пилюли от начальства
Точно так же не считаю что стоит пускать кого попало в мир через NAT.
Конечно нельзя.
Но правила NATа всегда должны быть максимально разрешающими (т.е. если гипотетически при обращении из сети А в сеть Б нужно будет транслировать адреса, то NAT обязательно должен быть включен). А затем на уровне политик файрвола решать, чей пакет пропустить, а чей — нет.
а для закрытия одноклассников есть прокси
Для закрытия или открытия любых доступов есть прокси/файрвол.
У вас что, прокси (который на самом деле является и файрволом) не в inline стоит?
Сколько живу, сколько администрирую, но про «максимально разрешающий NAT» от Вас слышу впервые.
И считаю это идиотизмом и нарушением единственного правила Unix, которое мне вдолбили еще 10 лет назад, которое гласит что запрещено делать всё, что не разрешено.
Так вот чисто по моему опыту — чем меньше открыто, тем меньше геморроя.
И считаю это идиотизмом и нарушением единственного правила Unix, которое мне вдолбили еще 10 лет назад, которое гласит что запрещено делать всё, что не разрешено.
Так вот чисто по моему опыту — чем меньше открыто, тем меньше геморроя.
Сколько живу, сколько администрирую, но про «максимально разрешающий NAT» от Вас слышу впервые.
Учитесь дальше.
Скажите — вам доводилось изучать best practices, design guide'ы и тому подобное по части организации сетевого периметра? Не обязательно привязанные к конкретному вендору (ибо общие принципы везде одинаковые). Мне кажется, что не доводилось ни разу, и дизайн вы разрабатываете по наитию, соответственно — дизайн выходит корявый.
Еще раз: NAT абсолютно ни в коей степени не является средством ограничения доступа. Не знаю, чья больная фантазия придумала такую глупость. Назначение NAT — как раз обеспечение доступа, и его правила должны быть такими, чтобы при наличии «permit ip any any» на файрволе у всех все работало. Для настройки запретов есть единая точка администрирования — файрвол. Высшая степень идиотизма еще и NAT под это задействовать.
Так вот чисто по моему опыту — чем меньше открыто, тем меньше геморроя.
NAT не имеет отношения к открытию/закрытию доступов.
Прокси это прошлый век, постепенно все откажутся от этого кривого аппендикса, в пользу DPI технологий.
Прокси это прошлый век, постепенно все откажутся от этого кривого аппендикса, в пользу DPI технологий.
Заблуждаетесь.
На самом деле все современные прокси/файрволы имеют функционал DPI. Некоторые еще и IPS с обновляемыми сигнатурами. Но они все равно остаются прокси.
Вы заблуждаетесь :)
Именно потому, что все вендоры, встраивают поддержку DPI в свои устройства, отпадает необходимость в ответвлении трафика (а если еще требуется SSL, то прописывание браузерных политик). И proxy != firewall, фаерволы ничего не проксируют.
Именно потому, что все вендоры, встраивают поддержку DPI в свои устройства, отпадает необходимость в ответвлении трафика (а если еще требуется SSL, то прописывание браузерных политик). И proxy != firewall, фаерволы ничего не проксируют.
proxy != firewall, фаерволы ничего не проксируют.
Ох…
Продукция Check Point, Blue Coat, MS TMG и так далее — файрволы, попутно прокси, попутно частично DPI. Они могут стоять в inline, могут — out of band. Они могут читать SSL методом спуфинга сертификатов (какие еще браузерные политики?), а могут и не читать.
Современные файрволы — весьма навороченные комбайны. Уже давно нет разделения.
в мелких и средних конторах ни чек поинт, ни иса/tmg почти не используются, в отличие от сквида.
в мелких и средних конторах ни чек поинт, ни иса/tmg почти не используются, в отличие от сквида.
Мне нет дела до говнорешений.
Ну вот видите, вы видимо обслуживая только 1 сеть, стали забывать что такое прокси и зачем изначально адреса прокси прописывались в браузерах :)
И наверно не можете себе представить то, что представляет себе любой консультант, когда заказчик начает говроить о proxy. Поэтому не нужно отождествлять и подменять данные термины между собой.
И наверно не можете себе представить то, что представляет себе любой консультант, когда заказчик начает говроить о proxy. Поэтому не нужно отождествлять и подменять данные термины между собой.
вы видимо обслуживая только 1 сеть, стали забывать что такое прокси и зачем изначально адреса прокси прописывались в браузерах :)
Я понимаю. Вы — нет.
Сейчас уже никто не ставит прокси в out of band. Однако, роль данного сервера не меняется. Я считаю, что различие между подходами к расположению сервера слишком мизерны, чтобы выдумывать новое слово, потому буду дальше называть «проксей» решение, в том числе фильтрующее HTTP по категориям и прочему.
Ну вот видите, вы все таки не понимаете.
Это нормально и отличает людей что-то эксплуатирующих и что-то интегрирующих. Как правило когда заказчик говорит о Proxy, он подразумевает что у него где-то стоит ISA (Squid, Kerio и т.п.) куда он средствами политик AD заворачивает трафик и фильтрует по категориями.
А отличие от расположения (не будет брать сюда обратное проксирование трафика к веб-сервисам) все таки существенно, согласитесь, поддерживать сеть где трафик маршрутизируется только на основе L3 маршрутизации удобнее и проще, чем выяснять куда там бразуер\PBR заворачивает какой-то трафик и что там с ним присходит, почему больше ничего не работает.
Впринципе называть проксей можете и дальше, просто я расстроился, подумав что вы используете классические прокси, хотя вроде бы в тематике подкованы.
Это нормально и отличает людей что-то эксплуатирующих и что-то интегрирующих. Как правило когда заказчик говорит о Proxy, он подразумевает что у него где-то стоит ISA (Squid, Kerio и т.п.) куда он средствами политик AD заворачивает трафик и фильтрует по категориями.
А отличие от расположения (не будет брать сюда обратное проксирование трафика к веб-сервисам) все таки существенно, согласитесь, поддерживать сеть где трафик маршрутизируется только на основе L3 маршрутизации удобнее и проще, чем выяснять куда там бразуер\PBR заворачивает какой-то трафик и что там с ним присходит, почему больше ничего не работает.
Впринципе называть проксей можете и дальше, просто я расстроился, подумав что вы используете классические прокси, хотя вроде бы в тематике подкованы.
А отличие от расположения (не будет брать сюда обратное проксирование трафика к веб-сервисам) все таки существенно
Для сервера оно монописуально. Трафик входит с него с одной стороны и выходит с другой. То, что на входе был каким-либо образом туннелированный трафик, ничего не меняет для сервера, это мелочь.
поддерживать сеть где трафик маршрутизируется только на основе L3 маршрутизации удобнее и проще, чем выяснять куда там бразуер\PBR заворачивает какой-то трафик и что там с ним присходит, почему больше ничего не работает.
По опыту — добавляется лишний элемент в виде механизма autodiscover, который временами любит ломаться, но в общем и целом никакого радикального повышения сложности обслуживания нет.
Странно, почему во всех сетях, начиная от рабочих групп без домена на 5 машин, кончая транснациональными сетями на сотни филиалов, с которыми я был связан напрямую или через знакомых админов, везде использовался squid из «прошлого века», по Вашей терминологии
почему во всех сетях, начиная от рабочих групп без домена на 5 машин, кончая транснациональными сетями на сотни филиалов, с которыми я был связан напрямую или через знакомых админов, везде использовался squid из «прошлого века», по Вашей терминологии
Про транснациональные компании явно врете.
В моей компании сотни филиалов, и я знаю штук 5 других сравнимых или более крупных. Нигде нет никакого опенсорса на подобных направлениях.
Не вру, но в тех компаниях Windows практически не использовалось, в отличие от opensource, и продукции rhel, suse, oracle и других крупных Linux вендоров
в тех компаниях Windows практически не использовалось
И это — глупость.
В крупных компаниях линукс как раз редко встречается. Клиентская часть на виндах. Сервера — на солярке, аиксе, край — фряхе. А вот линукс очень редкий гость.
Да вы просто линуксоненавистник :)
Исторически сложилось, что у нас все сервера были на фряхе, в том числе высоконагруженные СУБД на Firebird. Когда в линуксе анонсировали какие-то улучшения в I/O, мы протестировали производительность на типичной нагрузке и в линуксе получилось на 10% быстрее, перешли на линукс.
Когда к нам в компанию пришли евангелисты микрософт, поднялся вопрос о переводе СУБД под венду. И что неожиданно — она на наших задачах оказалась на 20% (!!!) быстрее линукса, ещё один переход сделали. Благо, firebird многоплатформенный.
Исторически сложилось, что у нас все сервера были на фряхе, в том числе высоконагруженные СУБД на Firebird. Когда в линуксе анонсировали какие-то улучшения в I/O, мы протестировали производительность на типичной нагрузке и в линуксе получилось на 10% быстрее, перешли на линукс.
Когда к нам в компанию пришли евангелисты микрософт, поднялся вопрос о переводе СУБД под венду. И что неожиданно — она на наших задачах оказалась на 20% (!!!) быстрее линукса, ещё один переход сделали. Благо, firebird многоплатформенный.
В моей тоже используется. Пользуется им от силы человек 20. На него уже года четыре никто не логинился. По хорошему, кансельнуть, да как-то никому не хочется руки пачкать, ничего критичного через него все равно не ходит.
А чтобы центральным прокси в крупной компании был сквид — нет, такого не бывает. За исключением, может быть, компаний уровня гугла с превосходным штатом разработчиков, чей сквид наверняка напоминает общедоступный разве что названием и больше ничем.
А чтобы центральным прокси в крупной компании был сквид — нет, такого не бывает. За исключением, может быть, компаний уровня гугла с превосходным штатом разработчиков, чей сквид наверняка напоминает общедоступный разве что названием и больше ничем.
Обычно Squid отваливается на стадии, когда обслуживать его становится дорого. Никому не интересно экономить 10 рублей на кешировании картинок, а для контроля WEB доступа есть более масштабируемые и централизованно управляемые средства.
Короче Squid обычно у контор с недостатком финансирования.
Короче Squid обычно у контор с недостатком финансирования.
Для закрытия или открытия любых доступов есть прокси/файрвол.
У вас что, прокси (который на самом деле является и файрволом) не в inline стоит?
с каких это пор прокси является фаерволом?
Я не буду говорить про тех, кто функционал фаервола и прокси обьединяет в одну коробку — к сожалению в мелких конторах это в 90% чаще всего один пк на юниксе.
Но если вы умудритесь на «фаерволе», например ASA5x или PIX'e настроить прокси — я Вас порекомендую вместо себя админом (смайлик)
да, про прозрачный прокси я в курсе, но разговор сейчас не о прозрачном проксировании
Я не буду говорить про тех, кто функционал фаервола и прокси обьединяет в одну коробку
Microsoft например, или тот же Check Point… Лучше как раз про них говорите.
Но если вы умудритесь на «фаерволе», например ASA5x или PIX'e настроить прокси
Угу, и прямо SSM не умеет делать URL filtering и тому подобное…
я Вас порекомендую вместо себя админом
Я лучше воздержусь.
разговор сейчас не о прозрачном проксировании
С какого перепуга?
Насколько я помню по маркетинговой брошуре — MS TMG — ставится как на рабочие станции клиентская часть, так отдельно серверная часть и консоль управления.
С логичным ограничением запрета установки TMG на AD DC, что, в принципе, логично.
Опять же, ISA/TMG не отменяют аппаратного фаервола _до_ сервера vpn/tmg
С логичным ограничением запрета установки TMG на AD DC, что, в принципе, логично.
Опять же, ISA/TMG не отменяют аппаратного фаервола _до_ сервера vpn/tmg
MS TMG — ставится как на рабочие станции клиентская часть, так отдельно серверная часть и консоль управления.
Может работать с клиентом. Может без. На любые сервера клиент никогда не ставят.
ISA/TMG не отменяют аппаратного фаервола _до_ сервера vpn/tmg
TMG прекрасно может работать в роли файрвола. Аппаратную железку можно ставить в виде грубого, но быстрого L3/L4 фильтра, отдав L7 на откуп TMG.
TMG прекрасно может работать в роли файрвола. Аппаратную железку можно ставить в виде грубого, но быстрого L3/L4 фильтра, отдав L7 на откуп TMG.
У вас сейчас так работает в эксплуатации? Исторически сложилось или потому что Cisco не поддерживала данный функционал? Сейчас удобнее поддерживать одну железку, которая умеет фильтровать быстро на всех уровнях.
У вас сейчас так работает в эксплуатации? Исторически сложилось или потому что Cisco не поддерживала данный функционал? Сейчас удобнее поддерживать одну железку, которая умеет фильтровать быстро на всех уровнях.
Исторически сложилось или потому что Cisco не поддерживала данный функционал?
Ни то, ни то. Скорее — разделение обязанностей. TMG отлично работает на уровне приложения, но по производительности не бьет рекордов. ASA является первоклассной NATилкой, и очень быстро фильтрует на L3/L4. Кроме того, гипотетически ASAшку завалить куда сложнее, чем TMG. Потому логично расположить на внешнем периметре аппаратный файрвол, а позади него более нежное и чуткое программное решение.
(у нас не TMG, но это ничего не меняет)
Сейчас удобнее поддерживать одну железку, которая умеет фильтровать быстро на всех уровнях.
Удобнее — да. Надежнее — не факт.
Забыл:
А зачем он там?
Ну и вспомните старый тезис: «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте». Заменить «пишите код» на «стройте инфраструктуру», и получится настолько же верное утверждение. Ограничение доступа политиками NAT — чушь какая-то.
я не считаю, что firewall на рабочих станциях не нужен.
А зачем он там?
Ну и вспомните старый тезис: «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте». Заменить «пишите код» на «стройте инфраструктуру», и получится настолько же верное утверждение. Ограничение доступа политиками NAT — чушь какая-то.
Для психопата, которые знает, где я живу есть замечательная штука — документирование, протоколирование и приказы по компании.
Для психопата, которые знает, где я живу есть замечательная штука — документирование, протоколирование и приказы по компании.
Если бы я был склонным к агрессии психопатом, и меня приняли бы поддерживать инфраструктуру, которую поднимали вы, и я увидел бы ограничения доступа NATом — ну что же, сочувствую :)
А то вообще весело, про фаеры на РС. Пусть любой инсайд резвится на полную катушку.
Расскажите мне, как локальный файрвол защитит от инсайда.
А еще расскажите, зачем он нужен при правильном разграничении доступов к ресурсам, а также при наличии систем IPS, DLP, application-aware инспектирования трафика между периметрами, системы контроля подключения к сети (предоставление доступа к сети только если подключена доменная машина, и на ней аутентифицирован доменный пользователь; политики применяются прямо на порту) и так далее.
А еще расскажите, зачем он нужен при правильном разграничении доступов к ресурсам, а также при наличии систем IPS, DLP, application-aware инспектирования трафика между периметрами, системы контроля подключения к сети (предоставление доступа к сети только если подключена доменная машина, и на ней аутентифицирован доменный пользователь; политики применяются прямо на порту) и так далее.
А ещё расскажите мне, зачем конторе на 5 — 50 компов строить IPS, DLP, AA DPI, периметры и прочее.
Так же расскажите, что будет если в замечательной сети с контроллем доступа появится вполне себе доверенная машина (доменная, с аутентифицированным пользователем и прочий 802.1x), с пользователем у которого evil intentions?
А локальный фаервол может защитить от инсайда весьма банально — не давая светить работающие сервисы другим членам сети.
JDima, у вас enterprise головного мозга, и если в случае с большим предприятием я с вами солидарен по всем пунктам сетевой безопасности (кроме локального FW), то для SMB — категорически нет.
Так же расскажите, что будет если в замечательной сети с контроллем доступа появится вполне себе доверенная машина (доменная, с аутентифицированным пользователем и прочий 802.1x), с пользователем у которого evil intentions?
А локальный фаервол может защитить от инсайда весьма банально — не давая светить работающие сервисы другим членам сети.
JDima, у вас enterprise головного мозга, и если в случае с большим предприятием я с вами солидарен по всем пунктам сетевой безопасности (кроме локального FW), то для SMB — категорически нет.
расскажите, что будет если в замечательной сети с контроллем доступа появится вполне себе доверенная машина (доменная, с аутентифицированным пользователем и прочий 802.1x), с пользователем у которого evil intentions?
Да ничего особенного на самом деле. Украсть информацию он сможет разве что фотографируя монитор. Ну, может, удалит те данные, к которым имеет доступ (бекапы).
При этом пользователь не может подключить к сети ноутбук с backtrack или LAN-портом wi-fi роутер. А ведь последний пункт является исключительно стремным.
А локальный фаервол может защитить от инсайда весьма банально — не давая светить работающие сервисы другим членам сети.
Какие сервисы? RDP? SMB?
Вы ведь понимаете, что все более-менее интересные для инсайдера файлы будут храниться не на соседнем компьютере, а на сервере? Ну запретили кому-то доступ файрволом — теперь он не может работать с шарой.
у вас enterprise головного мозга
Вовсе нет — я знаю одну контору на 20 человек, где подняты IPS (правда, снорт), 802.1x, а также весьма грамотно настроен периметр.
то для SMB — категорически нет.
Мелким фирмочкам не нужна безопасность? Сами ведь говорите, что боитесь инсайда. Так ведь системы контроля доступа к сети и DLP как раз могут быть весьма эффективны.
Отключение ната не отключает маршрутизацию трафика.
Внезапно: пакет, отправленный с 192.168.1.1 на маршрутизатор с выключенным натом уйдёт наружу, и дойдёт до получателя с 192.168.1.1 в src.
Внезапно: пакет, отправленный с 192.168.1.1 на маршрутизатор с выключенным натом уйдёт наружу, и дойдёт до получателя с 192.168.1.1 в src.
NAT не является средством безопасности, но при этом делает всю заNATенную сеть non-routeable, и для локальной сети предприятия меня это весьма устраивает, меньше возможности проникновения, меньше шансов на ошибку в конфигурации.
Ну и зачем рядовым ПК в организации global routeable адреса?
А кривые они именно из-за неподдержки НАТа, причем если для ФТП достачно тупо в PORT слать внешний айпишник, то с SIPом нужен inspection, и то, как сами знаете, не всегда работает.
Ну и зачем рядовым ПК в организации global routeable адреса?
А кривые они именно из-за неподдержки НАТа, причем если для ФТП достачно тупо в PORT слать внешний айпишник, то с SIPом нужен inspection, и то, как сами знаете, не всегда работает.
меньше возможности проникновения, меньше шансов на ошибку в конфигурации.
Всегда нужны решения, осуществляющие compliance сканирование правил файрвола.
Если вы боитесь своих рук, то может, не стоит заниматься ответственными делами?
Ну и зачем рядовым ПК в организации global routeable адреса?
Отказ от NAT/PAT.
А кривые они именно из-за неподдержки НАТа
Т.е. не протокол кривой, а сама концепция NAT.
Угу, а маленькая фирма пусть ответственных дядек нанимает. Особенно если их рядом нет.
Т.е. ради идеи? Вопрос не NÁT/PAT, вопрос в отсутствии необходимости.
Коли сама концепция была кривой, почему же большинство протоколов прнкрасно работает чернз NAT
Т.е. ради идеи? Вопрос не NÁT/PAT, вопрос в отсутствии необходимости.
Коли сама концепция была кривой, почему же большинство протоколов прнкрасно работает чернз NAT
Вопрос не NÁT/PAT, вопрос в отсутствии необходимости.
А еще в красоте решения.
Коли сама концепция была кривой, почему же большинство протоколов прнкрасно работает чернз NAT
Чтобы понять ответ на этот вопрос, задайте себе следующие наводящие вопросы:
1) Как работает NAT?
2) Как работает VOIP (для примера)?
3) Чем VOIP принципиально отличается от HTTP?
1) переписывает SRC IP и форвардит на нужный интерфейс. В случае PAT может и не переписывать, в обоих случаях требуется иметь connection state table.
2) через жопу (памятуя сколько геммора я наслушался/поимел при настройке GW). А так — не сильно отличается от того же FTP, одно соединение на control, по одному отдельному соединению на поток. При PASV и разрешения коннектиться на все порты наружу для клиента за NATом даже ftp helper не нужен, само будет работать.
Для активного режима и строгово фаера — нужен хелпер, но работает. Почему при наличии STUN, хелперов и прочего, это хозяйство всё равно работает через раз — выше моего понимания, потому и делаю вывод, что SIP и RTSP — уродские протоколы, которые ломаются при любом чихе.
3)в эпоху web 2.0 — ничем наличием дополнительных потоков, которые ломятся в обе стороны как бог на душу положит.
2) через жопу (памятуя сколько геммора я наслушался/поимел при настройке GW). А так — не сильно отличается от того же FTP, одно соединение на control, по одному отдельному соединению на поток. При PASV и разрешения коннектиться на все порты наружу для клиента за NATом даже ftp helper не нужен, само будет работать.
Для активного режима и строгово фаера — нужен хелпер, но работает. Почему при наличии STUN, хелперов и прочего, это хозяйство всё равно работает через раз — выше моего понимания, потому и делаю вывод, что SIP и RTSP — уродские протоколы, которые ломаются при любом чихе.
3)
одно соединение на control, по одному отдельному соединению на поток.
Отлично — так зачем так сделали? Почему НЕВОЗМОЖНО пускать и сигнализацию, и медию в одном соединении?
выше моего понимания
И впрямь.
Потому что мультиплексирование в один поток — дикое усложнение протокола. Представьте себе какой-нибудь IM, который состоит из «звук», «чат», «видео», «рабочий стол».
Ваше решение? Написать монстра на ASN.1? Или просто открыть четыре сокета? Лично мне второй вариант кажется куда более элегантным, чем любой, самый изощрённый, метод in-band мультиплексирования.
Ваше решение? Написать монстра на ASN.1? Или просто открыть четыре сокета? Лично мне второй вариант кажется куда более элегантным, чем любой, самый изощрённый, метод in-band мультиплексирования.
Потому что в результате эти соединения идут на разные хосты!
В контексте SIP сигнализация идёт на сервер моего провайдера VoIP, оттуда к провайдеру второго абонента, оттуда к самому абоненту; а вот сами медиа-данные могут идти напрямую.
FTP так же можно напрямую соединить — передать данные между серверами, а не транзитом через хост пользователя.
В контексте SIP сигнализация идёт на сервер моего провайдера VoIP, оттуда к провайдеру второго абонента, оттуда к самому абоненту; а вот сами медиа-данные могут идти напрямую.
FTP так же можно напрямую соединить — передать данные между серверами, а не транзитом через хост пользователя.
Потому что в результате эти соединения идут на разные хосты!
Бинго! И впрямь, нет ни малейшего смысла пускать голосовой трафик в сторону SIP-провайдера, если вызываемая сторона находится в интернете.
И чтобы оно в таком виде хоть как-то могло проползти через NAT, требуются всякие костыли вроде STUN — который, как уже было замечено, работает не всегда и не везде.
Именно это я и подразумеваю под «nat выел мозг». В чём ущербность ftp и sip? В том, что они через нат плохо ходят? А может это nat, как технология, ущебрен, а не протоколы?
Посыл «nat, как технология, ущебрен» был бы верен, если бы через него нормально ходило бы только 5% протоколов, а всё остальноё требовало изъёбов. В ситуации, когда 95% протоколов прекрасно ходят через NAT, а изъёбов требуют 5% протоколов, вывод о том, кто ущербен — напрашивается сам.
Идеей IP (по сравнению со всякими IPX) была фундаментальная идея: каждый узел сети может обратиться к каждому. Там было ещё несколько идей — hop-based routing, агрегирование и т.д., но исходная идея Интернета именно в этом и состоит: каждый с каждым.
Есть куча протоколов, в которых вызов идёт от клиента к серверу (ярчайший пример — HTTP). Но могут быть ситуации и обратные — когда вызов идёт от сервера к клиенту (и SIP отличный тому пример). А ещё может оказаться так, что серверу нужно установить несколько соединений с клиентом для разных субпротоколов.
Считать, что такой подход ущербен можно только в одном случае — если мы признаём, что есть «особые» IP-адреса серверов, к которым можно подключаться, и есть массовые быдло-адреса клиентов, с которых можно только коннектиться, но к которым нельзя обратиться.
Если так — да, любой протокол, обращающийся к клиенту пытается обратиться к быдлоадресу и очевидно ущербен.
Если же мы говорим про Интернет, то тут нет «быдло-адресов», и сервер вполне может обратиться к клиенту.
А вот технологии, которые переводят Интернет в сегрегированную сеть с «белыми» и «быдло-» IP-адресами — вот они-то как раз с точки зрения принципов Интернета ущербны.
Есть куча протоколов, в которых вызов идёт от клиента к серверу (ярчайший пример — HTTP). Но могут быть ситуации и обратные — когда вызов идёт от сервера к клиенту (и SIP отличный тому пример). А ещё может оказаться так, что серверу нужно установить несколько соединений с клиентом для разных субпротоколов.
Считать, что такой подход ущербен можно только в одном случае — если мы признаём, что есть «особые» IP-адреса серверов, к которым можно подключаться, и есть массовые быдло-адреса клиентов, с которых можно только коннектиться, но к которым нельзя обратиться.
Если так — да, любой протокол, обращающийся к клиенту пытается обратиться к быдлоадресу и очевидно ущербен.
Если же мы говорим про Интернет, то тут нет «быдло-адресов», и сервер вполне может обратиться к клиенту.
А вот технологии, которые переводят Интернет в сегрегированную сеть с «белыми» и «быдло-» IP-адресами — вот они-то как раз с точки зрения принципов Интернета ущербны.
Идеей IP (по сравнению со всякими IPX) была фундаментальная идея: каждый узел сети может обратиться к каждому
Когда IP придумывался, небыло речи о кофеварках и холодильниках, подключенных к интернету.
Но могут быть ситуации и обратные — когда вызов идёт от сервера к клиенту (и SIP отличный тому пример)
Угу, только в FTP почему-то сделали PASV, а в SIP — нет. Это при том, что SIP делался 1996, когда уже были очевидны проблемы и с адресами и с NATом.
А вот технологии, которые переводят Интернет в сегрегированную сеть с «белыми» и «быдло-» IP-адресами — вот они-то как раз с точки зрения принципов Интернета ущербны.
Только идеологически.
Собственно, задумайтесь: все IM-протоколы держат TCP-соединение. Всегда. Нахрена, спрашивается? Потому что иначе сервер не может сказать клиенту, что пришло новое сообщение.
Это проблема TCP, а не IP.
Это проблема TCP, а не IP.
Каким образом сервер может установить соединение с клиентом, если клиент за натом?
Исходящий UDP «пробивает дырку» в NAT со стороны клиента, после чего сервер может невозбранно слать клиенту UDP пакеты в любой момент. Клиенту нужно один раз в начале работы послать серверу пакет.
И как долго эта дырка держится? Через 4 дня входящий вызов можно прислать? Ну-ну.
Ничто не мешает дырочку обновлять хоть каждую минуту, заодно сервер будет в курсе, что мы живы.
А еще спамботы со всего света не будут меня беспокоить. =)
А еще спамботы со всего света не будут меня беспокоить. =)
>> обновлять хоть каждую минуту
и вы изобрели TCP с его keep-alive ))
и вы изобрели TCP с его keep-alive ))
На что только не пойдут люди, лишь бы протащить старый кривой костыль в будущее.
Увы, это не совсем так. UDP пробивает в NAT именно дырочку, в которую может писать любой желающий. И эта дырочка сохраняется довольно долго, даже после физического разрыва связи.
А TCP без keep-alive и пяти минут не проживет, не говоря уж о физических разрывах. =)
А TCP без keep-alive и пяти минут не проживет, не говоря уж о физических разрывах. =)
>> UDP пробивает в NAT именно дырочку, в которую может писать любой желающий
Прочитайте про типы NAT (Full cone, address restricted и т.п.)
ru.wikipedia.org/wiki/STUN
Поведение NAT перпендикулярно протоколу (TCP/UDP).
Мой роутер, например, не позволяет делать hole punching — если UDP-пакет приходит в дырку от другого IP, а не с того, с кем первоначально установлено соединение, он отбрасывается. Если же ваш роутер принимает в дырку UDP-пакеты с любого IP, вы уверены, что он не делает то же самое с TCP-пакетами?
Прочитайте про типы NAT (Full cone, address restricted и т.п.)
ru.wikipedia.org/wiki/STUN
Поведение NAT перпендикулярно протоколу (TCP/UDP).
Мой роутер, например, не позволяет делать hole punching — если UDP-пакет приходит в дырку от другого IP, а не с того, с кем первоначально установлено соединение, он отбрасывается. Если же ваш роутер принимает в дырку UDP-пакеты с любого IP, вы уверены, что он не делает то же самое с TCP-пакетами?
* тут подробнее, чем wiki www.cyberguru.ru/networks/network-security/nat-details.html
Даже если роутер пропустит «чужой» TCP-пакет, его не примет ОС. Потому что TCP в принципе чисто сеансовый и принимает пакеты только от конкретного хоста и порта. И дырка закрывается сразу после сеанса. А с UDP все гораздо проще — он не сеансовый, там нет принципиальных различий между клиентом и сервером. Кто первый вякнул — тот и клиент. И дырка от UDP просто так не закроется, потому как нет «закрывающего» пакета.
Full Cone NAT нужен только в случае, если оба хоста за NATами. И нужен он только на одной стороне. Для связи с публичным сервером это не требуется.
Full Cone NAT нужен только в случае, если оба хоста за NATами. И нужен он только на одной стороне. Для связи с публичным сервером это не требуется.
Можете ли вы сидя за натом связаться с своей рабочей станцией на работе?Да, могу, потому что есть еще такая штука как порт. over 65000 рабочих станций на 1 белый айпи.
Наивная, утопическая идея связать «каждый с каждым» натолкнулась на естественное желание обеспечить информационную безопасность. И потому идея эта сейчас объективно не востребована.
Наивная, утопическая идея связать «каждый с каждым»
И это говорит человек эпохи торрентов, VOIPа и так далее.
естественное желание обеспечить информационную безопасность.
NAT/PAT не имеет никакого отношения к информационной безопасности.
Никогда не возьму на работу сетевика, который всем в офисе даст по белому IP адресу, откроет доступ к торрентам и вообще распахнет сети наружу: подключайтесь!
Особенно эта фраза «радует»: NAT/PAT не имеет никакого отношения к ИБ… Хотел бы я знать, это позиция Cisco или личное мнение? Ведь по факту NAT обеспечивает некоторую, в ряде случаев достаточную защиту локальной сети. А при столкновении теории и практики — побеждает, как известно, практика.
Особенно эта фраза «радует»: NAT/PAT не имеет никакого отношения к ИБ… Хотел бы я знать, это позиция Cisco или личное мнение? Ведь по факту NAT обеспечивает некоторую, в ряде случаев достаточную защиту локальной сети. А при столкновении теории и практики — побеждает, как известно, практика.
Никогда не возьму на работу сетевика, который всем в офисе даст по белому IP адресу, откроет доступ к торрентам и вообще распахнет сети наружу: подключайтесь!
Значит, вы слишком мало знаете о сетях.
Я бы с удовольствием выдал всем внутренним устройствам глобально маршрутизируемые адреса. Только у меня нет достаточного по размерам адресного пространства, только жалкая /22 сетка… И я знаю лишь одну коммерческую организацию, которая так делает, но она реально небольшая. А есть всякие мудаки вроде британского минобороны, которые отхапали себе /8, но ни одного, самого махонького префикса не выпускают…
Торренты… А откуда они взялись? Как-то странно у вас работает логика… Из «я технически могу это сделать» не следует «я обязательно так сделаю». К сведению: у нас на много тысяч сотрудников лишь пара десятков мегабит трафика от/до внешних ресурсов.
Хотел бы я знать, это позиция Cisco или личное мнение?
Всеобщее мнение. Механизм PAT очень похож на крайней ущербности stateful файрвол, нередко пробиваемый без особых проблем (см. UDP hole punching). С таким же успехом можно включить файрвол и без PAT. Даже не с «тем же успехом», а «с лучшими результатами».
Единственное, что делает PAT по сравнению с нормальным файрволом — маскирует адрес. Всё. Аргумент «не проделав статическую NAT трансляцию, к внутреннему хосту не подключиться» глуп, так как то же самое верно и про файрвол, если подменить «трансляция» на «правило». И если ваша сетевая безопасность построена на PAT (по желанию добавить роутерные ACL), тут уж проблема в ДНК того, кто это придумал.
А при столкновении теории и практики — побеждает, как известно, практика.
Вы не владеете ни тем, ни тем, как ни прискорбно об этом говорить.
В принципе, можете почитать одного из практиков с четвертьвековым опытом — blog.ioshints.info/2011/12/is-nat-security-feature.html. Или вот, неплохая статья: habrahabr.ru/post/134638/ (хотя в ней делается допущение, которое маловероятно в реальной жизни, но все равно интересно).
И если ваша сетевая безопасность построена на PAT (по желанию добавить роутерные ACL), тут уж проблема в ДНК того, кто это придумал.
Эмм, бывают ситуации, когда по другому не сделаешь.
Дома? Возможно, если уж такое выбрано сетевое железо (вроде большинство хомячковых девайсов вообще не содержит функционала файрвола?), но там и требования соответствующие. На работе? Сомневаюсь. Всегда есть варианты. Даже опенсорсные.
Вот я являюсь абонентом Онлайм. Они дают пять глобально маршрутизируемых адресов на порт. Счастье? Нет: тут только transparent файрвол будет работать, а мне это неинтересно по ряду причин. А вот если бы они выдавали ровно один адрес, параллельно делая на остальные маршрут в сторону этого адреса и сказав «распоряжайтесь ими как хотите», это было бы великолепно, и у всех моих домашних устройств были бы глобально маршрутизируемые адреса. Ну ладно, не у всех, а у части, если адресов будет всего 4, но все равно приятно :)
Вот я являюсь абонентом Онлайм. Они дают пять глобально маршрутизируемых адресов на порт. Счастье? Нет: тут только transparent файрвол будет работать, а мне это неинтересно по ряду причин. А вот если бы они выдавали ровно один адрес, параллельно делая на остальные маршрут в сторону этого адреса и сказав «распоряжайтесь ими как хотите», это было бы великолепно, и у всех моих домашних устройств были бы глобально маршрутизируемые адреса. Ну ладно, не у всех, а у части, если адресов будет всего 4, но все равно приятно :)
На работе тоже. Например, если железка не тянет возросшую нагрузку при включении CBAC или стоит базовый IOS.
Грубый косяк архитектора. Если роутер не тянет CBAC/ZBPF, то значит, он и так работает с близкой к 100% утилизацией ЦП. Немного изменится характер трафика, и ЦП будет перегружен. Соответственно — закупить нормальное железо. Или хотя бы софтовым решением воспользоваться.
По поводу «базовый IOS» — такие отмазки напоминают мне обсуждение после крупной аварии «ну да, данный критический сервис надо было резервировать, но для этого требовалось что-то докупать, потому я решил, что лучше не надо».
По поводу «базовый IOS» — такие отмазки напоминают мне обсуждение после крупной аварии «ну да, данный критический сервис надо было резервировать, но для этого требовалось что-то докупать, потому я решил, что лучше не надо».
Большинство софтовых решений не заглядывает выше 4 уровня.
А ситуации бывают разные, у кого-то уже есть оборудование, кому-то по тендеру закупили железки без секурных лицензий. Даже в экзамене CCIE есть подобный вопрос (кто-то из антицисковцев писал), правильным ответом на который является использование RACL.
А ситуации бывают разные, у кого-то уже есть оборудование, кому-то по тендеру закупили железки без секурных лицензий. Даже в экзамене CCIE есть подобный вопрос (кто-то из антицисковцев писал), правильным ответом на который является использование RACL.
Все файрволы обязаны смотреть выше L4, и хардварный файрвол вовсе не функциональнее софтового, скорее наоборот, сложная логика обработки пакетов не поддается записыванию в ASICи и требует задействования обычного процессора общего назначения.
В случае NAT/PAT надо активно изменять данные уровня приложения (без этого будут большие проблемы с тем же VOIP). В случае инспектирования файрволом — не изменять, но анализировать пакет и открывать динамические порты по мере надобности, увидев в заголовке уровня приложения успешное согласование портов обеими сторонами.
Но даже на L4 есть много такого, чего не делает PAT, но что делать надо с точки зрения безопасности.
«А ситуации бывают разные» — они все сводятся к «инженер просрал все полимеры». И снова: всегда есть обходные пути.
RACL — это то, с чем, опять же, не будет работать ни один более-менее сложный протокол. Все равно придется разрешать весь UDP.
По экзамену CCIE — почему «даже»? Там очень много извращений. Лаба CCIE — это пример того, как НЕ надо строить продуктивные сети. Слишком сложно, слишком неочевидно, слишком ненадежно. Там другая задача — проверить понимание кандидатом работы отдельных протоколов и их связок в экстремальной ситуации, т.е. чем навороченнее, тем лучше. Ну и раз в блюпринте есть ACLы, надо как-то проверить их знание кандидатом. Пусть даже в надуманном сценарии. В конце концов, application-aware инспектирование не везде доступно. Если надо на каталисте сделать базовую фильтрацию доступа, то о полноценном файрволинге речи нет. Но мы вроде говорили о PAT? Никто не делает PAT на каталистах. Ну и никто не использует каталист для фильтрации трафика там, где атаки действительно вероятны.
В случае NAT/PAT надо активно изменять данные уровня приложения (без этого будут большие проблемы с тем же VOIP). В случае инспектирования файрволом — не изменять, но анализировать пакет и открывать динамические порты по мере надобности, увидев в заголовке уровня приложения успешное согласование портов обеими сторонами.
Но даже на L4 есть много такого, чего не делает PAT, но что делать надо с точки зрения безопасности.
«А ситуации бывают разные» — они все сводятся к «инженер просрал все полимеры». И снова: всегда есть обходные пути.
RACL — это то, с чем, опять же, не будет работать ни один более-менее сложный протокол. Все равно придется разрешать весь UDP.
По экзамену CCIE — почему «даже»? Там очень много извращений. Лаба CCIE — это пример того, как НЕ надо строить продуктивные сети. Слишком сложно, слишком неочевидно, слишком ненадежно. Там другая задача — проверить понимание кандидатом работы отдельных протоколов и их связок в экстремальной ситуации, т.е. чем навороченнее, тем лучше. Ну и раз в блюпринте есть ACLы, надо как-то проверить их знание кандидатом. Пусть даже в надуманном сценарии. В конце концов, application-aware инспектирование не везде доступно. Если надо на каталисте сделать базовую фильтрацию доступа, то о полноценном файрволинге речи нет. Но мы вроде говорили о PAT? Никто не делает PAT на каталистах. Ну и никто не использует каталист для фильтрации трафика там, где атаки действительно вероятны.
Что еще более обидно — таки оно в таком виде и не используется. А куда используется — хрен знает.
Вы заблуждаетесь, там все компьютеры имеют белый адрес из выделенных диапазонов.
Там — это где? в НР? Точно-точно?
Ага, недавно был у них на курсах — все компьютеры в классе имели адрес из 15 подсети. Если не верите, можете спросить у них в блоге.
Если бы 25% — обычно даже бывает, что целых 75%
Пример — клиенту дают «прямой» (то есть не через pppoe/pptp) IP-адрес в отдельном интерфейсе, для этого берется отдельная подсеть /30 — 4 адреса
1 — идентификатор сети (не используется)
2 — адрес его шлюза вешается на оборудование провайдера
3 — выдается клиенту
4 — броадкаст адрес (не используется)
Итого 3/4 адресов столь ценных уходит просто в «никуда». Сейчас конечно многое изменилось, но лет 5 назад такое было сплошь и рядом.
Пример — клиенту дают «прямой» (то есть не через pppoe/pptp) IP-адрес в отдельном интерфейсе, для этого берется отдельная подсеть /30 — 4 адреса
1 — идентификатор сети (не используется)
2 — адрес его шлюза вешается на оборудование провайдера
3 — выдается клиенту
4 — броадкаст адрес (не используется)
Итого 3/4 адресов столь ценных уходит просто в «никуда». Сейчас конечно многое изменилось, но лет 5 назад такое было сплошь и рядом.
Уж сколько на моей памяти было таких топиков, и каждый раз пророчили что вот-вот ещё чуть-чуть и адреса закончатся, интернет встанет и все виндоусы посыпятся синими окнами и вообще «проблема 2000» покажется детской забавой по сравнению с тем, что нам предстоит «вот буквально завтра».
Но месяцы переходят в годы, топики всё появляются, а IPv4 всё никак не кончается…
Но месяцы переходят в годы, топики всё появляются, а IPv4 всё никак не кончается…
Вы не понимаете. Это стадии происходящего.
Сначала все адреса раздали RIR'ам.
Потом RIR'ы ужесточили правила выдачи адерсов LIR'ам.
Теперь остались последние /8
Я лично год назад писал про скрипт для подсчёта числа свободных адресов. Год назад их было 57 миллионов. Прошло чуть-чуть больше года — и их осталось 16.7 миллионов.
Про дальнейшие рассчёты думайте сами.
Сначала все адреса раздали RIR'ам.
Потом RIR'ы ужесточили правила выдачи адерсов LIR'ам.
Теперь остались последние /8
Я лично год назад писал про скрипт для подсчёта числа свободных адресов. Год назад их было 57 миллионов. Прошло чуть-чуть больше года — и их осталось 16.7 миллионов.
Про дальнейшие рассчёты думайте сами.
upd, ссылка не запостилась: habrahabr.ru/post/96079/
Как же хочу ipv6 на домашнем провайдере. :(
Спросите. У меня уже почти три года как он есть (desunote.ru). Более того, именно ipv6 я использую для работы с гуглем и кучей других сайтов.
Ответ: «Можем и выдавать, но пока всё это всё равно заворачивается в IPv4, ибо почти никто не поддерживает сие счастье =)». Так что вот. А хочется прямое, нативное такое… Мягкое, белое и пушистое! :)
Как это выглядит технически? 2 PPP-соединения?
Почему? PPP соединение одно. v4 адрес назначается IPCP, v6 — IPv6CP. Это на роутере. На компьютере dual stack, общение с роутером и по v4, и по v6. В чем проблема-то?
Я не говорю, что есть какая-то проблема.
Мне, как и другим здесь читателям, интересно узнать, как устроена раздача IPv6 у реального провайдера в реальной ситуации.
Теоретизировать и цитировать документацию можно сколько угодно, но в реальности может быть совсем по-другому. Например, у покойного Волгателекома до запуска безлимитных тарифов было два PPP соединения (для внутреннего ФОСа и внешки), и абоненты сами мучались с маршрутизацией и оборудованием, не поддерживающем поднятие двух сессий.
Мне, как и другим здесь читателям, интересно узнать, как устроена раздача IPv6 у реального провайдера в реальной ситуации.
Теоретизировать и цитировать документацию можно сколько угодно, но в реальности может быть совсем по-другому. Например, у покойного Волгателекома до запуска безлимитных тарифов было два PPP соединения (для внутреннего ФОСа и внешки), и абоненты сами мучались с маршрутизацией и оборудованием, не поддерживающем поднятие двух сессий.
На всякий случай, отметая попытки логически обьяснить такую несуразность: ip-шник для внутренней ФОС давали «белый», просто он был изолирован от внешней сети фаирволом
Мне, как и другим здесь читателям, интересно узнать, как устроена раздача IPv6 у реального провайдера в реальной ситуации.
Мне реальный провайдер в реальной ситуации выдает порт ethernet, к которому я могу подключить 5 разных устройств (средствами свитча — даже роутер не требуется), и все они получат по глобально маршрутизируемому адресу. Без всяких VPN, PPPoE, любого вида аутентификаций и так далее. Когда у них появится IPv6 — просто будут выдавать еще и v6 адреса.
Потому, являясь абонентом провайдера, у которого все весьма красиво настроено, мне абсолютно накласть на всяких волготелекомов. Не умеют делать по-человечески — и ладно, меня это не заботит. Сейчас таких провайдеров уже немного осталось.
У тиеры выдаётся IPv6 адрес для компьютера/маршрутизатора и /64 для остального оборудования в доме.
DHCP?
/64 минимальный префикс для SA
Кстати — пройдет 200 лет, и потомки, в спешке мигрируя всю звездную систему на IPv16, будут долго крыть нас матом за такое транжирство адресного пространства. Да и при наличии схемы «один мак на миллион китайских роутеров» APIPA работает чуточку лучше…
Я бы не стал загадывать так далеко. Кроме того, что вы забыли за пределами атмосферы?
Я бы не стал загадывать так далеко.
В свое время IPv4 воевал с ISO CLNS за господство над миром. Кто выиграл — известно, одним из важных факторов победы была простота адреса — у CLNS адрес мог иметь длину от 8 до 20 байт, и умные головы решили «да ну его к черту, кому нужно такое огромное адресное пространство? Нам и 4-х байт хватит надолго».
Кстати, IPv6 имеет с CLNS куда больше общего, чем с IPv4.
Это будет успех. Поищите что-нибудь рукотворное в современном мире, чем люди массово и активно пользуются уже 200 лет.
Колесо? :)
Это кто же сейчас использует колесо, сделанное более 200 лет назад? Колеса сейчас делают больше из металла, шины придумывают разные, диски, смазку, подшипники и т.д.
В IPv6 нет ничего нового с точки зрения адресации, просто больше бит, чем в IPv6. Но, если им будут пользоваться 200 лет и только потом изменят — это будет успех.
В IPv6 нет ничего нового с точки зрения адресации, просто больше бит, чем в IPv6. Но, если им будут пользоваться 200 лет и только потом изменят — это будет успех.
Мосты/улицы/дороги. Их, конечно, ремонтируют…
О, если вас идеи интерсуют — латинский алфавит. Сколько лет там версии не меняли?
О, если вас идеи интерсуют — латинский алфавит. Сколько лет там версии не меняли?
Серьезно, много ли этих мостов, дорог, улиц без нового асфальта и капитального (слово-то какое) ремонта?
Почему-то людям мало одного словарного запаса, записанного латинскими буквами. Постоянно расширяют, удаляют.
В IPv6 все те же единицы и нули, что в IPv4. Их просто больше. Т.е., если отталкиваться от «алфавита»: изменений нет. А вот словарный запас явно изменился.
Почему-то людям мало одного словарного запаса, записанного латинскими буквами. Постоянно расширяют, удаляют.
В IPv6 все те же единицы и нули, что в IPv4. Их просто больше. Т.е., если отталкиваться от «алфавита»: изменений нет. А вот словарный запас явно изменился.
Я не хотел сказать, что долгоживущих вещей нет. Есть. Коран, Библия, тот же алфавит, производство самурайских мечей и т.д. Но все их отличает успех и некоторое отсутствие динамики.
Кому нужен сейчас новый алфавит? Большинству его хватает для записи звуков в виде знаков.
RIP уже не тот для большинства, но даже при этом придумали RIPng. 10 Мбит/с по коаксиалу уже не подходит для большинства. Архитектуры Pentium Pro недостаточно для текущих потребностей большинства. 640К всем не хватает.
Я хотел сказать, если IPv6 в столь динамичной отрасли просуществует 200 лет, по-моему, это будет успех.
Кому нужен сейчас новый алфавит? Большинству его хватает для записи звуков в виде знаков.
RIP уже не тот для большинства, но даже при этом придумали RIPng. 10 Мбит/с по коаксиалу уже не подходит для большинства. Архитектуры Pentium Pro недостаточно для текущих потребностей большинства. 640К всем не хватает.
Я хотел сказать, если IPv6 в столь динамичной отрасли просуществует 200 лет, по-моему, это будет успех.
RIP уже не тот для большинства, но даже при этом придумали RIPng.
Кто-то использует его для обмена маршрутами между сервером и роутером. А так да, сейчас значительно более эффективные протоколы.
10 Мбит/с по коаксиалу уже не подходит для большинства.
Потому возникли 100, 1000, 10G, 40G и т.д. плавно вверх.
Архитектуры Pentium Pro недостаточно для текущих потребностей большинства.
Архитектура Core основана на Pentium Pro, чего не скажешь про Pentium 4. А еще будущие интеловские дискретные видеокарты Knights Corner по сути являются массой маленьких пентиумпрошек в одном корпусе.
Я хотел сказать, если IPv6 в столь динамичной отрасли просуществует 200 лет, по-моему, это будет успех.
Но выше был пример как раз эволюционного развития. К IPv6 наверняка добавят массу других подпротоколов, напишут тысячи RFC. Но радикальных изменений не будет, слишком они сложны.
У тиеры в сети нет DHCP, только статика. Зато нет и mac-локинг. Воткнулся в порт — если настройки сети знаешь, можно пользоваться.
а у тебя там mediawiki говорит что хотет запустить скриптец после обновления
desunote.ru лег. Ни когда не слышал про этого провайдера.
А поддержка со стороны девайсов разве не требуется?
Зависит от того, чем эти «девайсы» занимаются.
Кабельный модем, например.
Там какая-то фагготрия с IP over ATM? Или DOCSYS?
Короче, если железка что-то знает про IP, то ей нужно знать и про IPv6. Если железка занимается L2, то IPv6 ей пофигу.
Короче, если железка что-то знает про IP, то ей нужно знать и про IPv6. Если железка занимается L2, то IPv6 ей пофигу.
DOCSYS лично у меня. Что-то про IP точно знает, хотя бы потому что сама откликается на 192.168.100.1 и раздаёт адреса из 192.168.100.x если кабель отключен.
Тогда потребуется апгрейт железа.
Причем не только CPE а также и самих CMTS. Железо там очень олдскульное и при этом довольно дорогое. Полностью менять существующую DOCSIS инфраструктуру для провайдера — полностью нереальный и не рентабельный ужас. В разы дешевле получится сконвертировать существующих абонентов в HCNA (что тоже бред) либо за свой же счет в FTTx. Ну либо 6to4 на худой конец.
P.S. Небыло там никогда «Y» — DOCSIS оно, Data Over Cable Service Interface Specifications.
P.S. Небыло там никогда «Y» — DOCSIS оно, Data Over Cable Service Interface Specifications.
Я все эти паллиативные технологии (модемы, ADSL, DOCSIS и т.д.) всегда считал уродством. Ethernet, нормальная коммутация, маршрутизация и всебщее счастье. Желательно либо в PON, либо активкой.
Ну, в 98-м году оно не так еще убого выглядело.
Лично у меня в то время было царствие Фидо и уже ближе к 99-му дайлап на 14400 в хорошую погоду. Также для разнообразия, можно повспоминать цены на Fast Ethernet решения в то же время (ух помню как я гордился настоящим соточным хабом(!) в то время).
Итого во времена разработки стандарта оно себя вполне себя оправдывало до середины 2000-х по соотношению цена/продуктивность. А при условии наличия существующей КТВ инфраструктуры было просто идеальным почти до середины 00-х как убийца ADSL, тем более с такими-то фичами которые умел DOCSIS в то время — полисинг, балансировка апстримов, довольно глубокое управление CPE и прочие вкусности.
Все что началось после этого — DOCSIS 3.0 (2008), HCNA — это просто слабые попытки оттянуть кончину технологии и дать операторам какое-то время на реорганизацию существующей сети под сегодняшние реалии.
Лично у меня в то время было царствие Фидо и уже ближе к 99-му дайлап на 14400 в хорошую погоду. Также для разнообразия, можно повспоминать цены на Fast Ethernet решения в то же время (ух помню как я гордился настоящим соточным хабом(!) в то время).
Итого во времена разработки стандарта оно себя вполне себя оправдывало до середины 2000-х по соотношению цена/продуктивность. А при условии наличия существующей КТВ инфраструктуры было просто идеальным почти до середины 00-х как убийца ADSL, тем более с такими-то фичами которые умел DOCSIS в то время — полисинг, балансировка апстримов, довольно глубокое управление CPE и прочие вкусности.
Все что началось после этого — DOCSIS 3.0 (2008), HCNA — это просто слабые попытки оттянуть кончину технологии и дать операторам какое-то время на реорганизацию существующей сети под сегодняшние реалии.
кстати, а доксис 3й то же ipv6 не умеет? я вот всю думаю, когда Воля в Киеве начнет уже чесаться по этому поводу.
а заодно когда всякие home-wide длинки, тплинки, линксисы и прочие начнут внедрять в роутеры ipv6…
а заодно когда всякие home-wide длинки, тплинки, линксисы и прочие начнут внедрять в роутеры ipv6…
Воля со своей кабельной инфраструктурой меня печалит каждый раз когда приезжаю в Киев.
Видеть подключение в 5Мбит, который даже не всегда гарантированный (при цене гарантированного на средних объемах), это как вернуться в 2007 год в Харькове.
А если еще вспомнить какой в Воле Кабель хамский саппорт и нежелание исправлять свои же косяки…
В общем желаю Воле скорой кончины…
Видеть подключение в 5Мбит, который даже не всегда гарантированный (при цене гарантированного на средних объемах), это как вернуться в 2007 год в Харькове.
А если еще вспомнить какой в Воле Кабель хамский саппорт и нежелание исправлять свои же косяки…
В общем желаю Воле скорой кончины…
качество Воли сильно зависит от района. у меня на кардачах воля с момента подключения падала два раза — один раз на сутки — кабло перерезали, второй тоже на около дня, но меня дома тогда не было. а так — вся моя купленная полоса честно есть
Просто у меня дома 100Мбит за 100грн/мес + цифровое ТВ.
При этом 90Мбит выжимаю спокойно всегда.
Это нормальная цена для домашнего канала.
И саппорт всегда готовый помочь, а не тот который постоянно предлагает перезагрузить компьютер по любой проблеме.
Я с Волей сталкивался и в Киеве и в Харькове.
Везде отвратительное впечатление.
При этом 90Мбит выжимаю спокойно всегда.
Это нормальная цена для домашнего канала.
И саппорт всегда готовый помочь, а не тот который постоянно предлагает перезагрузить компьютер по любой проблеме.
Я с Волей сталкивался и в Киеве и в Харькове.
Везде отвратительное впечатление.
Правильно ли я понимаю, что для того чтобы (оператору) работать с IPv6, нужно иметь аплинк, который может это IPv6 маршрутизировать, а также сам имеет IPv6-пиринги с другими IPv6-сетями?
… и home-wide «железный» роутер с ipv6 подержкой, который не стоит почти 300 баксов, да.
Кто-нибудь может сказать, что будет если хостер выдаст IPv6 вместо IPv4 и его привязать к доменному имени. Какие устройства/ОС не будут поддерживать (браузеры, мобильные браузеры, HTTP Client...)? Будет ли это зависеть от сети клиента? В общем, что плохого если внезапно сервер хостится на ipv6 (все равно люди обращаются к серверу по доменному имени в большинстве).
Если выдадут «вместо» — ничего хорошего не будет. (можете сами попробовать зайти на iv6.l.google.com/).
Первичная проблема не в мобильных устройствах и компьютерах, а в сетевом оборудовании и настройках ipv6 между операторами связи.
Правильным решением является настройка обоих адресов для сервера (и ipv4 и ipv6). В этом случае, у кого есть ipv6 — пойдут по ipv6, у кого есть ipv4 — пойдут по ipv4.
Первичная проблема не в мобильных устройствах и компьютерах, а в сетевом оборудовании и настройках ipv6 между операторами связи.
Правильным решением является настройка обоих адресов для сервера (и ipv4 и ipv6). В этом случае, у кого есть ipv6 — пойдут по ipv6, у кого есть ipv4 — пойдут по ipv4.
Cygwin, Windows 8, Санкт-Петербург, Avangard-DSL:
Мда, не всё так радужно…
Мой провайдер Ростелеком пока не предоставляет подключение IPv6. Какие сейчас «домашние роутеры» используются для IPv6 у тех кому это уже предоставляют провайдеры? Какая модель поддерживает «из коробки» и как это выглядит технически? (2 pppoe соединения или как-то еще)
Судя по тому, что я вижу в логах роутера (Asus WL-600g), IPv6 моему роутеру назначается (в технических подробностях не силён, но что-то про это есть). Однако прошивка IPv6 не умеет, и, похоже, уметь не планирует… Эх, кажется, выходной я проведу в попытках разобраться с DD-WRT…
IPv6 из коробки поддерживает AirPort Extreme. Точка даже может в случае необходимости зарегистрироваться в сети v6 через тоннель.
Не открывается
Открывается только по IPv6. Для ipv6.google.com (точнее, для ipv6.l.google.com.) нет A-записи.
а что мне надо сделать чтобы открыть «под IPv6»? Я не силен в предметной области. Локальный адаптер какой-то ipV6-адрес имеет. получает ли IPv6 от провайдера роутер — понятия не имею. В его веб морде ничего такого не нашел (tp-link 1043). По слухам провайдер (билайн) ipv6 таки поддерживает.
Билайн не предоставляет глобально-маршрутизируемые адреса для физических лиц (по крайней мере, не делает это через автоконфигурацию). Дефолтная прошивка tp-link wr1043nd, если я правильно помню, не умеет IPv6.
Однако, современные ОС умеют использовать Teredo для получения связности с IPv6-миром. В Windows можно попробовать ввести команду «netsh interface ipv6 set teredo client». В случае с большинством дистрибутивов GNU/Linux достаточно установить пакет miredo.
Совет позвонить в саппорт действительно отличный — чем больше клиентов будут хотеть IPv6, тем быстрее провайдеры начнут предпринимать для этого активные действия.
Однако, современные ОС умеют использовать Teredo для получения связности с IPv6-миром. В Windows можно попробовать ввести команду «netsh interface ipv6 set teredo client». В случае с большинством дистрибутивов GNU/Linux достаточно установить пакет miredo.
Совет позвонить в саппорт действительно отличный — чем больше клиентов будут хотеть IPv6, тем быстрее провайдеры начнут предпринимать для этого активные действия.
Значит, у вас есть проблемы со связностью ipv6 с гуглем. Можете позвонить в саппорт и спросить, почему у вас не работает ipv6.google,com.
Ну, тут вопрос сложный:
1) На одном IP дофига хостов может быть
2) Запас IPv4-адресов пока остаётся достоточно большой у хостеров.
3) Не будут поддерживать многие уже неподдерживаемые ОС, хотя для некоторых из них появятся официальные и не очень обновления/патчи/программки
4) Если мне не изменяет память, этот вопрос на Хабре уже обсуждался.
1) На одном IP дофига хостов может быть
2) Запас IPv4-адресов пока остаётся достоточно большой у хостеров.
3) Не будут поддерживать многие уже неподдерживаемые ОС, хотя для некоторых из них появятся официальные и не очень обновления/патчи/программки
4) Если мне не изменяет память, этот вопрос на Хабре уже обсуждался.
Во-первых большинство хостеров (особенно, в России) LIR'ы. Т.е. один уровень «резерва», считай, вычеркнут. Во-вторых скорость использования адресов (~40 миллионов за год) показывает, что оставшихся 16 миллионов, даже с трёхкратным запасом нахомяченного, хватит на год.
АААА дальше там начнётся утрамбовка. Думаю, ipv4 будут тянуть настолько долго, насколько можно будет трамбовать пользователей и сервисов в NAT'ы и в shared IP.
Тут следующие проблемы:
nat имеет ограниченный запас масштабирования. Новых адресов в пул брать негде.
сервера имеют лимит производительности, даже если это gateway с прокси-сервером, то есть набрать слишком много IP на адрес не удастся.
Плюс куча сайтов хочет https (читай — свой IP), плюс куча не-HTTP сервисов (от скайпа и IP-телефонии до онлайн игр).
Плюс нелюбовь к shared-хостингу (не зря мы одним из своих преимуществ в облаке считаем пока что бесплатные IP-адреса, по штуке на машину) — многие проекты в принципе не пойдут на shared.
Ещё одна проблема — это построение сетей. Пихать всюду серые адреса? До определённого предела можно, а дальше там возникает потолок.
Ну и главный аргумент: у одного жемчуг мелковат, у другого суп жидковат. Я к тому, что я знаю пару крупных проектов, у которых есть LIR и под реальное железо набирались адреса. Много адресов. При том, что сайт у них, дай бог, пару десятков IP использует.
А у других были выбраны все лимиты LIR'а по allocation на момент /8, а уже прямо сейчас нужно, например, 2-3 тысячи адресов.
Так что стресс начнётся много раньше, чем все IP-адрес уйдут в дело.
АААА дальше там начнётся утрамбовка. Думаю, ipv4 будут тянуть настолько долго, насколько можно будет трамбовать пользователей и сервисов в NAT'ы и в shared IP.
Тут следующие проблемы:
nat имеет ограниченный запас масштабирования. Новых адресов в пул брать негде.
сервера имеют лимит производительности, даже если это gateway с прокси-сервером, то есть набрать слишком много IP на адрес не удастся.
Плюс куча сайтов хочет https (читай — свой IP), плюс куча не-HTTP сервисов (от скайпа и IP-телефонии до онлайн игр).
Плюс нелюбовь к shared-хостингу (не зря мы одним из своих преимуществ в облаке считаем пока что бесплатные IP-адреса, по штуке на машину) — многие проекты в принципе не пойдут на shared.
Ещё одна проблема — это построение сетей. Пихать всюду серые адреса? До определённого предела можно, а дальше там возникает потолок.
Ну и главный аргумент: у одного жемчуг мелковат, у другого суп жидковат. Я к тому, что я знаю пару крупных проектов, у которых есть LIR и под реальное железо набирались адреса. Много адресов. При том, что сайт у них, дай бог, пару десятков IP использует.
А у других были выбраны все лимиты LIR'а по allocation на момент /8, а уже прямо сейчас нужно, например, 2-3 тысячи адресов.
Так что стресс начнётся много раньше, чем все IP-адрес уйдут в дело.
Мы (компания, в которой я работаю) и сами провайдер и LIR. Честно, захомячили адресов чуть больше чем было необходимо ранее, но зато теперь можно, пока что, не нервничать, даже учитывая то что у нас белая адресация и клиентам выдаются внешники (то есть, фактически, «серой» сети нет) =)
Да и многие другие компании обладают достаточным резервом чтобы успеть подготовиться. Так что, считаю, тут нет места для паники, только для трезвого мышления и холодного расчёта.
Да, у многих начнётся «утрамбовка». Да, закончится выдача «халявных» внешников. Но «агонией» я бы это всё не назвал. Будут, конечно, определённые проблемы, но ещё достаточно времени подготовиться
PS Доброе утро!)
Да и многие другие компании обладают достаточным резервом чтобы успеть подготовиться. Так что, считаю, тут нет места для паники, только для трезвого мышления и холодного расчёта.
Да, у многих начнётся «утрамбовка». Да, закончится выдача «халявных» внешников. Но «агонией» я бы это всё не назвал. Будут, конечно, определённые проблемы, но ещё достаточно времени подготовиться
PS Доброе утро!)
Плюс куча сайтов хочет https (читай — свой IP)Что не так с https? Потребности в ip ровно такие же как и в http, вешай сколько угодно виртуальных серверов.
Насколько я знаю, сайт предъявляет сертификат не по доменному имени. Или уже пофиксили?
Можно разные домены развесить по разным портам (всё равно вручную никто не набирает https-адрес)
Пофиксили, правда SNI en.wikipedia.org/wiki/Server_Name_Indication не всеми поддерживается
Полагаю нехватка IP адресов это достаточное обоснование военного конфликта.
В интересное время живем. На неделе нашему клиенту выделили /20 из 5.226. Наверное, больше никогда такого не увижу. В нагрузку буквально впихнули /32 IPv6.
Интересно, увижу ли чистый IPv6 интернет до пенсии…
Интересно, увижу ли чистый IPv6 интернет до пенсии…
Чистый — это когда все сайты по ipv6 работают, или когда последний ipv4 перестанет работать? Первое — да, второе — врят ли. До сих пор есть сайты на гопфере. Просто из принципа.
Хотя, я думаю, раньше 20-30 года говорить о прекращении поддержки ipv4 на оборудовании/сервисах не стоит. Миллионы (миллиарды) устройств, среди них куча старинных, но всё ещё работающих… И они — только ipv4.
Да что там говорить — кобол до сих пор в продакте…
Хотя, я думаю, раньше 20-30 года говорить о прекращении поддержки ipv4 на оборудовании/сервисах не стоит. Миллионы (миллиарды) устройств, среди них куча старинных, но всё ещё работающих… И они — только ipv4.
Да что там говорить — кобол до сих пор в продакте…
Это схоже с проблемой x64 — давно уже есть, а проги на такую архитектуру перевели далеко не все.
И x86 практически полностью исчезнет еще очень нескоро.
И x86 практически полностью исчезнет еще очень нескоро.
Не совсем так. i386 вы можете использовать сколько хотите. До тех пор, пока у вас есть софт и железо — нет проблем. Однако, с инетом не так — вам нужно не только «использовать», но и иметь возможность связаться с другими. А что делать, если этих «других» больше, чем число свободных адресов?
Потому что реально 64-битовые целые жрут кучу места, а для практических нужд требуются редко. 64-битовая адресация нужна тоже только для программ, которым надо очень-очень много памяти. В целом же за счет констант 64-битовый код минимум на 20% больше.
Неплохой сценарий для голливудского блокбастера получается.
Захватывающая битва двоеточий против точек? Хм.
Пост написан таким слогом, что просто веет могильным холодом. Для завязки триллера на компьютерную тематику — самое оно. А потом в сценарий врывается благородный герой Юнипер и в одиночку высвобождает все разом неиспользуемые IPv4 и передает обратно RIPE NCC. За что и получает от благодарного человечества подсеть 172.16.0.0/16 в единоличное безвременное пользование.
Ну и цисек парочку в сценарий, чтобы добавить любовной интриги.
Ну и цисек парочку в сценарий, чтобы добавить любовной интриги.
Вы знаете, для обывателя это ерунда, а вот я точно знаю, что мне, как технарю, придётся ппц как неудобно и дискомфортно в ближайшее время. Потому что мы вроде бы IPv6 поддерживаем всюду, но есть огромная куча мелочей, о которых надо думать.
Особые правила антиспуфинга, новые сертификаты для SSL поверх IPv6, поддержка ipv6 в каждой самой занюханной дырке.
Да что там говорить, у меня до сих пор wifi дома без ipv6.
Особые правила антиспуфинга, новые сертификаты для SSL поверх IPv6, поддержка ipv6 в каждой самой занюханной дырке.
Да что там говорить, у меня до сих пор wifi дома без ipv6.
Да я понимаю, есть опыт общения с сетевым оборудованием.
Насчет WiFi это да. Купил топовый на тот момент (1.5 года назад) рутер Asus rt-n66u или как то так. Так он v6 не разумеет…
rt-n66u поддерживает ipv6, если посмотреть описания официальных прошивок. Я уж не говорю о неофициальных.
Rt n56u конечно же, очепятк :(
66u это то что мне хочется купить теперь.
66u это то что мне хочется купить теперь.
В бета-версии оф.прошивки уже есть ipv6 (ASUS 3.0.0.3.116b firmware)
vip.asus.com/forum/view.aspx?id=20120426233524315&board_id=11&model=RT-N56U&page=1&SLanguage=en-us
vip.asus.com/forum/view.aspx?id=20120426233524315&board_id=11&model=RT-N56U&page=1&SLanguage=en-us
вот это смотрели? Советую code.google.com/p/rt-n56u/
Вот это смотрели? Советую code.google.com/p/rt-n56u/issues/detail?id=69
А зачем новые SSL-сертификаты для IPv6?
… задумался.
Да, вы правы. Нужно всего лишь переписать нафиг часть софта, которая по SSL слушает. А сертификаты можно старые.
Да, вы правы. Нужно всего лишь переписать нафиг часть софта, которая по SSL слушает. А сертификаты можно старые.
А у вас еще какой-то софт его не поддерживает?
Или писали не задумываясь об IPv6?
Я просто к тому что компания вы молодая и проблема с IP стояла уже тогда когда писали этот софт.
Я к примеру еще в 2008 писал панель управления VDS с поддержкой IPv6.
В 2009 уже применял эту поддержку.
Или писали не задумываясь об IPv6?
Я просто к тому что компания вы молодая и проблема с IP стояла уже тогда когда писали этот софт.
Я к примеру еще в 2008 писал панель управления VDS с поддержкой IPv6.
В 2009 уже применял эту поддержку.
Да, именно так. При том, что инфраструктура виртуализации/сети у нас ipv6 поддерживает, клиентам мы их выдаём, довольно большие куски нашей собственной инфраструктуры совершенно не готовы к ipv6. Просто потому, что об этом нужно было специально думать.
А дальше простая логика: добавить ipv6 в копоненту (например, управления адресами) — 3 часа на написание, час на review, три часа на тестирование.
Добавить более нужную и важную фич у — столько же.
Так что ipv6 всё так же болтается ниже планки «будем делать».
А дальше простая логика: добавить ipv6 в копоненту (например, управления адресами) — 3 часа на написание, час на review, три часа на тестирование.
Добавить более нужную и важную фич у — столько же.
Так что ipv6 всё так же болтается ниже планки «будем делать».
Может Майя как раз этот конец света предсказали 2012ом году???!!!
PI не выдают. А AS ещё есть шанс получить?
надо утрамбовывать. IPv4 должно хватить каждому второму человеку на Земле.
раздать их людям — по 1 в одни руки по паспортам, а люди как приватизационные сертификаты пусть за бутылку водки продают корпорациям. )))
раздать их людям — по 1 в одни руки по паспортам, а люди как приватизационные сертификаты пусть за бутылку водки продают корпорациям. )))
А PI-адреса (провайдеро-независимые) больше не выдаются. Уже сейчас.
Даже самую зачуханную /24 не дадут?
1) Примерно в течение полугода (вероятнее всего, меньше) закончатся нормальные запасы адресов LIR'ов
Я сомневаюсь. На русских RIPE митингах и трейнингах все спокойно делились, как (глагол вырезан цензурой) RIPE.
Пишут, например, что абонентов N тысяч уже и еще планируется рост в 10 раз, и нужно на каждого по IP, а сами сажают всех за NAT.
Или заявляют, что много-мега ДЦ построили и нужно просто на каждый юнит по 1 IP, а сами не засовывают в BGP адреса годами.
Примеры по каждому варианту находятся легко. Достаточно, например, взять по России LIR класса large.
Вот small и exta small может сильно задеть. Будут арендовать у large.
IMHO, IPv4 еще будет достаточно года 3, может, даже 5 лет. И только потом начнется острая нехватка у критического процента ISP.
Я это и имел в виду под «нормальные запасы». Нормальные — это когда можно продолжать выдавать адреса так, как будто они не заканчиваются.
Потом придётся думать и напрягаться.
Потом придётся думать и напрягаться.
А я имел в виду, что и через полгода, и через год, «влиятельная» часть ISP будет выдавать адреса так, как будто они не заканчиваются. А «невлиятельная» часть ISP не сможет склонить мир к IPv6. Потом перевес будет потихоньку смещаться и в какой-то критический момент пойдёт реальное внедрение IPv6. До этой точки, по-моему, год минимум.
Вы высказали своё предположение, я своё. У каждого свой опыт, своё представление. Две экспертные оценки.
Вы высказали своё предположение, я своё. У каждого свой опыт, своё представление. Две экспертные оценки.
IPv6 это конечно хорошо. Только вот запоминать адреса тяжело.
А машину кто чинить будет?
Сервер 172.17.66.43 послал неверный ответ по радиусу серверу 192.168.255.231, из-за чего отвалилась синхронизация между 10.168.191.192 и DNS-сервером 96.211.4.77. В результате мы их всех сейчас назваем по IP.
Сервер 172.17.66.43 послал неверный ответ по радиусу серверу 192.168.255.231, из-за чего отвалилась синхронизация между 10.168.191.192 и DNS-сервером 96.211.4.77. В результате мы их всех сейчас назваем по IP.
Даже с IPv4 тут есть большие проблемы.
Однажды у нас полностью слетела DNS зона (сбой реплицировался на все DNS сервера). Было весьма забавно наблюдать, как практически все серверные админы судорожно копают записи в поисках IP адресов своих систем. Даже сервер бекапа далеко не сразу отыскали. Как выяснилось, только бравые парни сетевики абсолютно плевали на DNS, ибо помнят адреса интерфейсов всех критических железок и серверов в своей зоне ответственности, а что не помнят, то записано прямо в securecrt.
Однажды у нас полностью слетела DNS зона (сбой реплицировался на все DNS сервера). Было весьма забавно наблюдать, как практически все серверные админы судорожно копают записи в поисках IP адресов своих систем. Даже сервер бекапа далеко не сразу отыскали. Как выяснилось, только бравые парни сетевики абсолютно плевали на DNS, ибо помнят адреса интерфейсов всех критических железок и серверов в своей зоне ответственности, а что не помнят, то записано прямо в securecrt.
Я наизусть помню адреса всех критических серверов. Вспоминать что сервер 312 это такой-то IP — нет, но management-сервер (и его IPMI), несколько важных сервисов — обязательно.
Так же как IP шлюзов до них.
Так же как IP шлюзов до них.
Я наизусть помню адреса всех критических серверов.
И это замечательно!
Но у нас серверные админы считали DNS чем-то незыблемым, вечным. Как только он скопытился — возникла совершенно «непредвиденная» проблема. Например, windows-админы не знают по адресу ни единого контроллера домена, а вот я почему-то помню почти все, хотя к моей епархии они вообще никаким боком.
У APNIC фаза последней /8 началась еще в прошлом апреле
Тут недавно кто-то обнаружил что у одного из гражданских министерств UK выделенный им блок /8 (51.0.0.0) уже много лет стоит никем не использованный (ни единого устройства в этом диапазоне).
Так что резервы еще есть :)
Так что резервы еще есть :)
blog.jgc.org/2012/09/the-uk-has-entire-unused-ipv4-8-that-is.html
Интереснее рыночная оценка этой сети.
Интереснее рыночная оценка этой сети.
5) Рынок юрлиц, у которых из активов только печать, да блок PI/LIR-статус станет расти (передача IP между компаниями не является продажей и может быть завёрнута RIPE NCC)
Что?
Что?
С момента последнего трейнинга RIPE NCC что-то могло поменяться, но тогда говорили, что для передачи адресов от одного LIR другому требуется justify requirements. И если нет, RIPE может забрать отдаваемые адреса в общий пул.
Тем, кому нужно, это не опасно (если только justify не станут делать драконовскими), а вот сквотерам придётся напрячься.
Кроме того, могут начать требовать анонса какого-то процента выданных/переносимых адресов.
Тем, кому нужно, это не опасно (если только justify не станут делать драконовскими), а вот сквотерам придётся напрячься.
Кроме того, могут начать требовать анонса какого-то процента выданных/переносимых адресов.
Последний IP будет выдан 21.12.12?
Ха! Вот и разгадка!
Это просто бородатый админ. Он показывает язык и говорит: «Идите в сад, задолбали спрашивать! Белых ip-шников больше нет! все за NAT!»
Это просто бородатый админ. Он показывает язык и говорит: «Идите в сад, задолбали спрашивать! Белых ip-шников больше нет! все за NAT!»
Понятно чем это грозит для разработчиков, а что насчёт обычных юзеров?
В ближайшие 2 года — только возможным ростом цен на «белые IP'шники». Дальше — надо смотреть, как все будут адоптироваться.
Сначала конец халявы со статическими IP (ребут и новый айпишник надо сообщать друзьям, чтобы к серваку CS могли подключиться), потом с динамическими (всех за NAT загонят). Как следствие перестанут нормально работать p2p-сети, различные домашние сервера (включая удаленный рабочие столы и т. п.). В общём любой доступ, инициированный извне. Для передачи данных между двумя обычными юзерами нужен будет посредник, к которому они оба будут коннектиться сами, а не ждать когда один из них законнектиться к другому.
Как раз в p2p доля ipv6 совершенно неприличная. И Ipv6 == white IP for free народ быстро понял.
Я бы уже не назвал тех, кто знает, что такое white IP. «обычными юзерами».
Но скорость там никакая, так как 99% пиров идут через he.net.
«на 8.8.11 было свободно: 58932064 адресов. (58 миллионов)
14.09.12 осталось только 17532480 (17 миллонов)»
Если бы вы разбили большое число на разряды (58932064 → 58 932 064), то не пришлось бы делать приписки в скобках :)
14.09.12 осталось только 17532480 (17 миллонов)»
Если бы вы разбили большое число на разряды (58932064 → 58 932 064), то не пришлось бы делать приписки в скобках :)
Скажите. А вот если, например, человек захотел купить себе выделенный сервер и поднять на нем vpn, чтобы ходить куда-нибудь в интернет через него. Если вот через год все адреса закончатся, то он не сможет это провернуть?
И вот мне как обывателю с ноутбуком что нужно делать для того, чтобы ходить в ipv6 сети?
И вот мне как обывателю с ноутбуком что нужно делать для того, чтобы ходить в ipv6 сети?
Если ему выделили адрес, то адрес никуда не денется. А вот новый может быть не удастся подключить (вероятнее всего, будет дороже).
На любой совмременной ОС вам как обывателю нужно только иметь современную ОС и современное бытовое сетевое оборудование.
Дальше оно там само. И stateless dhcp, и обычный dhcp.
На любой совмременной ОС вам как обывателю нужно только иметь современную ОС и современное бытовое сетевое оборудование.
Дальше оно там само. И stateless dhcp, и обычный dhcp.
У меня вот тут test-ipv6.ru/ говорит, что все ок кроме «Тест использования IPv6 DNS сервером вашего провайдера». Можете на пальцах пояснить что это значит для меня? И еще две таких штуки:
«Похоже, вы используете публичный 6to4 шлюз. Возможно, ваш роутер предоставляет его автоматически. Подобные публичные шлюзы не имеют соглашения об уровне технических услуг, что может превести к потери производительности. Лучше будет использовать родной IPv6 адрес от вашего провайдера ISP»
«Ваш DNS сервер (возможно, предоставляемый вашим провайдером) не имеет доступ к IPv6 интернету или не настроен на это. Это может ограничить ваш доступ к только IPv6 сайтам в будущем»
«Похоже, вы используете публичный 6to4 шлюз. Возможно, ваш роутер предоставляет его автоматически. Подобные публичные шлюзы не имеют соглашения об уровне технических услуг, что может превести к потери производительности. Лучше будет использовать родной IPv6 адрес от вашего провайдера ISP»
«Ваш DNS сервер (возможно, предоставляемый вашим провайдером) не имеет доступ к IPv6 интернету или не настроен на это. Это может ограничить ваш доступ к только IPv6 сайтам в будущем»
«Рост», но «расти».
1) Об эффективности использования IP:
черный — не рутабильные (спец. адреса)
красный — их не анонсируют в Интернет
зеленый — запас
серый — адреса которые реально используют
2) Посмотреть что доступно через IPv6 можно через прокси
Top Sites in Russia http://www.alexa.com/topsites/countries/RU
The requested site does not appear to have an IPv6 address:
— yandex.ru
— mail.ru
— odnoklassniki.ru
— liveinternet.ru
— rambler.ru
— rutracker.org
IPv6 enabled:
— vk.com
О чем это говорит?
черный — не рутабильные (спец. адреса)
красный — их не анонсируют в Интернет
зеленый — запас
серый — адреса которые реально используют
2) Посмотреть что доступно через IPv6 можно через прокси
Top Sites in Russia http://www.alexa.com/topsites/countries/RU
The requested site does not appear to have an IPv6 address:
— yandex.ru
— mail.ru
— odnoklassniki.ru
— liveinternet.ru
— rambler.ru
— rutracker.org
IPv6 enabled:
— vk.com
О чем это говорит?
Интересно, кто нибудь в курсе, будут раскулачивать крупных провайдеров который в свое время отжали по /8, а то и парочку? Или конторы которые «продают» айпи адреса?
будут раскулачивать крупных провайдеров который в свое время отжали по /8, а то и парочку?
Разумеется — нет. С какой стати?
Ну например с такой что по статистике около 50 процентов адресного пространства не используется. К примеру, у нас есть своя /16. Использована на 90 процентов. И есть реальная потребность в айпи адресах хоть мы и начали миграцию на ipv6.
Почему бы не рускулачить их и не дать возможность использовать ресурсы?
Почему бы не рускулачить их и не дать возможность использовать ресурсы?
Почему бы не рускулачить их и не дать возможность использовать ресурсы?
Вы вообще понимаете, что говорите?
«У Абрамовича есть яхта, а у меня нет. Давайте ее у него отберем».
Разница лишь в том что ip адреса не личная их собственность. Прочитайте условия получения адресного пространства.
Разница лишь в том что ip адреса не личная их собственность.
Это неважно.
Прочитайте условия получения адресного пространства.
Условия получения есть. Условий отнятия я почему-то не видел. И кроме того, в те времена, когда одна компания запросто могла отжать себе /8, условия явно были другими.
По факту, PI Блоки все же являются собственностью. Их нельзя просто отобрать на основании «другие голодают».
Точно нельзя отобрать IP-адреса? Вроде за IP-адреса не платят, их получают в RIPE бесплатно. Платят за membership и membership взносы тем больше, чем больше у вас IP-адресов (так как чем больше адресов, тем более крупный member)
Поставим вопрос по-другому.
/8 блоки принадлежат либо государственным структурам, либо крайне крупным коммерческим компаниям. У американского минобороны я насчитал аж одиннадцать /8 блоков. Как вы представляете себе их раскулачивание? Ну или раскулачивание Apple, ибо они тоже вряд ли используют свой блок целиком.
Если даже какие претензии возникнут — ну начнут владельцы их анонсить, ну запихнут их в одну железку, чтобы та на пинги отзывалась. Тут уж ну совсем никак не прикопаешься.
Однако, кто-то может сделать жест доброй воли и вернуть свой блок. Но опять же, сугубо добровольно.
/8 блоки принадлежат либо государственным структурам, либо крайне крупным коммерческим компаниям. У американского минобороны я насчитал аж одиннадцать /8 блоков. Как вы представляете себе их раскулачивание? Ну или раскулачивание Apple, ибо они тоже вряд ли используют свой блок целиком.
Если даже какие претензии возникнут — ну начнут владельцы их анонсить, ну запихнут их в одну железку, чтобы та на пинги отзывалась. Тут уж ну совсем никак не прикопаешься.
Однако, кто-то может сделать жест доброй воли и вернуть свой блок. Но опять же, сугубо добровольно.
В IPv4 есть возможность расширять заголовок, добавить до 40 байт. И эти байты можно использовать как расширение адреса, причем адреса можно расширять динамически, как телефонные номера. Интересно, почему так не сделали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Начало агонии IPv4: last /8