Technologie počítačových sítí AFT NAT64/DNS64 Bc. Lumír Balhar (BAL344), Bc. Petr Kadlec (KAD0019) 11. listopadu 2013
Address Family Translation Jako Address Family Translation, neboli AFT, lze označit mechanismy přechodu packetu mezi sítěmi s IPv4 a IPv6. Tyto mechanismy umožňují vzájemnou koexistenci postupně zastaralé technologie počítačových sítí IPv4 s nově nastupující technologií IPv6. V našem případě jsme se měli nejprve zabývat technologií NAT-PT, která se snažila docílit vzájemného propojení obou druhů sítí oběma směry (IPv4 lokální síť do IPv6 internetu a naopak IPv6 lokální síť do IPv4 internetu), ale pro své fungování potřebovala značný zásah do DNS a obecně nenašla širšího uplatnění a tak byla v RFC dokumentu 4966 odmítnuta a prohlášena za zastaralou. V tomto projektu jsme NAT-PT nahradili modernější verzí NAT64, která slouží k připojování nových lokálních sítí s IPv6 adresami do internetu využívajícího převážně IPv4 adresaci. Vzhledem k rozdílné adresaci u obou druhů sítí je třeba v případě implementace takového spojení implementovat i mechanismus pro správným překlad adres. V našem případě se bude jednat o technologii DNS64. Příklad použití Pro demonstraci praktické využitelnosti námi implementovaného mechanismu jsme využili smyšlenou síť využívající pouze IPv6 adresy, jejíž klienti ovšem stále nutně potřebují využívat prostředky internetu dostupné pouze pod IPv4 adresami. Ukázkové zapojení sítě může vypadat například takto. V tomto zapojení je provoz ze sítě do internetu rozdělen mezi dva routery, kdy se každý z nich stará o spojení v rámci jedné IP technologie. DNS server pak obstarává překlad domén na oba druhy adres. Samozřejmě je možné, aby funkci všech tří zařízení obstarával jen jeden síťový prvek. Postup spojení lze snadno pochopit z následujícího diagramu.
1. Klient užívající pouze IPv6 adresaci požádá o překlad domény. 2. DNS server se pokusí přeložit doménu na IPv6 adresu pomocí AAAA záznamu. Pokud taková adresa neexistuje, přeloží doménu na IPv4 adresu pomocí A záznamu a tuto adresu přidá k pevně stanovenému prefixu IPv6 adresy. Pokud by se první překlad pomocí AAAA záznamu podařil, klient by přistoupil klasicky ze své IPv6 sítě do IPv6 internetu a NAT64 by nebylo třeba. 3. Díky pevně danému prefixu adresy zavedenému do routovací tabulky klienta se začnou packety posílat na router obstarávající funkci NAT64. 4. Tento router si z dodané adresy odstraní prefix a naváže spojení s IPv4 internetem, které zprostředkuje klientovi.
Implementace Pro simulaci dvou samostatných sítí jsme využili routery Cisco a pro implementaci NAT64 routeru pak virtuální router Cisco CSR1000V. Schéma zapojení Následující schéma znázorňuje schéma zapojení včetně navržené adresace. Konfigurace IPv4 routeru Následující řádky popisují konfiguraci Cisco routeru v roli IPv4 sítě. ip cef ipv6 unicast-routing ipv6 cef multilink bundle-name authenticated
interface Loopback0 ip address 1.1.1.1 255.255.255.255 interface Loopback1 ip address 1.1.1.2 255.255.255.255 interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.0 duplex auto speed auto router ospf 1 network 1.1.1.1 0.0.0.0 area 1 network 1.1.1.2 0.0.0.0 area 0 network 10.0.0.0 0.0.0.255 area 0 Konfigurace IPv6 routeru Následující řádky popisují konfiguraci Cisco routeru v roli IPv6 sítě. ip cef ipv6 unicast-routing ipv6 cef interface Loopback0 no ip address ipv6 address AB00::1/128 ipv6 rip RIP enable interface Loopback1 no ip address ipv6 address AB01::1/128 ipv6 rip RIP enable interface FastEthernet0/0 duplex auto speed auto ipv6 address 2001::A00:A/128 ipv6 rip RIP enable ipv6 router rip RIP Konfigurace NAT64 routeru Následující řádky popisují konfiguraci Cisco routeru v roli centrálního prvku s NAT64.
ipv6 unicast-routing interface Loopback0 no ip address ipv6 address BB10::1/128 interface Loopback1 ip address 2.2.2.2 255.255.255.255 interface FastEthernet0/2/6 ip address 10.0.0.2 255.255.255.0 negotiation auto nat64 enable interface FastEthernet0/2/7 no ip address negotiation auto ipv6 address 2001::A00:B/128 ipv6 rip RIP enable ipv6 rip RIP default-information only nat64 enable router ospf 1 network 2.2.2.2 0.0.0.0 area 1 network 10.0.0.0 0.0.0.255 area 0 ipv6 router rip RIP nat64 prefix stateful 3001::/96 nat64 v6v4 static 2001::A00:A 10.0.0.10 Ověření funkčnosti Při ověřování funkčnosti jsme nejdříve povolili debug informací o ICMP packetech. Následně jsme vyzkoušeli spojení pomocí příkazu ping. Na routeru s IPv4 adresou jsme spustili příkaz Ping s adresou routeru v IPv6 síti. *Nov 12 09:51:22.307: ICMP: echo reply rcvd, src 10.0.0.10, dst 10.0.0.1, topology BASE, dscp 0 topoid 0 *Nov 12 09:51:22.311: ICMP: echo reply rcvd, src 10.0.0.10, dst 10.0.0.1, topology BASE, dscp 0 topoid 0 *Nov 12 09:51:22.315: ICMP: echo reply rcvd, src 10.0.0.10, dst 10.0.0.1, topology BASE, dscp 0 topoid 0 *Nov 12 09:51:22.315: ICMP: echo reply rcvd, src 10.0.0.10, dst 10.0.0.1, topology BASE, dscp 0 topoid 0 *Nov 12 09:51:22.319: ICMP: echo reply rcvd, src 10.0.0.10, dst 10.0.0.1, topology BASE, dscp 0 topoid 0
Na routeru v IPv6 síti jsme získali následující výstup. *Nov 12 09:51:23.347: ICMPv6: Received echo request, Src=3001::A00:1, Dst=2001:A *Nov 12 09:51:23.347: ICMPv6: Sent echo reply, Src=2001::A00:A, Dst=3001::A00:1 *Nov 12 09:51:23.351: ICMPv6: Received echo request, Src=3001::A00:1, Dst=2001:A *Nov 12 09:51:23.351: ICMPv6: Sent echo reply, Src=2001::A00:A, Dst=3001::A00:1 *Nov 12 09:51:23.351: ICMPv6: Received echo request, Src=3001::A00:1, Dst=2001:A *Nov 12 09:51:23.351: ICMPv6: Sent echo reply, Src=2001::A00:A, Dst=3001::A00:1 *Nov 12 09:51:23.355: ICMPv6: Received echo request, Src=3001::A00:1, Dst=2001:A *Nov 12 09:51:23.355: ICMPv6: Sent echo reply, Src=2001::A00:A, Dst=3001::A00:1 *Nov 12 09:51:23.359: ICMPv6: Received echo request, Src=3001::A00:1, Dst=2001:A *Nov 12 09:51:23.359: ICMPv6: Sent echo reply, Src=2001::A00:A, Dst=3001::A00:1 Následně jsme si zobrazili statistiky tohoto provozu na centrálním prvku sítě.
DNS64 DNS64 jsme z důvodu použití virtuálního routeru CSR1000V s pouze dvěmi fyzickými síťovými kartami realizovali samostatně na počítači s operačním systémem Linux. Jako DNS server nám posloužil Bind9, který od verze 0.9.8 DNS64 podporuje. Implementace Celá implementace spočívala v nastavení mechanismu DNS64 a nastavení DNS serverů, kam má náš lokální DNS server dotazy zasílat. Konfigurace v souboru /etc/named.conf.options vypadala následovně. options { directory "/var/cache/bind"; dns64 2001:ABCD::/96 { clients { any; }; mapped { any; }; suffix ::; recursive-only yes; break-dnssec yes; }; forwarders { 158.196.162.8; }; dnssec-validation auto; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; Ověření funkčnosti Při provedení DNS dotazu na IPv6 adresu na lokální server pomocí příkazu dig se ještě před implementací výše zmíněného vrátil prázdný výsledek. root@pcj257:/etc/bind# dig netdevelo.cz @127.0.0.1 aaaa ; <<>> DiG 9.8.1-P1 <<>> netdevelo.cz @127.0.0.1 aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34238 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;netdevelo.cz. IN AAAA ;; AUTHORITY SECTION: netdevelo.cz. 3578 IN SOA ns1.shopsys.cz. hostmaster.shopsys.cz. 2013071702
10800 3600 604800 3600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Nov 12 09:56:15 2013 ;; MSG SIZE rcvd: 89 Ovšem po implementaci došlo k popsanému efektu, kdy se i přes nenalezení AAAA záznamu v zóně domény netdevelo.cz vrátila IPv6 adresa složená z pevně daného prefixu v konfiguraci a IPv4 adresy získané z A záznamu domény (převedeného do tvaru adres IPv6). root@pcj257:/etc/bind# dig netdevelo.cz @127.0.0.1 aaaa ; <<>> DiG 9.8.1-P1 <<>> netdevelo.cz @127.0.0.1 aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19835 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;netdevelo.cz. IN AAAA ;; ANSWER SECTION: netdevelo.cz. 3069 IN AAAA2001:abcd::259d:c4ba ;; AUTHORITY SECTION:. 283647 IN NS f.root-servers.net.. 283647 IN NS i.root-servers.net.. 283647 IN NS g.root-servers.net.. 283647 IN NS d.root-servers.net.. 283647 IN NS b.root-servers.net.. 283647 IN NS k.root-servers.net.. 283647 IN NS h.root-servers.net.. 283647 IN NS e.root-servers.net.. 283647 IN NS c.root-servers.net.. 283647 IN NS j.root-servers.net.. 283647 IN NS l.root-servers.net.. 283647 IN NS m.root-servers.net.. 283647 IN NS a.root-servers.net. ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Nov 12 09:59:46 2013 ;; MSG SIZE rcvd: 269