Jump to content
Калькуляторы

Nat IPv4 to IPv6 Трансляция адресов v4 -> v6

Добрый день.

Подскажите, есть ли у кого опыт 1:1 NAT IPv4 в IPv6 ?

Смысл этого действа в поддержке "старого" оборудования.

например выдать пользователю сеть 10..0.0.0/24 и 1:1 странслировать в IPv6 ?

Бывают ли для этого специализированные железки ?

Есть смысл этого действа или есть более грамотный путь NOT IPv6 Ready ?

Edited by kww

Share this post


Link to post
Share on other sites

Вы думали прежде чем написать?)

 

Какой пользователю толк с доступа к одной не полной /32 подсести ИПв6 интернета?

Не полной, потому что от туда вычтут 127/8, 169..., 10/8, 172.. 224/8 - короче зарезервированные подсети.

И что делать с частью интернета /32, когда на одного пользователя/дом рекомендуют /64 давать, как минимальную единицу?

 

 

Вот транслировать кусок в6 в в4 смысл имеет, и технически это не сильно сложно.

Но и это имеет смысл для того чтобы админить старое оборудование с хостов у котороых только в6.

Или например принтер сетевой/принтсервер только в4, а печатать хочется всем, а у всех только в6, и то есть другие варианты выхода из этого положения.

Share this post


Link to post
Share on other sites
Вот транслировать кусок в6 в в4 смысл имеет, и технически это не сильно сложно.

Но и это имеет смысл для того чтобы админить старое оборудование с хостов у котороых только в6.

Или например принтер сетевой/принтсервер только в4, а печатать хочется всем, а у всех только в6, и то есть другие варианты выхода из этого положения.

Какие есть еще варианты допустим с тем-же старым принтсервером ?

Share this post


Link to post
Share on other sites

Подозреваю, что можно, например, для application level сделать прокси.

 

Например, юзер из "серой" сети резолвит запись AAAA, которая преобразуется в фиктивную A по определенной таблице.

 

И если он обращается к http (imap,pop3 и т.п.), то попадает на прокси ( или nat, редиректор портов и т.п.) , который уже соединяет его с хостом в ipv6.

 

Соответственно, таблица трансляции через некоторое время очищается (например, через ttl той DNS записи, которая отдаётся на подмену AAAA)

Edited by marikoda

Share this post


Link to post
Share on other sites
Какие есть еще варианты допустим с тем-же старым принтсервером ?
Конкретно с ним - держать сервер с двойным стёком, на котором настроить службу печати либо просто редирект отдельных портов.

Я планирую дописать ноду к фряхе для в4, отдельный от ядра в4 стёк, чтобы формально можно было иметь только в6 в системе, но получать доступ и к в4.

 

 

 

Подозреваю, что можно, например, для application level сделать прокси.

 

Например, юзер из "серой" сети резолвит запись AAAA, которая преобразуется в фиктивную A по определенной таблице.

 

И если он обращается к http (imap,pop3 и т.п.), то попадает на прокси ( или nat, редиректор портов и т.п.) , который уже соединяет его с хостом в ipv6.

 

Соответственно, таблица трансляции через некоторое время очищается (например, через ttl той DNS записи, которая отдаётся на подмену AAAA)

Вряд ли такое будет, слишком трудоёмко.

 

Share this post


Link to post
Share on other sites
Вряд ли такое будет, слишком трудоёмко.
Нечто подобное уже есть в Linux для ipv4 - это conntrack и всякие nat модули для ftp, sip, gre и т.п.

 

Share this post


Link to post
Share on other sites
Какие есть еще варианты допустим с тем-же старым принтсервером ?

Либо NAT64, либо простой юзерспейсный перенаправитель соединений типа 6tunnel.

Share this post


Link to post
Share on other sites
Нечто подобное уже есть в Linux для ipv4 - это conntrack и всякие nat модули для ftp, sip, gre и т.п.
Это говорит о том, что вы сами руками протоколы не щупали ни разу, а только админите потоки трафика.

 

То что у вас в линухе называется коннтрак модули во фре это либы от либалиас.

Это костыли чтобы правильно натить протоколы у которых л3 адрес передаётся в самом протоколе и необходим для его правильной работы.

Они меняют 1 ип адрес на другой, в некоторых случаях кое что ещё делают.

При том, что ип адреса имеют одинаковую длину.

 

 

А теперь: что делать когда длинна ип адреса разная?)

Или ещё лучше: как в ДНС АААА в А превращать?

 

Ещё интереснее, это то, что в хтмл прочем внедрённом и связанном с ним коде, коий бывает и на джаве, и даже зашифрованный, бывает зашит ип адрес, вместо днс имени.

Те придётся парсить регэкспом кучу всего и менять.

А поскольку заменяется на более длинное, то это ещё доп расходы памяти и ресурсов.

 

 

 

Короче говоря: даже NAT64 вряд ли можно использовать в операторском продакшене, либо сразу заявлять что ваши проблемы от пользования этим мы решать не станем: работает - повезло, не работает - так и должно быть.

