NAT-PT/DNS64/AFT. Bc. Lumír Balhar (BAL344), Bc. Petr Kadlec (KAD0019)

Transkript

1 NAT-PT/DNS64/AFT Bc. Lumír Balhar (BAL344), Bc. Petr Kadlec (KAD0019) Abstrakt: Tato práce pojednává o Address Family Translation, které obecně shrnuje přechodu z IPv6 sítí do IPv4. Zde se hlavně řeší NAT64 a DNS, jakožto klíčové služby pro přístup k internetu. Klíčová slova: AFT, DNS, DNS64, BIND, NAT64, IPv6, IPv4 1 Address Family Translation Příklad použití Implementace Schéma zapojení Konfigurace IPv4 routeru Konfigurace IPv6 routeru Konfigurace NAT64 routeru Ověření funkčnosti DNS Implementace Ověření funkčnosti Závěr Zdroje listopad /12

2 1 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. 2 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. Obrázek 1: Ukázkové schéma sítě užívající NAT64 a DNS64. listopad /12

3 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. Obrázek 2: Diagram procesu spojení klienta z IPv6 do Ipv4 sítě 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 NAT Tento router si z dodané adresy odstraní prefix a naváže spojení s Ipv4 internetem, které zprostředkuje klientovi. listopad /12

4 2.1 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. Obrázek 3: Schéma zapojení s navrženou adresací sítě. listopad /12

5 2.1.2 Konfigurace IPv4 routeru Následující řádky popisují konfiguraci Cisco routeru v roli IPv4 sítě. ### Základní nastavení ip cef ipv6 unicast-routing ipv6 cef multilink bundle-name authenticated ### Vnitřní interfacy pro routing a reprezentaci IPv4 sítě interface Loopback0 ip address interface Loopback1 ip address ### Propojovací interface interface FastEthernet0/0 ip address duplex auto speed auto ### Nastavení routování krajního routeru router ospf 1 network area 1 network area 0 network area 0 listopad /12

6 2.1.3 Konfigurace IPv6 routeru Následující řádky popisují konfiguraci Cisco routeru v roli IPv6 sítě. ### Základní nastavení ip cef ipv6 unicast-routing ipv6 cef ### Vnitřní interfacy pro routing a reprezentaci IPv6 sítě 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 ### Propojovací interface interface FastEthernet0/0 duplex auto speed auto ipv6 address 2001::A00:A/128 ipv6 rip RIP enable ### Routování ipv6 router rip RIP Konfigurace NAT64 routeru Následující řádky popisují konfiguraci Cisco routeru v roli centrálního prvku s NAT64. ### Základní nastavení ipv6 unicast-routing ### Vnitřní interfacy pro oba druhy sítí interface Loopback0 no ip address ipv6 address BB10::1/128 interface Loopback1 ip address ### Vnější interfacy pro oba druhy sítí interface FastEthernet0/2/6 ip address 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 listopad /12

7 nat64 enable ### Konfigurace OSPF router ospf 1 network area 1 network area 0 ### Povolení RIP ipv6 router rip RIP ### Konfigurace NAT64 nat64 prefix stateful 3001::/96 nat64 v6v4 static 2001::A00:A listopad /12

8 2.1.5 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 , dst , 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 Následně jsme si zobrazili statistiky tohoto provozu na centrálním prvku sítě. Obrázek 4: Statistiky provozu mezi jednotlivými sítěmi listopad /12

9 Obrázek 5: Zobrazení nastavení statického mapování NAT 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 DNS64 podporuje. 2.3 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ě. ### Základní nastavení options { directory "/var/cache/bind"; ### Nastavení DNS64 - prefix dns :ABCD::/96 { clients { any; }; mapped { any; }; suffix ::; recursive-only yes; break-dnssec yes; }; ### Nastavení zdrojových DNS serverů pro přeposlání dotazů forwarders { ; }; 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 aaaa ; <<>> DiG P1 <<>> aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 listopad /12

10 ;; QUESTION SECTION: ;netdevelo.cz. IN AAAA ;; AUTHORITY SECTION: netdevelo.cz IN SOA ns1.shopsys.cz. hostmaster.shopsys.cz ;; Query time: 0 msec ;; SERVER: #53( ) ;; WHEN: Tue Nov 12 09:56: ;; 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 aaaa ; <<>> DiG P1 <<>> aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;netdevelo.cz. IN AAAA ;; ANSWER SECTION: netdevelo.cz IN AAAA 2001:abcd::259d:c4ba ;; AUTHORITY SECTION: IN NS f.root-servers.net IN NS i.root-servers.net IN NS g.root-servers.net IN NS d.root-servers.net IN NS b.root-servers.net IN NS k.root-servers.net IN NS h.root-servers.net IN NS e.root-servers.net IN NS c.root-servers.net IN NS j.root-servers.net IN NS l.root-servers.net IN NS m.root-servers.net IN NS a.root-servers.net. ;; Query time: 1 msec ;; SERVER: #53( ) ;; WHEN: Tue Nov 12 09:59: ;; MSG SIZE rcvd: 269 listopad /12

11 3 Závěr Závěrem lze říci, že je technologie NAT64 dobře připravena a snadno konfigurovatelná na zařízeních společnosti Cisco a značnou měrou tak přispívá k možnosti rozšíření vazeb mezi stávajícím IPv4 a nově vznikajícím IPv6 internetem. Ovšem podpora této technologie by se mohla vyskytovat i na více zařízeních společnosti Cisco (především levnějších sérií) a také by se mohlo objevit i na zařízeních jiných výrobců, čímž by se mohlo výrazně přispět k jejímu masivnímu rozšíření. U DNS64 je situace velmi podobná, což vyplývá z nutnosti kooperace těchto technologií při jejich nasazení. DNS64 je na tom ovšem lépe, co se týče podpory, protože jej už delší dobu podporují hlavní open source DNS servery, jejichž provoz zvládne jakýkoli Linuxový server a není tak třeba utrácet značné sumy peněz za speciální servery s podporou této technologie. Vzhledem ke zmiňované ceně zařízení společnosti Cisco bych se v případě implementace této technologie do ostrého provozu určitě zaměřil na open source alternativy, které by mohly přinést stejný užitek s daleko nižšími náklady. listopad /12

12 4 Zdroje [1] NAT64 a DNS64. [online]. Dostupné z: [2] DNS64 in BIND. [online]. Dostupné z: [3] Static NAT-PT for IPv6 Configuration Example. [online]. Dostupné z: 1.shtml [4] IPv6 Stateful NAT64 Configuration Example. [online]. Dostupné z: listopad /12