Ipv6-9-Tunelowanie Nat64 Direct Access

Tajemnice protokołu IPv6

Jacek Światowiak

[email protected]


Cześć 9

Mechanizm Direct Access

Oraz konwersja protokolarna


Jacek Światowiak

Kilka słów o mnie:

MCSE+M, MCSE+S MCTS: Forefront Client and Server, ISA 2006 MCTS: SQL 2005 MCTS: Vista, Windows 7 MCTS: Business Desktop Deployment, BDD MCTS: Office Communications Server 2007 MCTS: SBS 2008, EBS 2008 MCTS: Exchange 2007, 2010 MCTS: Windows Server Virtualization, MCTS: Windows Server 2008 R2, Desktop Virtualization

MCITP: Windows Server 2008, Server Administrator

MCITP: Windows Server 2008, Enterprise Administrator

MCITP: SQL 2005, Database Administrator

MCITP: Exchange Server 2007, Enterprise Messaging Administrator

MCITP: Exchange Server 2010, Enterprise Messaging Administrator

MCITP: Windows Server 2008 R2, Virtualization Administrator 2008 R2

MCITP: Windows 7, Enterprise Desktop Administrator

MSA: Office Communications Server 2007 – U.C.Voice

MVP: Forefront od października 2010

Strefa eksperta ATE

2008 TAK

2009 TAK

2010 TAK 2/38

http://mvp.support.microsoft.com/


Jacek Światowiak Rok 2001 !!!!!!!!!!!!!!

3/38


Jacek Światowiak

Inżynieria Internetu Przyszłości

Projekt jest współfinansowany ze środków Unii Europejskiej poprzez Europejski

Fundusz Rozwoju Regionalnego w ramach Programu Operacyjnego

Innowacyjna Gospodarka na lata 2007-2013:

• Priorytet 1 - Badania i rozwój nowoczesnych technologii.

• Działanie 1.1 - Wsparcie badań naukowych dla budowy gospodarki opartej na wiedzy.

• Poddziałanie 1.1.2 - Strategiczne programy badań naukowych i prac rozwojowych.

Numer projektu: POIG.01.01.02-00-045/09-00.

Czas realizacji: 01.01.2010 - 31.12.2012.

http://www.iip.net.pl

4/38


Jacek Światowiak


Projekt dotyczy opracowania i przetestowania infrastruktury i usług dla nowych generacji sieci

Internet, tj. Internetu IPv6 i Internetu Przyszłości (ang. Future Internet). Oczekuje się, iż nowe

generacje Internetu (jeden z głównych priorytetów badawczych w ramach Programów

Ramowych Unii Europejskiej) przyczynią się istotnie do rozwoju cywilizacyjnego w Europie

powodując, że z ich możliwości będą korzystały wszystkie lub prawie wszystkie obszary

ludzkiej aktywności.

Celem projektu w ramach Internetu IPv6 jest opracowanie metodyki dla ewolucyjnego

zastąpienia w sieci krajowej obecnej wersji IP (IPv4) przez protokół IPv6 oraz

zaproponowanie nowych rozwiązań sieciowych i usług wynikających z IPv6.

Celem projektu w ramach Internetu Przyszłości jest opracowanie i przetestowanie propozycji

nowej architektury opartej na wirtualizacji zasobów wraz z nowymi mechanizmami i

algorytmami dotyczącymi istotnych aspektów działania sieci. Projekt stawia sobie również za

cel stworzenie środowiska krajowej sieci testowej dla Internetu IPv6 i Internetu Przyszłości,

pozwalającego na prowadzenie działalności badawczo-rozwojowej opartej na weryfikacji

eksperymentalnej.

5/38


Jacek Światowiak


Projekt jest realizowany przez konsorcjum, w którego skład wchodzą wiodące

uczelnie techniczne, instytuty Polskiej Akademii Nauk i instytuty branżowe.

Politechnika Warszawska

Instytut Łączności - Państwowy Instytut Badawczy

Politechnika Wrocławska

Politechnika Poznańska