Хотя это вполне простой, прямой и понятный костыль, с вполне понятными проблемами и решениями/их отсутствием.

NAT46 - полное глюкалово (если привязываться к днс для трансляции), либо крайне ограниченное решение.

 

 

По поводу хтмл, с не вшитыми ип адресами есть идея:

достаточно чтобы шлюз был с двойным стёком, и просто держать на нём прокси, хотя бы тот же сквид.

Если предполагается что в6 клиент хочет к в4 по ип подключится, то возможно нужно будет мутить реврайтер адресов в сквиде, а клиент будет писать что нибудь типа: 192.168.0.1.v4 - чтобы браузер у прокси спрашивал по имени и без недоумений.

Share this post


Link to post
Share on other sites
То что у вас в линухе называется коннтрак модули во фре это либы от либалиас.

Это костыли чтобы правильно натить протоколы у которых л3 адрес передаётся в самом протоколе и необходим для его правильной работы.

Они меняют 1 ип адрес на другой, в некоторых случаях кое что ещё делают.

При том, что ип адреса имеют одинаковую длину.

Не соглашусь. Хелперы, например, для ftp или sip меняют один адрес на другой в текстовом протоколе, т.е. длина вполне может оказываться разной.

 

А теперь: что делать когда длинна ип адреса разная?)

Или ещё лучше: как в ДНС АААА в А превращать?

Выше про это писал: держать таблицу трансляции вида

AAAA запись - "серый" адрес и чистить ее через некоторое время.

Что-то вроде NAPT, то еще круче и сложнее :)

 

Ещё интереснее, это то, что в хтмл прочем внедрённом и связанном с ним коде, коий бывает и на джаве, и даже зашифрованный, бывает зашит ип адрес, вместо днс имени.

Те придётся парсить регэкспом кучу всего и менять.

А поскольку заменяется на более длинное, то это ещё доп расходы памяти и ресурсов.

В 95% случаев там будет доменное имя, в остальных можно сделать трансляцию вручную.

 

Короче говоря: даже NAT64 вряд ли можно использовать в операторском продакшене, либо сразу заявлять что ваши проблемы от пользования этим мы решать не станем: работает - повезло, не работает - так и должно быть.

Хотя это вполне простой, прямой и понятный костыль, с вполне понятными проблемами и решениями/их отсутствием.

NAT46 - полное глюкалово (если привязываться к днс для трансляции), либо крайне ограниченное решение.

Глюкало - согласен. Но тут же вроде разговор о proof of concept ?
По поводу хтмл, с не вшитыми ип адресами есть идея:

достаточно чтобы шлюз был с двойным стёком, и просто держать на нём прокси, хотя бы тот же сквид.

Если предполагается что в6 клиент хочет к в4 по ип подключится, то возможно нужно будет мутить реврайтер адресов в сквиде, а клиент будет писать что нибудь типа: 192.168.0.1.v4 - чтобы браузер у прокси спрашивал по имени и без недоумений.

Ну это и так понятно.

Дело ведь в том, что не только http прокотол используются.

 

Share this post


Link to post
Share on other sites
Или ещё лучше: как в ДНС АААА в А превращать?
Это проблема решённая, см. DNS64 (который используется в комплекте с NAT64).

AAAA для не имеющих её хостов придумывается на ходу из "NAT64 prefix + IPv4".

 

Ещё интереснее, это то, что в хтмл прочем внедрённом и связанном с ним коде, коий бывает и на джаве, и даже зашифрованный, бывает зашит ип адрес, вместо днс имени.
Тут да, ничего не поделаешь.

 

Те придётся парсить регэкспом кучу всего и менять.

А поскольку заменяется на более длинное, то это ещё доп расходы памяти и ресурсов.

Во-первых малореальная перспектива, гнать весь поток HTTP через умный парсер на регэкспах, чтобы тот не захлебнулся при этом (или отдельный кластер специально под эту задачу?)

Во-вторых, лезти руками чего-то реплейсить в пользовательском трафике - слишком высока вероятность поломать кучу вещей. Что если я читаю страницу, где просто перечисляются через запятую ради информации какие-то IPv4-адреса. Или мне на личный ящик прислали E-Mail с инструкциями по подключению к офисному почтовому серверу (из офиса с другого провайдера). Что с контрольными суммами, GPG-подписями? И т.д.

В общем поскольку буквальные IPv4 в страницах заменять слишком чревато проблемами (да и лезти в чужой трафик по сути искажая его - это зло), никто этого делать не собирается, и с NAT64 они просто не будут работать, се ля ви.

Впрочем и без них в целом можно жить, см. http://tools.ietf.org/html/draft-arkko-ipv...y-experience-02

Точнее, IPv4-адреса в HTML - самая меньшая из проблем в конфигурации v6-only + NAT64. Большая - старый v4-only софт.

 

Короче говоря: даже NAT64 вряд ли можно использовать в операторском продакшене
Абсолютно верно, в одиночку нельзя, но при желании можно как дополнение к dual stack.
Edited by rm_

