Říjen - měsíc notebooků

Go 4 IPv6 & Win: Pokročilé síťování. II. díl

V předchozí části seriálu o IPv6 jsme probrali kroky nutné k rozchození IPv6 v lokální síti, dnes se podíváme na nastavení směrovačů a připojení klientů přes IPv4 sítě pomocí tunelů.

Tunelování IPv6 přes internet (IP-HTTPS)

V předchozí části jsme měli vlastní vnitřní síť rozjetou na IPv6. Pokud byste měli nativní IPv6 internetovou konektivitu, nic by vám už teď nebránilo to rozjet naplno. Problém je, že tu nejspíš nemáte. Ale ona časem přijde. Díky různým tunelovacím technologiím však máme možnost používat IPv6 v omezené míře již nyní a dokonce si užívat i bezpečnosti, jakou nabízí například Direct Access.

V dalším bude tedy naším cílem připojit si klienta, který umí IPv6, z internetu do naší firemní sítě, která už teď pracuje na IPv6. Samozřejmě nejspíš jen v paralelním IPv4/IPv6 režimu, ale přecejenom máme vevnitř IPv6 adresy. Připojení bude muset jít přes IPv4 internet, protože se dá čekat, že to bude ještě nějakou dobu majoritní síťová vrstva a většina připojení bude mít ještě dlouhou dobu IPv4 k dispozici. Vypadat by to mohlo například podle obrázků:

img01_ipv6-schema-client-tunneling-base.png

Představa je tedy taková, že máme počítač KamilPC někde v internetu, ne nutně na veřejných adresách. Tento stroj umí IPv6, ale žádnou veřejnou IPv6 adresu nedostal - zřejmě tam není ani IPv6 router, ani DHCPv6 server. To je důležitý fakt, protože IPv6 tunelové síťovky se nahazují automaticky pouze v případě, že klient žádnou veřejnou IPv6 adresu nemá. Když ji nemá, automaticky se mu počítač pokusí nahodit nějaký IPv6 tunel, aby se problém vyřešil. Například tak, jak je vidět v obrázku:

img02_ipv6-schema-client-tunneling-with-tunnel.png

Tunel znamená, že se klientovi ustaví vlastně jakási obdoba VPN připojení. Říkám jen "obdoba", protože tunel nemusí být nutně ani autentizovaný (ověřený), ani šifrovaný. Prostě kdokoliv se vám v některých případech může připojit do sítě. Tunel to ale bude, protože klientovi se vytvoří virtuální síťovka s nějakou IPv6 adresou. Všechny pakety, které do této síťovky půjdou se prostě budou odesílat obalené ještě IPv4 obalem na váš přístupový server. V našem případě touto gateway bude směrovač London. Ten bude mít také vlastní virtuální síťovku, takže z pohledu směrování a IP adres se to bude chovat stejně.

Tunelových protokolů je několik možných s Windows 7 a Windows Server 2008. Existuje 6to4, Teredo, ISATAP a nejnovější IP-HTTPS. My si tu nastavíme IP-HTTPS, protože to má několik výhod (a navíc je to nejsložitější). Chodí to jednoduše přes TCP 443 a je to obalené normálním HTTPS obalem. Průchodnost to má jako kudla máslem. A je to i šifrované. Navíc budeme vyžadovat klientský certifikát počítače pro ověření přístupu, takže budeme mít firmu luxusně chráněnou a přitom všichni IPv6 klienti, kdekoliv se objeví na internetu, budou mít okamžitě automaticky připojení do vnitřní IPv6 sítě.

Požadavky jsou následující:

  • IP-HTTPS gateway musí být dostupná z internetu přes TCP 443 na nějakém veřejném jméně, v našem příkladě je to ipv6.gopas.cz. Žádné množství NAT zařízení v cestě ničemu nevadí. Dá se to dokonce prohánět přes TMG (Threat Management Gateway) a její SSL/TLS inspekci.
  • IP-HTTPS server by měl být členem domény, stejně jako stanice. Zjednoduší to správu a umožní ověřování SSL/TLS klientských certifikátů.
  • IP-HTTPS server (v našem případě směrovač London) by měl být členem skupiny Windows Authorization Access Group, aby mohl číst tokenGroups atribut uživatelských účtů v Active Directory. Detaily jindy a jinde, to by byla už jiná pohádka.
  • SSL/TLS certifikát IP-HTTPS serveru. Musí mít Server Authentication použití (EKU, 1.3.6.1.5.5.7.3.1), musí být uložen v Microsoft RSA SChannel Cryptographic Provider, nebo v Microsoft DH Schannel Cryptographic Provider, nebo v CNG a musí být použitelný k Encryption (Digital Signature, Key Encipherment). Subject, nebo Subject Alternative Name (SAN) musí obsahovat to jméno, které budou klienti používat jako adresu své IP-HTTPS gateway. CRL, nebo OCSP takového certifikátu musí být dostupné a platně z klientů. Certifikát musí být umístěn v úložišti počítače a musí mít k němu přístup účet SYSTEM. Ideálně bych si tedy koupil veřejný certifikát a dal do něho jméno ve stylu ipv6.gopas.cz například.
  • SSL/TLS klientský certifikát IP-HTTPS klienta. Jeden rozdíl je ten, že v certifikátu musí být použití (Enhanced Key Usage, EKU) Client Authentication (1.3.6.1.5.5.7.3.2). Druhý zásadní rozdíl je ten, že každý klientský počítač bude mít svůj vlastní certifikát. Ten by navíc měl ideálně obsahovat v Subject Alternative Name (SAN rozšíření) doménové DNS jméno daného počítače, aby se dal jednoduše ověřit v Active Directory. Já bych ideálně takové certifikáty vydával automaticky (autoenrollment) ze své vlastní interní certifikační autority, ideálně doménové (AD CS, Enterprise CA). K tomu vám stačí i Windows Server 2008 R2 Standard Edition. Certifikační autorita musí být umístěna v NTAuth store v Active Directory.