Poznańskie Centrum Superkomputerowo-Sieciowe (Instytut Chemii

Bioorganicznej PAN)

Instytut Informatyki Teoretycznej i Stosowanej Polskiej Akademii Nauk

Politechnika Śląska

Politechnika Gdańska

Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie

6/38


Jacek Światowiak

Sesje

Zagadnienia adresacji – odbyła się 11 listopada 2011

Datagram IPv6 – odbyła się 25 listopada 2011 r.

Protokół ICMPv6 – odbyła się 1 grudnia 2011

Protokół Neighbor Discovery – 15 grudnia 2011

Zagadnienia automatycznej adresacji – 2 lutego 2012

Technologie migracji – 16 luty 2012

Tunelowanie 6to4, 6over4, 6RD – 1 marca 2012

Tunelowanie ISATAP, TEREDO – 12 kwietnia 2012

Translacja protokołów (NAT64/DNS64), mechanizm DirectAccess w Windows

Server 2008 R2, Windows 7 oraz nowości w Windows Server 2012 – 14 czerwca

Zagadnienia dodatkowe – 28 czerwca – zakończenie cyklu

7/38


Jacek Światowiak

Agenda

Metody translacji protokołów Problemy z NAT Stateless IP/ICMP Translation (SIIT) Transport Relay Translation (TRT) NAT64 DNS64 Dual Stack Lite Klasyczne VPN DirectAccess Direct Access w rodzinie 2008 R2/ Windows 7 UAG 2010 publikacje Direct Access w rodzinie 2012 / Windows 8 Direct Access w rodzinie 2012 / Windows 8 – wdrożenie 4 RD IVI DiVI

8/38


Jacek Światowiak

RFC 2765 SIIT (ang. Stateless IP/ICMP Translation Algorithm

RFC 2766 NAT-PT (ang. Network Address Translation – Protocol Translation) oraz NAPT-

PT (ang. Network Address Port Translation + Protocol Translation). Zastąpiony przez RFC

4966 (Reasons to Move the Network Address Translator - Protocol Translator

(NAT-PT) to Historic Status)

BIS (ang. Bump In the Stack) - na podstawie RFC 2767 Dual Stack Hosts using the "Bump-

In-the-Stack" Technique

BIA (ang. Bump in the API) - RFC 3338 Dual Stack Hosts using Bump-in-the-API

Transport Relay Translator - na podstawie RFC 3142 An IPv6-to-IPv4 Transport

ALG (ang. Aplication Layer Gateway) - na podstawie RFC 2766 Network Address

Translation – Protocol Translation) oraz RFC 2663 IP Network Address Translator (NAT)

Terminology and Considerations

SOCKS IPv4/IPv6 - na podstawie RFC 3089 - A SOCKS-based IPv6/IPv4 Gateway

Mechanism

Metody translacji protokołów

9/38


Jacek Światowiak


CGN – Large Scale NAT44

NAT 444 (CGN + CPE NAT 44)

CGN – Carrier Grade NAT

CPE - Customer-

premises equipment

LSN – Large Scale Network

10/38


Jacek Światowiak


DS-Lite (NAT44 + 4-over-6 tunnel)

A+P (DSLite z prekonfigurowanym zakresem portów)

NAT64

11/38


Jacek Światowiak


Każdy NAT jest gorszy niż bezpośrednie podłączenie END-to-END

Podwójny NAT jeszcze gorszy niż pojedynczy NAT (NAT444)

Nat z ALG bardzo złe rozwiązanie (NAT-PT – uwagi w RFC 4966)

NAT jest OK dal ruchu wychodzącego

NAT + TUN/TURN rozwiązuje problemy sesji typu peer-to-peer (SIP)

Wydaje się, iż mimo wad – dominującymi rozwiązaniami będą:

NAT64

DS-Lite/A+P

IETF – Grupa robocza Softwire !!!!!!!!!!

RFC 4925 - Softwire Problem Statement

http://datatracker.ietf.org/wg/softwire/charter/

12/38


Jacek Światowiak

Problemy z NAT