Share this post


Link to post
Share on other sites
Или ещё лучше: как в ДНС АААА в А превращать?
Это проблема решённая, см. DNS64 (который используется в комплекте с NAT64).

AAAA для не имеющих её хостов придумывается на ходу из "NAT64 prefix + IPv4".

Мы обсуждали вариант строго обратный, как для малого числа клиентов, которые умеют только ipv4 (старое железо, старые OS и т.п.) обеспечить доступ к хостам, умеющим только ipv6.

Т.е. если в nat64 клиент имеет адрес ipv6, а сервер ipv4, то в данном случае - наоборот.

Edited by marikoda

Share this post


Link to post
Share on other sites
Не соглашусь. Хелперы, например, для ftp или sip меняют один адрес на другой в текстовом протоколе, т.е. длина вполне может оказываться разной.
Если новая меньше - вполне можно забить чем нибудь типа пробелов.

 

 

Выше про это писал: держать таблицу трансляции вида

AAAA запись - "серый" адрес и чистить ее через некоторое время.

Что-то вроде NAPT, то еще круче и сложнее :)

Видел.

Это не поможет тем, кто ДНС не использует.

Не считая что кроме А записей в днс есть другие типы записей с адресами.

Но для простых случаев, типа емаил клиентов, должно сработать.

 

 

 

В 95% случаев там будет доменное имя, в остальных можно сделать трансляцию вручную.
Только если для себя любимого.

 

 

Ну это и так понятно.

Дело ведь в том, что не только http прокотол используются.

Кто не обучен через хттп/сокс(?) прокси работать - тот и не сможет работать.

 

 

Во-первых малореальная перспектива, гнать весь поток HTTP через умный парсер на регэкспах, чтобы тот не захлебнулся при этом (или отдельный кластер специально под эту задачу?)

Во-вторых, лезти руками чего-то реплейсить в пользовательском трафике - слишком высока вероятность поломать кучу вещей. Что если я читаю страницу, где просто перечисляются через запятую ради информации какие-то IPv4-адреса. Или мне на личный ящик прислали E-Mail с инструкциями по подключению к офисному почтовому серверу (из офиса с другого провайдера). Что с контрольными суммами, GPG-подписями? И т.д.

В общем поскольку буквальные IPv4 в страницах заменять слишком чревато проблемами (да и лезти в чужой трафик по сути искажая его - это зло), никто этого делать не собирается, и с NAT64 они просто не будут работать, се ля ви.

Впрочем и без них в целом можно жить, см. http://tools.ietf.org/html/draft-arkko-ipv...y-experience-02

Точнее, IPv4-адреса в HTML - самая меньшая из проблем в конфигурации v6-only + NAT64. Большая - старый v4-only софт.

Я и не думал даже применять такой изврат с регэкспами для продакшена в исп, это максимум на шлюзе дома/офисе, или для тех персонала чтобы со старым железом работать.

в4 адреса, отличные от адреса откуда идёт траф по идее трогать и не нужно. А нужно править только которые http://ip, чтобы корректно веб интерфейс отрабатывал.

Старый в4 софт - сможет относительно относительно без проблем;но жить в локалках

 

Share this post


Link to post
Share on other sites
чтобы со старым железом работать.
Только что решал как раз эту проблему.

Имеется: точка доступа, не уразумеющая IPv6. Зато имеющая v4-адрес 192.168.1.1.

На сервере в одной с нею сети выполняю:

ADDR=2001:470:989e::1:1
ip addr add $ADDR/64 dev eth0 preferred_lft 0
6tunnel -L $ADDR -6 -4 80 ::ffff:192.168.1.1 80

Добавляю в DNS:

wrv200  86400  IN  AAAA  2001:470:989e::1:1

Всё, теперь эту ТД можно админить по IPv6 из любой точки Интернета (если бы это было разрешено моим файрволлом).

http://ompldr.org/vNzQ3dA/2011-01-23T155704Z-wrv200.png

 

Могло бы не получиться, если бы ТД в генерируемом HTML упоминала свой буквальный v4-адрес - но к счастью она этого не делает, покликал по страницам веб-интерфейса, все пути ссылок и отправки форм везде относительные, всё работает.

Edited by rm_

Share this post


Link to post
Share on other sites

Я думаю просто транслятор/натилку поставить 6-4, без фаерволинга и пр.

Нода с автономным от ядра в4 стёком позволит в ядре в4 не держать, лет через 5-10 это будет актуально.

Как представляю можно будет анонсить в сеть этот транслятор как дефолтшлюз для определённого префикса.

В можно будет даже кучу таких трансляторов держать, при необходимости, для отказоустойчивости или распределения нагрузки.

 

 

Вообще, думаю китайцы наклепают таки коробочек в6-4, рублей по тыще.

Мозгов там особо не нужно, памяти не нужно (таблицу трансляций держать нет необходимости), настроек почти никаких.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this