среда, 28 марта 2012 г.

Первые шаги в IPv6. NAT64

Пришло время руками пощупать грядущий протокол и озадачится вариантами предстоящего в не столь далеком будущем внедрения. Для первой заметки на тему IPv6 решил таки описать вариант организации NAT64 на базе сервера под управлением Ubuntu 11.10 для обеспечения IPv6 only хостов в IPv4 сеть. Не исключено, что местами будут допущены некоторые ошибки - ввиду первого опыта ковыряния подобных решений.

Итак задача - обеспечить IPv6 only хосту доступ к IPv4 only ресурсам. Требуется всего самая малость - преобразовать совместимо v4 адреса в v6 и на маршрутизаторе транслировать их в заданном направлении. Для решения задачи потребуется:

  1. Сервер под управлением какого-либо дистрибутива Linux (в данном случае Ubuntu 11.10) (http://www.ubuntu.com/)
  2. DNS64 для подмены/добавления транслированных v4 в v6 адресов, чтобы конечный IPv6 хост знал направление дальнейшего движения. В примере использован Bind 9.8 (http://www.isc.org/software/bind) (собственно именно с версии 9.8 он и поддерживает требуемый функционал).
  3. NAT64 в реализации tayga (http://www.litech.org/tayga/)
  4. Блок адресов и связность с v6 для маршрутизатора. В примере использован туннельный брокер компании NetAssist (http://tb.netassist.ua/), хотя можно, например, воспользоваться брокером Hurricane Electric (http://tunnelbroker.net/).
  5. Linux IPv6 Router Advertisement Daemon aka radvd (http://www.litech.org/radvd/)
  6. ISC DHCP Daemon version >=4 (http://www.isc.org/software/dhcp)
Все пакеты ставились из базовых репозиторием при помощи apt-get. Исключение bind - за версией 9.8 пришлось сбегать в пул с пакетами ubuntu и взять свежий. Лично я брал тут.
Не вижу смысла расписывать сам процесс настройки туннеля - ибо у обоих предложенных брокеров есть инструкции ко всевозможным случаям, включая интересующий Linux. Приведу лишь в качестве цитаты пример для конкретного туннеля от NetAssist:

modprobe ipv6
ip tunnel add netassist mode sit remote 62.205.132.12 local x.x.x.x ttl 200
ip link set netassist up
ip addr add 2a01:da:ffff:2d9::2/64 dev netassist
ip route add ::/0 dev netassist
ip -f inet6 addr
 Итак. Будем считать, что туннель поднят и работает. Необходимо выдать конфигурацию внутренним абонентам. Для этого настроим внутренний интерфейс, radvd и dhcp.
Для начала из пула, который выдал нам туннельный брокер (в моем случае 2a01:da:80d0::/48) отрежем блок 2a01:da:80d0::/64.
Интерфейс:
ifconfig eth1 inet6 add 2a01:da:80d0::1/64
Настроим radvd для автоконфигурации интерфейсов (/etc/radvd.conf):

interface eth1 {
        AdvSendAdvert on;
        AdvOtherConfigFlag on;
        AdvManagedFlag off;
        AdvLinkMTU 1280;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix 2a01:da:80d0::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
        RDNSS 2a01:da:80d0::1
        {
        };
};
Пропишем в /etc/sysctl.conf:
net.ipv6.conf.all.forwarding = 1
И применим:
sysctl -p
Можно запускать:
/etc/init.d/radvd start
Если прошло без ошибок - замечательно. Иначе - искать ошибку и чинить.
Далее настроим dhcp для одной единственной цели - отдавать клиентам Windows адрес DNS сервера, который через RDNSS они получать не умеют. В связи с чем конфиг довольно прост (/etc/dhcp/v6_eth1):
authoritative;
log-facility local7;
ddns-update-style none;
ignore client-updates;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
option dhcp6.rapid-commit;
option dhcp6.name-servers 2a01:da:80d0::1;
option dhcp6.domain-search "mylocal.net";
option dhcp6.preference 255;
option dhcp6.info-refresh-time 21600;
dhcpv6-lease-file-name "/var/lib/dhcp/dhcpd6.leases";


subnet6 2a01:da:80d0::/64 {
   range6 2a01:da:80d0::2 2a01:da:80d0::FF;
}
Создаем /var/lib/dhcp/dhcpd6.leases:
touch /var/lib/dhcp/dhcpd6.leases
chown dhcpd:dhcpd /var/lib/dhcp/dhcpd6.leases
Стартуем:
/usr/sbin/dhcpd -6 -cf /etc/dhcp/v6_eth1 eth1
Теперь абоненты должны получать настройки IPv6 и можно озадачится вопросом трансляции адресов. Настроим tayga (/etc/tayga.conf):

tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2a01:da:80d0:1::2
prefix 2a01:da:80d0:2:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/spool/tayga
В конфиге мы отрезали v4 подсеть 192.168.255.0/24 для трансляции, а также v6 /96 блок 2a01:da:80d0:2:ffff::/96.
В документации также сказано о необходимости ручного создания tun интерфейса net64 на манер:
tayga --mktun
Но мне как-то удалось избежать данного этапа и сразу сделать запуск:
/etc/init.d/tayga start 
Добавим правило NAT для подменных IPv4:
iptables -t nat -A POSTROUTING -s 192.168.255.0/24 -j MASQUERADE 
К слову сказать, интерфейс nat64 у меня почему-то после запуска был в состоянии down. Разбираться пока не стал - просто сделал:
ifconfig nat64 up
Также не хватает завернуть трафик в этот самый nat64. Делал так:
ip addr add 192.168.255.1 dev nat64
ip route add 192.168.255.0/24 dev nat64
ip route add 2a01:da:80d0:2:ffff::/96 dev nat64
Осталось на закуску настроить DNS64. Для этого в /etc/bind/named.conf.options учтем следующее:

options {
// SKIP
        listen-on-v6 { any; };
        dns64 2a01:da:80d0:2:ffff::/96
        {
                clients { 2a01:da:80d0:1::/64; };
        };
// SKIP
};
Запускаем bind. Проверяем на клиенте:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 20:cf:30:1c:f2:52
          inet6 addr: 2a01:da:80d0:1:22cf:30ff:fe1c:f252/64 Scope:Общий
          inet6 addr: fe80::22cf:30ff:fe1c:f252/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:145421 errors:0 dropped:0 overruns:0 frame:0
          TX packets:124475 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000
          RX bytes:74361437 (74.3 MB)  TX bytes:14183191 (14.1 MB)
          Interrupt:46 

Как видим адрес получили. Адрес ДНС сервера тоже:
# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 2a01:da:80d0:1::1

 Проверяем связь. Пустим трассу на IP:

# traceroute -n -I 2a01:da:80d0:2:ffff::94.100.191.204
traceroute to 2a01:da:80d0:2:ffff::94.100.191.204 (2a01:da:80d0:2:ffff:0:5e64:bfcc), 30 hops max, 80 byte packets
 1  2a01:da:80d0:1::1  0.186 ms  0.538 ms  0.524 ms
 2  2a01:da:80d0:1::2  0.523 ms  0.511 ms  0.499 ms
 3  2a01:da:80d0:1::2  0.821 ms  0.831 ms  0.822 ms
 4  2a01:da:80d0:2:ffff:0:e16e:2603  3.735 ms  3.756 ms  3.876 ms
 5  2a01:da:80d0:2:ffff:0:e16e:26da  3.870 ms  4.088 ms  4.093 ms
 6  2a01:da:80d0:2:ffff:0:c444:21f6  11.654 ms  11.486 ms  11.552 ms
 7  2a01:da:80d0:2:ffff:0:59b8:4008  11.591 ms  14.577 ms  14.698 ms
 8  2a01:da:80d0:2:ffff:0:c323:41e6  14.434 ms  14.455 ms  14.372 ms
 9  2a01:da:80d0:2:ffff:0:59b8:4012  24.826 ms  22.183 ms  22.108 ms
10  2a01:da:80d0:2:ffff:0:5e64:b735  20.676 ms  20.644 ms  20.476 ms
11  2a01:da:80d0:2:ffff:0:5e64:bfcc  20.781 ms  20.344 ms  20.251 ms
Трасса есть. Посмотрим различие в резолве имени на v4 и v6 хостах. На v4 хосте я вижу:
# host mail.ru
mail.ru has address 94.100.191.204
mail.ru has address 94.100.191.201
mail.ru has address 94.100.191.202
mail.ru has address 94.100.191.203
mail.ru mail is handled by 10 mxs.mail.ru.
А на v6 вот что:
# host mail.ru
mail.ru has address 94.100.191.204
mail.ru has address 94.100.191.201
mail.ru has address 94.100.191.202
mail.ru has address 94.100.191.203
mail.ru has IPv6 address 2a01:da:80d0:2:ffff:0:5e64:bfcc
mail.ru has IPv6 address 2a01:da:80d0:2:ffff:0:5e64:bfc9
mail.ru has IPv6 address 2a01:da:80d0:2:ffff:0:5e64:bfca
mail.ru has IPv6 address 2a01:da:80d0:2:ffff:0:5e64:bfcb
mail.ru mail is handled by 10 mxs.mail.ru. 
Как-то так. Удачных экспериментов.


Автор: на
Ярлыки: , , , , , , , , , , ,

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)