Microsoft vykročil na cestu jeho nasazení razantním krokem v podobě implementace do operačního systému Windows 2000, v čemž pochopitelně pokračují jeho nástupci XP, 2003 a další. V následujících odstavcích vás chceme zavést do tohoto možná trochu tajemného světa a upozornit na zajímavosti, jež třeba prozatím unikly vašemu zkoumání, ačkoliv jste se již s IPSecem seznámili.
Přínosy administrace
pomocí NETSH
Určitě nebudeme příliš přehánět, když řekneme, že mezi nejproměnlivější části implementace IPSecu ve Windows patří příslušné ovládací a monitorovací nástroje. Přestože samotný grafický editor lokálních politik či jejich ekvivalentů v objektech Group Policy zásadních změn nedoznal, bouřlivý vývoj se odehrával na jiných místech. Mezi nejzásadnější novinky se již před lety s příchodem Windows XP zařadil IP Security Monitor, jehož proměny rozhodně nebyly kosmetické. Z chabého, spíše provizorního nástroje ve formě spustitelné aplikace se stalo propracované rozhraní v podobě snap-in pro konzolu MMC. K dispozici je široká škála parametrů, díky nimž lze sledovat fáze vyjednávání i vytvořené bezpečnostní asociace stejně jako statistiky o množství přenesených dat.
Velkou míru invence a smyslu pro humor prokázali tvůrci z Redmondu také při tvorbě nástrojů pro automatizování správy IPSecu, jež pracují v příkazové řádce. Ve Windows 2000, kde byl IPSec Microsoftem zaveden poprvé, byl k dispozici pouze nástroj ze sady Resource Kit, neboť přímo v systému řádkové rozhraní nebylo. Program IPSecpol.exe sloužil především k automatizaci prováděných operací a nedisponoval ve srovnání s grafickým rozhraním žádnými výjimečnými vlastnostmi. S nástupem klientského systému Windows XP se objevuje novinka v podobě programu Ipseccmd.exe, jenž byl jakousi novou generací ovládání z konzoly. Nástroj nabízí tři režimy, dovoluje vzdáleně ovládat konfigurované počítače a upozornění na nekompatibilitu s Windows 2000 napovídá, že se objevují nové možnosti. K dispozici je režim pro dotazování, jenž vypisuje aktuální statistiky, dále je možné definovat jak statické politiky (obdobně jako v grafickém rozhraní), tak politiky dynamické, jež jsou funkční dočasně (přesněji do restartu služby Policy Agent) a v grafickém rozhraní nemají svůj ekvivalent. Prozatímním vyvrcholením této vývojové řady je definitivní zakotvení funkcionality pro IPSec do velmi univerzálního konzolového nástroje Netsh.exe, jehož možnosti jsou i jinak mimořádné. Tato varianta správy je prozatím dostupná jen ve Windows Server 2003 a přináší některé velmi zajímavé novinky, o nichž se nyní zmíníme.
V každém případě je dobré si uvědomit, že Netsh.exe dovoluje konfigurovat parametry, které v grafickém rozhraní nemají ekvivalent. Jednou z novinek je tvorba tzv. persistentních (persistent) politik, jež jsou sourozencem doménových (v GPO) a lokálních politik pro IPSec. Jejich úkolem je pracovat vždy, a to bez ohledu na to, zda se na počítač úspěšně podaří "doručit" doménové nastavení či zda se správně provede politika lokální. Persistentní sada zásad tedy chrání server třeba po dobu startu operačního systému před působností GPO a slouží jako pojistka pro chvíle, kdy "nezaberou" ostatní politiky. Takováto odolná politika se vytváří podobně jako varianty lokální či doménové, s tím rozdílem, že parametr "location" je označen jako "persistent".
Další zajímavou možností nástroje Netsh.
exe jsou funkce pro diagnostiku. Pomocí příkazu "show" je možné dosáhnout výpisu či exportu aktuálního nastavení politik v čitelné podobě (např: netsh ipsec static show all >), a to včetně přesměrování do souboru. Pokud se zabýváte řešením potíží při sestavování zabezpečené komunikace, určitě oceníte detailní logování událostí při vyjednávání o zabezpečení IKE. Velmi podrobný výpis prováděných operací získáte zapnutím trasovacího režimu (netsh ipsec dynamic set config ikelogging 1), díky čemuž bude do souboru systemrootdebugoakley.log velmi podrobně zaznamenáván průběh vyjednávání. Na závěr přidejme ještě jeden tip pro ladění a monitorování: samotný ovladač (IPSec driver), jež odpovídá za kontrolu zpracování síťového provozu, lze přimět k zasílá-
ní podrobnějších zpráv o činnosti do systémového logu. Pokud použijete příkaz pro zvýšení úrovně diagnostiky (netsh ipsec dynamic set config ipsecdiagnostics 7), objeví se ve vašem Event Vieweru záplava podrobných informací. Pozor, může jich být opravdu hodně!
Přestože nástroj Netsh.exe vypadá na první pohled nepřístupně, naučte se s ním pracovat. Jeho možnosti vám nejen v případě IPSecu přinesou příjemná překvapení.
IPSec a NAT-Traversal
Pokud jste zaváděli v prostředí Windows 2000 řešení na bázi IPSecu, třeba přístup vzdálených klientů pomocí VPN s protokolem L2TP/IPSec, pravděpodobně jste narazili na tradiční omezení v podobě nekompatibility se službou Network Address Translation. V této oblasti došlo v posledních letech k zajímavému vývoji a Microsoft do prostředí Windows Server 2003 zabudoval dnes již samozřejmou funkci NAT-Traversal, u níž se zastavíme, neboť se kolem ní stále vyskytuje řada nejasností.
Vylepšení NAT-T bylo v průběhu posledních let vyvinuto jako reakce na stále větší oblibu technologie IPSec a její problémy se službami NAT. Stručně řečeno, chráněné síťové pakety byly po běžném překladu adres zničeny, neboť služba NAT mění adresy IP, čísla portů a také třeba některé kontrolní součty, což posléze naprosto neodpovídá původní digitálně podepsané informaci. Vylepšení NAT-T zahrnuje jednak dodatečné připojení nové hlavičky protokolu UDP (obvykle na portu 4500), jednak změnu vyjednávací fáze, což zajišťuje, že protistrany se informují o svých schopnostech NAT-T provádět. Přes mezilehlé služby překladu adres pak pakety proplují díky tomu, že je modifikováno zástupné záhlaví UDP a chráněný obsah je nedotčen.
Častou nejasností je to, které prvky na síťové cestě musí NAT-T zvládat. Obecně platí, že se dohadují vždy cílové protistrany: pokud použijete spojení L2TP/IPSec pro sestavení VPN, pak musí funkcí NAT-T disponovat jak klientský operační systém, jenž spojení iniciuje, tak cílový server VPN, jenž volání přijímá. Pokud se zaměříme na platformu Windows, na straně klienta vyhoví Windows XP SP 2, Windows 2000 s příslušnou aktualizací (818043), dále pak Windows 98, Me a NT 4.0 Workstation s aplikací Microsoft L2TP/IPSec VPN Client. Na serverové straně je schopen takovéto spojení přijmout a korektně vyjednat pouze Windows Server 2003 a jeho služba Routing and Remote Access, starší Windows 2000 to nedokáží, a to ani po aktualizaci. Co se týče mezilehlých služeb NAT, jež jsou mezi těmito koncovými body, funkce NAT-T na ně neklade žádné nároky ohledně překladu, avšak vyžaduje otevření minimálně jednoho dodatečného spojení na bráně firewallu - jde o již zmíněný port 4500 protokolu UDP. Jako mezilehlá služba NAT tedy dobře poslouží třeba i stávající server Windows 2000 s překladem adres v rámci služby RRAS.
Přestože podle výše uvedených informací vypadá vše jednoduše jako jednoznačné vítězství, služba NAT-T s sebou přece jen nese určité implementační potíže. Existuje minimálně jedno doporučení Microsoftu, jež byste při navrhování své struktury VPN neměli ignorovat: výrobce nedoporučuje schovávat server VPN za službu NAT tak, aby na klientském počítači bylo zadáváno jako cílová adresa IP rozhraní služby NAT, číhající před serverem. Místo toho je doporučeno server VPN vždy "vystrčit" do internetu, aby klient (sám klidně může být schován za překladem adres) adresoval veřejnou adresu IP na internetu. Tvůrci Windows XP šli dokonce tak daleko, že možnost vytvoření takového spojení pomocí NAT-T na klientském systému zakázali, odblokování je nutné provést v registru. I s tímto omezením se však stále jedná o bezesporu dobře využitelnou technologii.
L2TP/IPSec a Preshared Key
Přestože již ve Windows 2000 byla implementována technologie IPSec se třemi možnostmi autentizace protistran při navazování spojení, nebylo možné využít všech variant v rámci sestavování tunelů VPN. Připomeňme, že protokol Kerberos vyhovuje pro ověření počítačů v rámci lokální sítě, ale k navázání spojení VPN z veřejné sítě nikoliv. Nasazení certifikátů pro klientské počítače za účelem ověření vyžaduje implementaci náročné infrastruktury PKI. Ačkoliv od počátku byla k dispozici metoda třetí - preshared key (předsdílený klíč) - pro účely sestavení tunelu VPN ji použít nešlo.
Tvůrci systému, zřejmě s cílem mimo jiné umožnit připojení uživatelů k četným zařízením jiných výrobců a vyloučit nároky na PKI, tuto funkci do novějších verzí Windows XP a Windows Serveru 2003 zabudovali. Klientský počítač a server se nyní mohou vzájemně ověřit pomocí předem dohodnutého tajemství, jež se ve formě textového řetězce vkládá jak na straně klienta při konfiguraci nového síťového spojení VPN, tak na straně serveru v rámci služby RRAS. Ve Windows XP najdeme příslušnou volbu na záložce Security pod tlačítkem IPSec Settings, v ovládací konzole služby RRAS pak hledejte nastavení ve vlastnostech serveru na záložce Security (oba případy ukazují obrázky).
Pro úplnost dodejme, že zde popsaná autentizační metoda prostřednictvím sdíleného klíče ovlivňuje vzájemné ověření počítačů, mezi nimiž vzniká tunel IPSec. Protože protokol L2TP/IPSec ověřuje nezávisle jak počítače, tak samotného uživatele, týká se změna pouze autentizace identity komunikujících strojů - uživatel je samozřejmě stále nucen ověřit svoji identitu prostřednictvím zavedených protokolů jako EAP či MS-CHAP v2. I přesto je však dobré přistupovat obezřetně především ke způsobům, jak sdílená tajemství předávat svým uživatelům. 05s0074/jp o
IPSecr
Informační zdroje o IPSecu ve Windows
• www.microsoft.com/windowsserver2003/technologies/
networking/ipsec/default.mspx
Články o technologii NAT Traversal
• www.isaserver.org/articles/IPSec_Passthrough.html
• www.microsoft.com/technet/community/columns/
cableguy/cg0802.mspx
Jednou ze silných vlastností rozhraní Netsh je export
různých nastavení. Žádným problémem samozřejmě není přesměrování do textového souboru.
Novinkou je IP Security Monitor v podobě konzoly MMC. Velmi dobře lze sledovat veškeré fáze komunikace.
Služba RRAS na straně serveru nabízí pro konfiguraci sdíleného klíče pro IPSec položku na kartě Security v obecných
vlastnostech serveru.
Na straně klientského počítače je potřeba sdílený klíč pro autentizaci IPSecu ručně zadat ve vlastnostech klientu VPN.
PŘEDPLATNÉ
ČLÁNKY DO MAILU