NAT-PT (RFC 2766) = NAT64 + NAT46 + DNS ALG

- Rozwiązanie czysto akademickie………

DS-Lite = NAT44 over IPv6

• Dobrze znane rozwiązane

• I Dobrze znane problemy !

• Dla dużej skali wdrożenia

NAT64 = dla ograniczonych środowisk

• Tylko klient IPv6 do serwerów /klientów IPv4

• Nie działa w drugą stronę

13/38


Jacek Światowiak

Stateless IP/ICMP Translation (SIIT)

Stateless IP/ICMP Translation (SIIT)

Stateless IP/ICMP Translation (SIIT) dokonuje translacji pomiędzy nagłówkami datagramów IPv4 a IPv6. SIIT definiuje klasę adresów IPv6 określanych jako IPv4-translated addresses. Mają one prefiks ::ffff:0:0:0/96 i mogą być również zapisywane w formacie ::ffff:0:a.b.c.d, gdzie a.b.c.d jest adresem IPv4 węzła określanego jako "IPv6-enabled". Prefiks został tak dobrany aby przy generacji sumy kontrolnej nagłówka datagramu IPv4 uniknąć niepotrzebnych zmian

Specyfikację przyjęła grupa robocza NGTRANS IETF w lutym 2000 jako RFC 2765 . RFC

2765 został zastawiony przez RFC 6145 (IP/ICMP Translation Algorithm) w roku 2011.

Adres ten cały czas jest zdefiniowany w RFC 6052 (IPv6 Addressing of IPv4/IPv6

Translators).

Zaś mechanizmy translacji IPv4/IPv6 w RFC 6144 (Framework for IPv4/IPv6 Translation).

14/38


Jacek Światowiak

Transport Relay Translation (TRT)

Transport Relay Translation (TRT)

Transport Relay Translation (TRT) został zdefiniowany w RFC 3142 (An IPv6-

to-IPv4 Transport Relay Translator).

Jest to jedna z najbardziej znanych metod działania NAT-PT/NAPT-PT ale

bardzo silnie zależna od DNS, który dokonuje konwersji rekordów AAAA na A.

Mechanizm ten jest określany jako DNS-ALG a zdefiniowany został w