Vydávání certifikátů je mimo rozsah tohoto textu. Takže provedeme jen nějaké to ověření, že ty certifikáty, které máme na směrovači London a stanici KamilPC jsou v pořádku. Provede se to pomocí nástroje CERTUTIL a je potřeba ověřit, že ve výpisech jsou všechny parametry v pořádku.

Nejprve ověříme certifikát serveru. Ověření platnosti tohot certifikátu je potřeba udělat jak na serveru samotném, tak na klientovi, kterého umístíme do internetu. Na IP-HTTPS gateway serveru se vypíšou všechny certifkáty počítače - najděte si ten správný:

CERTUTIL -verifystore my
CERTUTIL -v -verifystore my
Cert Hash: F61867B88AD320117FD63ECE863C043794F33661
Subject: ipv6.gopas.cz
Enhanced Key Usage: Server Authentication
Provider: Microsoft RSA Schannel Cryptographic Provider
Encryption Test Passed
Allow Full Control: NT Authority\SYSTEM
Certificate is valid

Z výpisu je dobré zi opsat, nebo okopírovat hodnotu políčka Cert Hash, protože ji budeme za chvilku potřebovat při konfiguraci ovladače HTTP.SYS (viz. dále). Pomocí MMC konzole Certificates certifikát serveru vyexportujeme bez privátního klíče (nebo můžeme použít CERTUTIL). Certifikát serveru překopírujeme na stanici klienta pro ověření funkčnosti v okamžiku, kdy je klient v internetu.

CERTUTIL -store my ipv6.gopas.cz c:\ipv6-gopas-cz.cer

img03_ipv6-iphttps-server-certificate-on-client.png

Až je certifikát serveru nakopírován na stanici klienta, který je umístěn v internetu. Ověříme platnost certifikátu IP-HTTPS serveru z pohledu klienta pomocí:

CERTUTIL -url c:\ipv6-gopas-cz.cer

Dále ověříme stejným způsobem platnost certifikátu klienta, který by se měl lišit jen jménem umístěným v poli Subject. V našem případě by tam mělo být jméno kamilpc.gopas.cz. Z klienta by bylo vhodné ověřít dostupnost IP-HTTPS serveru, například pomocí PING a jeho jména (v našem případě ipv6.gopas.cz).

A jestli jsou certifikáty v pořádku, vyrážíme na konfiguraci IP-HTTPS tunelu na straně směrovače London. Zde je potřeba zapnout tunelovou síťovku a nakonfigurovat ji tak, aby poslouchala na správném portu a jméně serveru (v našem případě je jméno serveru ipv6.gopas.cz). Nejprve vytvoříme virtuální serverovou IP-HTTPS síťovku:


NETSH INTERFACE IPHTTPS SHOW INTERFACE
NETSTAT -ano | FINDSTR :443

img04_ipv6-iphttps-server-interface-create.png

NETSH INTERFACE IPHTTPS ADD INTERFACE Server https://ipv6.gopas.cz:443/IPHTTPS State=enabled AuthMode=certificates

Tím jsme vytvořili IP-HTTPS síťovku. Ona ale používá vnitřní systémový ovladač HTTP.SYS k tomu, aby poslouchala na příchozí komunikace. Ovladač HTTP.SYS je používán například i IISkem a dalšími službami, jako je Windows Server Remote Management (WinRM), nebo třeba SSTP VPN. Má kvůli tomu vlastní správu certifikátů, která je mimo nastavení IP-HTTPS tunelu. Jen pro zajímavost, tunelové síťovky na klientovi i serveru spravuje služba IP Helper. Bez ní tunely nepojedou. Ale zase je to dobrá nápověda, co restartovat, když se děje něco nekalého:

NET STOP iphlpsvc & NET START iphlpsvc

Musíme tedy nastavit ještě HTTP.SYS, aby používal správný certifikát a rozuměl klientským certifikátům. SSL/TLS certifikáty nemohou být uchyceny (bind) na jména, ale musí být vázány na konkrétní IPv4 adresy serveru (ano, děláme tunel pomocí IPv4). Můžete si vybrat, buď použijete IPv4 adresu 0.0.0.0, což přichytí certifikát na všechny IPv4 adresy, nebo se dá použít konkrétní (v našem případě 30.0.0.1). Hodnotu CertHash jste zjistili v jednom z předchozích kroků - musí odpovídat vašemu certifikátu, který máte na serveru. Zatímco položka appid jestále stejná a to přesně ta, kterou vidíte ve výpisu. Nastavítka DSMapperUsage a ClientCertNegotiation zapínají ověřování klientských certifikátů pomocí Active Directory.

NETSH HTTP ADD SSLCERT IPPort=30.0.0.1:443 CertHash=F61867B88AD320117FD63ECE863C043794F33661
appid={5d8e2743-ef20-4d38-8751-7e400f200e65} ClientCertNegotiation=enable DSMapperUsage=enable

img05_ipv6-iphttps-server-interface-httpsys.png

Když tohle máte, mělo by se již dát z KamilPC vyzkoušet toto HTTPS připojení. Pokud to všechno funguje, můžete do prohlížeče zadat https://ipv6.gopas.cz/IPHTTPS. Sice nic moc neuvidíte, ale to je právě dobře - nemělo by se vám zobrazit žádné certifikátové varování a prohlížeč by měl téměř donekonečna čekat na odezvu, která nepřichází a nepřichází. Ono to sice není normální HTTP, ale ten SSL obal tím otestujete.

Dále musíme této virtuální síťovce na serveru nastavit IPv6 adresu, zapnout Forwarding zveřejnit tuto routu (Publish) a zveřejnit i další routy, speciálně do vnitřní sítě.

NETSH INTERFACE IPv6 SET ADDRESS Name=IPHTTPSInterface fc00:3::1
NETSH INTERFACE IPv6 SET INTERFACE IPHTTPSInterface Forwarding=enable Advertise=enable
OtherStateful=enable ManagedAddress=disable
NETSH INTERFACE IPv6 SET ROUTE fc00:3::/64 IPHTTPSInterface Publish=yes
NETSH INTERFACE IPv6 SET ROUTE ::/0 Link Publish=yes

img06_ipv6-iphttps-server-interface-routes.png

V předchozím výpisu směrovací tabulky si všimněte, že potřebujeme, aby náš směrovač London zveřejňoval (Publish) do této nové tunelové síťovky jak routu do Londýna, tak také routu výchozí (default route). Ty byly ale nakonfigurovány již dříve, takže jsem se s nimi znovu nepáral. No a nyní už stačí pouze nastavit klienta. Uf, to je dřina. Takže na klientském počítači je potřeba vypnout všechny ostatní tunely a vytvořit novou virtuální IP-HTTPS síťovku:

NETSH INTERFACE isatap set state disabled
NETSH INTERFACE teredo set state disabled
NETSH INTERFACE 6to4 set state disabled
NETSH INTERFACE HTTPSTUNNEL Add Interface Client https://ipv6.gopas.cz/IPHTTPS State=Default AuthMode=Certificates

img07_ipv6-iphttps-client-interface.png

img08_ipv6-iphttps-client-ipconfig.png

A už si můžete konektivitu ověřit jen jednoduchým PINGem. V případě, že se chcete podívat do logu na IP-HTTPS serveru, jaké počítače se vám na něm ověřovaly, stačí hledat následující události:

Log: Security
Task Category: Logon
Level: Information
Event ID: 4624
Logon Type: 3
Security ID: GOPAS\KamilPC$
Authentication Package: SChannel
Logon Process: SChannel

A to je pro dnešek všechno! Teď už umíte lokální IPv6, směrování i to nejsložitější a nejbezpečnější tunelování! Příště nás čeká manuální konfigurace Direct Access.

Autor: Ondřej Ševeček

Živě je díky vašim hlasům ve finále ankety Křišťálová Lupa. Podpořte nás prosím ještě v závěrečném kole. Děkujeme!


Sledujte Živě na Facebooku

celkem 0

Poslední názory Názory



DEJTE NÁM TIP NA ČLÁNEK

Živě je díky vašim hlasům ve finále ankety Křišťálová Lupa. Podpořte nás prosím ještě v závěrečném kole. Děkujeme!



Aktuální číslo časopisu Computer
  • Testy nejnovějších produktů na českém trhu.
  • Informace ze světa internetu i bezpečnosti.
  • Plné verze programů zdarma pro všechny čtenáře.

Partnerská sekce pro IT profesionály
Microsoft TechNet/MSDN