dokumencie RFC 2694 (DNS extensions to Network Address Translators

(DNS_ALG).

15/38


Jacek Światowiak

NAT 64

NAT64 jest mechanizmem zapewniającym komunikację węzłom IPv6 w węzłami

IPv4.

Serwer NAT64 ma od jednego interfejsu co najmniej jeden adres IPv4, a od

drugiego segment IPv6 o długości 32-bitów (czyli z prefiksem – przykładowym

64:ff9b::/96)

RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators – punkt 2.2 IPv4-

Embedded IPv6 Address Format i 2.4 Text Representation

RFC 6146 - Stateful NAT64: Network Address and Protocol Translation

from IPv6 Clients to IPv4 Servers

16/38


Jacek Światowiak

NAT 64

17/38


Jacek Światowiak

DNS 64

DNS64 opisuje wykorzystanie serwera DNS celem pozyskania rekordów AAAA

dla docelowego serwera, lecz dla którego dostępne są wyłącznie rekordy A.

DNS 64 dokona syntezy rekordów AAAA na podstawie uzyskanych od innego

serwera DNS rekordów typu A

Pierwsza cześć utworzonego syntetycznie adresu IPv6 wskazuje na translator

IPv6/IPv4 a druga zawiera w sobie docelowy adresIPv4. Translatorem jest

zwykle serwer NAT64.

Specyfikacja opisana jest w dokumencie RFC 6147- DNS64: DNS Extensions

for Network Address Translation from IPv6 Clients to IPv4 Servers.

Potencjalne problemy z DNS Sec oraz z hostami wirtualnymi !!!

18/38


Jacek Światowiak

Implementacje NAT 64

Implementacja NAT 64

TAYGA - a stateless NAT64 implementation for Linux

(http://www.litech.org/tayga/) (Ostatnia wersja 0.9.2, 2011-06-10). Wykorzystuje

TUN Driver

Ecdysis - NAT64 gateway, includes DNS64 – testowane na Fedora 10 – 14

(Ostatnia wersja 2010-11-17 ), również LiveCD oraz OpenBSD 4.6

Microsoft Forefront Unified Access Gateway 2010 - a reverse proxy and

VPN solution that implements DNS64 and NAT64 – teraz wbudowana

bezpośrednio w serwery rodziny 2012.

Stateless Network Address Translation 64 on Cisco ASR 1000

Stateful NAT64 feature on Juniper MX Series 3D Universal Edge router

OpenBSD 5.1 brings a PF packet filter capable of NAT64

19/38

http://www.litech.org/tayga/




Jacek Światowiak

Dual-Stack Lite (DS-Lite)

NAT64

• IPv6 to IPv4 NAT

• Natywny transport

• DNS64 = DNS ALG

• Brak koniczności modyfikacji sieci

i urządzeń CPE

• Węzły IPv6 lub dual stack

• Nie wiele implementacji

DS-Lite

• IPv4 to IPv4 NAT

• Tunele 4-over-6

• Brak konieczności DNS(Sec)

• Wymagane zmiany w urządzeniach

CPE

• Brak konieczności obsługi IPv6 na

węzłach

• NAT 44 – dobrze poznany

RFC 6333 - Dual-Stack Lite Broadband Deployments Following IPv4

Exhaustion

20/38


Jacek Światowiak

Klasyczne VPN

Jakie ograniczenia wnoszą istniejące klasyczne rozwiązania VPN

PPTP – wymaga przepuszczania od strony klienta na zaporze sieciowej protokołu

GRE (protokół o numerze 47) oraz otwarcia portu TCP o numerze 1723

L2TP/IPSec – sam mechanizm tunelowania L2TP jest przezroczysty dla zapór

sieciowych, gdyż bazuje na tunelowaniu w protokole UDP. Natomiast w

połączeniu z IPSec wymaga przepuszczania przez zaporę protokołu IPSec – w

części określanej jako Encapsulating Security Payload (ESP) – jest to protokół o

numerze 50. Dodatkowo wymagane jest przepuszczanie portu UDP 500 i portu

UDP 1701.

21/38


Jacek Światowiak

Direct Access

DirectAccess zestawia tunele IPSec od klienta do serwera DirectAccess

wykorzystując protokół IPv6 jako protokół transportowy celem uzyskania dostępu

do zasobów intranetowych lub innych klientów DirectAccess.

Technologia ta enkapsuluje ruch IPv6 przez sieć IPv4. Cały ruch do sieci intranet

jest szyfrowany przy użyciu protokołu SSL i wysyłany jest za pośrednictwem

standardowego portu HTTPS (443), co oznacza, że w większości przypadków nie

jest wymagana rekonfiguracji zapory sieciowej lub serwera proxy. Klient

DirectAccess może skorzystać z jednej z kilku technologii tunelowania, w

zależności od konfiguracji sieci gdzie klient jest podłączony. Wykorzystywane

mogą być mechanizmy: 6to4, ISATAP, Teredo lub IP-HTTPS.

klient, który jest podłączony do Internetu bezpośrednio (wykorzystuje publiczne

adresy IPv4) będzie korzystać z mechanizmu 6to4, ale jeśli znajduje się za

urządzeniem NAT, korzystać będzie z technologii Teredo lub IP-HTTPS. ISATAP

wykorzystywany jest wewnątrz sieci korporacyjnej.

22/38


Jacek Światowiak

Direct Access w rodzinie 2008 R2/

Windows 7

W przypadku środowiska wykorzystującego rodzinę Windows Server 2008 R2 oraz Windows 7 do

zbudowania infrastruktury DirectAccess wymagane są następujące elementy:

• Jeden lub więcej serwerów DirectAccess będących elementami Windows Server 2008 R2 z dwiema

kartami sieciowymi: jedna, która jest podłączona bezpośrednio do Internetu, a druga, która jest

podłączona do sieci intranet.

• Na serwerze DirectAccess, co najmniej dwa kolejne, publiczne adresy IPv4 przypisane do karty sieciowej,

która jest podłączona do Internetu. Wymóg ten jest niezbędny dla wykrywania typu NAT’a za którym może

się znajdować klient Direct Access.

• Klienci DirectAccess z systemem Windows 7 (wyłącznie w wersjach Ultimate i Enterprise). Te stacje

robocze muszą być członkami domeny Active Directory.

• Co najmniej jeden kontroler domeny i serwer DNS z systemem Windows Server 2008 z dodatkiem SP2

lub Windows Server 2008 R2

• Korporacyjna Infrastruktura klucza publicznego (PKI) celem wystawiania certyfikatów.

• Komponent DirectAccess dostępny w serwerze Windows Server 2008 R2 zapewnia minimalną

funkcjonalność. Umożliwia wyłącznie dostęp do zasobów korporacyjnych tylko po protokole IPv6, co

oznacza, iż Klient Direct Access nie ma tym kanałem dostępu do zasobów (serwerów), które nie wspierają

protokołu IPv6.

Nie zapewnia również żadnego mechanizmu wysokiej dostępności dla tego kanału komunikacyjnego. Aby

zapewnić zarówno wysoką dostępność jak i konwersję protokołu IPv6 na IPv4 (mechanizm NAT64, DNS 64)

celem dostępu do zasobów obsługujących wyłącznie protokół IPv4 niezbędne jest wdrożenie produktu z

rodziny Forefront o nazwie Unified Access Gateway 2010 (UAG), co podnosi znacznie koszty wdrożenia.

23/38


Jacek Światowiak

UAG 2010 publikacje

24/38


Jacek Światowiak

Direct Access w rodzinie 2008 R2/

Windows 7

Klient DirectAccess zastawia dwa tunele IPSec:

Tunel infrastrukturalny - IPSec Encapsulating Payload (ESP) z wykorzystaniem

certyfikatu komputera. Tunel ten zapewnia dostęp do wewnętrznego serwera DNS,

kontrolera domeny, celem uwierzytelniania w środowisku domenowym.

Tunel intranetowy - również IPsec ESP ale z wykorzystaniem zarówno certyfikatu

komputera i poświadczeń użytkownika. Ten tunel odpowiada za uwierzytelnianie

użytkownika i zapewnia dostęp do zasobów intranetowych i serwerów aplikacji.

25/38


Jacek Światowiak

Direct Access w rodzinie 2012 /

Windows 8

Jakie zmiany wnosi Windows Server 8 w zakresie technologii Direct Acccess

• Integracja i koegzystencja serwera DirectAccess i serwera usługi RRAS na jednym

systemie (problem protokołu IKEv2 występujący w Windows Server 2008 R2 został

rozwiązany).

• Uproszczone zarządzanie usługą DirectAccess w szczególności w małych i średnich

organizacjach.

• Możliwość wdrożenia mechanizmu Direct Access w trybie zdalnej administracji stacjami

klienckimi lub w trybie zdalnej administracji i równocześnie dostępu do sieci

korporacyjnej.

• Usunięcie wymogu korzystania z korporacyjnej infrastruktury klucza publicznego PKI.

Mechanizm zmoże posługiwać się certyfikatami self-sign wystawianymi również na

adresy IP.

• Wbudowano w system komponenty NAT64 i DNS64 dla dostępu do zasobów

wewnętrznych korzystających wyłącznie z protokołu IPv4 (komponent ten był dostępny

wyłącznie w produkcie UAG 2010).

• Wsparcie dla serwera DirectAccess zlokalizowanego za urządzeniem NAT co

zlikwidowało konieczność wykorzystywania dwóch publicznych adresów IPv4.

• Uproszczenie zasad komunikacji sieciowej i reguł zapory.

26/38


Jacek Światowiak


Windows 8

Jakie zmiany wnosi Windows Server 8 w zakresie technologii Direct Acccess

• Wsparcie dla Load balancingu (rozkładanie obciążenia na więcej niż jeden serwer) oraz

wysokiej dostępności bez konieczności wykorzystywania serwera UAG 2010.

• Opcja wymuszenia tunelowania do Internetu poprzez lub poza połączniem DirectAccess

– Force Tunneling.

• Wsparcie dla obsługi wielu domen Active Directory.

• Integracja z mechanizmem NAP (element dostępny był wyłącznie w produkcie UAG

2010).

• Wsparcie dla uwierzytelniania hasłami jednorazowymi OTP (np. tokeny). W systemie

Windows Server 2008 R2 dostępny był mechanizm obsługi wyłącznie kart inteligentnych.

• Zwiększona wydajność tunelowania IP-HTTPS poprzez eliminację podwójnego

szyfrowania HTTPS/IPSEC.

• Wsparcie dla środowiska składającego się z wielu lokacji Active Directory (multi site).

• Wsparcie systemu w wersji Core.

• Możliwość zarządzania i monitorowania z wykorzystaniem Windows PowerShella.

• Monitorowanie stanu połączenia klienta i serwera.

• Wbudowana diagnostyka oraz ulepszone rozliczanie i raportowanie.

27/38


Jacek Światowiak


Windows 8 - wdrożenie

28/38


Jacek Światowiak



29/38


Jacek Światowiak



Uproszczona konfiguracja DirectAcess dla celów zdalnego zarządzania

30/38


Jacek Światowiak



Konfiguracja DirectAcess dla rodziny Windows Server 2012/ Windows 8

31/38


Jacek Światowiak



Topologia wdrożenia

32/38


Jacek Światowiak



Dahsboard

33/38


Jacek Światowiak



Zestawione połączenie DirectAccess

34/38


Jacek Światowiak



NAT 64

DNS 64

Mechanizm NAT64 bazuje na draftach IETF

http://tools.ietf.org/html/draft-ietf-behave-v6v4-

xlate-stateful

http://tools.ietf.org/html/draft-ietf-behave-v6v4-

xlate

http://tools.ietf.org/html/draft-ietf-behave-

address-format

zaś DNS64 na

http://tools.ietf.org/html/draft-ietf-behave-dns64

35/38


Jacek Światowiak

4 RD

IPv4 Residual Deployment

Mechanizm odwrotny do 6RD – ma odpowiadać za przesyłanie protokołu IPv4 po

sieciach IPv6.

Czyli jest tunelowanie typu IP-in-IP.

IETF Draft

IPv4 Residual Deployment across IPv6-Service networks (4rd)

ISP-NAT's made optional

draft-despres-intarea-4rd-01

14 marca 2011

36/38


Jacek Światowiak

IVI oraz dIVI

IVI Translation

Oznacza technikę translacji typu

stateless IPv4/IPv6

• Translacja adresów jest opisana w RFC 6052 - jako mapowanie typu stateless z zawartymi

w adresie IPv6 adresamiIPv4

• Transalcja nagłówka IP oraz ICMP zdefiniowana została w RFC 6145

• Transalcja rekordów DNS (DNS64) zdefiniowana została RFC 6147 , a samo mapowanie

rekordów w RFC 6052.

Współdzielenie adresów w trybie stateless NAT64 umożliwia wykorzystanie pojedynczego

publicznego adresu IPv4 przez wiele adresów IPv6, dzięki wykorzystaniu mapowania na

warstwie transportowej. Więcej w RFC 6052.

Dual stateless translation zwana dIVI. Dzięki translacji w trybie stateless, po drugiej translacji

możliwe jest odzyskanie oryginalnego adresu IPv4. Dzięki takiemu podejściu - NAT464 – nie

jest konieczne stosowanie DNS64 i application-level gateway (ALG)

RFC 6219 - The China Education and Research Network (CERNET) IVI

Translation

Design and Deployment for the IPv4/IPv6 Coexistence and Transition

37/38


Jacek Światowiak

Dziękuję za uwagę… W następnej części: Zagadnienia dodatkowe

Ipv6-9-Tunelowanie Nat64 Direct Access

Documents

Transcript of Ipv6-9-Tunelowanie Nat64 Direct Access