Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



17.09.2019

PLNOG23 czyli sieci 5G,...

Największa polska konferencja telekomunikacyjna powraca do Krakowa! Wśród nowości ścieżka...
05.09.2019

Cloudya – nowa usługa NFON

Po ponad dekadzie ciągłego rozwoju technologii Cloudya, swobodna i niczym nie ograniczona...
02.09.2019

Na dużą skalę

Kaspersky Hybrid Cloud Security
02.09.2019

Bezpieczny brzeg sieci

Fortinet Secure SD-Branch
02.09.2019

Nowoczesne centra danych

AMD EPYC
30.08.2019

Dostęp do AI i ML

VMware Cloud Foundation
30.08.2019

Lekkość i moc

Toshiba Portégé A30-E
30.08.2019

Bez przestojów

APC Easy UPS On-Line
29.08.2019

Duże moce

Lenovo ThinkSystem SR635 i SR655

(Prawie) bezobsługowa sieć VPN

Data publikacji: 29-08-2019 Autor: Piotr Wojciechowski
SIEĆ TYPU HUB-AND-SPOKE

W sieciach wielu przedsiębiorstw dane przechowywane i przetwarzane są w dedykowanych centrach danych. Wyzwaniem dla administratorów jest stworzenie wydajnej, bezpiecznej, a przede wszystkim skalowalnej sieci, która pozwoli oddziałom firmy na łączenie się z centralnymi zasobami. DMVPN jest jedną z technologii realizujących te potrzeby.

 

DMVPN (Dynamic Multipoint VPN) jest technologią stworzoną przez firmę Cisco. Mimo że oficjalnie dostępna jest jedynie na urządzeniach tej firmy, od wielu lat cieszy się bardzo dużą popularnością, gdyż pozwala na budowę skalowalnej sieci VPN w topologii hub-and-spoke i dual-hub-and-spoke z możliwością zapewnienia bezpośredniej komunikacji pomiędzy routerami końcowymi (spoke) (patrz ramka Hub-and-spoke). Routery w węzłach przechowują minimalną ilość informacji niezbędnych do nawiązania i utrzymania sesji z koncentratorami. Co więcej, dołączenie nowego węzła nie wymaga rekonfiguracji koncentratora, a konfiguracja węzłów jest bardzo szablonowa. Rozwiązania tego typu określa się terminem zero-­to­uch provisioning.

> WARSTWA TRANSPORTOWA

W DMVPN warstwa transportowa nie ma wielkiego znaczenia tak długo, jak długo zapewniony jest routing IPv4 lub IPv6 pomiędzy koncentratorem a węzłem końcowym. Mogą to być zarówno sieci prywatne, jak i zwykłe połączenie internetowe. Nie ma przy tym znaczenia, w jakiej technologii jest ono realizowane. Dzięki takiej elastyczności administratorzy mogą zapewnić łączność do nawet najbardziej odległych czy przestarzałych technologicznie lokalizacji oraz redundancję połączeń – podstawowe łącze może wykorzystywać firmową prywatną sieć WAN, zapasowe zaś połączenie poprzez sieć LTE/3G. Rou­tery brzegowe mogą mieć bezpośrednie połączenie z siecią publiczną lub znajdować się w sieci prywatnej, za innym urządzeniem dokonującym translacji NAT. Nie muszą one mieć także stałych adresów IP – mogą być przydzielane dynamicznie za pomocą protokołu DHCP. To spoke będzie inicjował połączenie z hubem, zatem to adres koncentratora VPN musi być niezmienny i zostanie zapisany w konfiguracji urządzenia zainstalowanego w węźle końcowym. Koncentrator zaś własnymi mechanizmami będzie weryfikował łączący się z nim rou­ter brzegowy.

DMVPN wykorzystuje trzy powszechne standardy do realizacji usługi bezpiecznego nawiązywania połączenia i transportu danych: tunele GRE (Generic Routing Encapsulation) zapewniające tunelowanie pakietów pomiędzy lokalizacjami, protokół NHRP (Next Hop Resolution Protocol) odpowiadający za mapowanie informacji oraz przekazywanie ich w trybie on-demand, czyli wtedy gdy są niezbędne do zrealizowania transmisji, oraz IPSec umożliwiający szyfrowanie ruchu.

W ramkach Konfiguracja koncentratora oraz Konfiguracja spoke’a znajdują się fragmenty konfiguracji rozwiązania DMVPN hub-and-spoke z redundancją połączeń – podstawowe poprzez sieć WAN oraz zapasowe poprzez sieć internetową. W kolejnych częściach artykułu będziemy się odnosić bezpośrednio do fragmentów tej konfiguracji.

> TRANSPORT ZA POMOCĄ MGRE

Aby uruchomić tunel GRE pomiędzy dwoma urządzeniami, zarówno koncentrator, jak i klient muszą znać adresy IP urządzenia z drugiego końca tunelu. Bardzo szybko rzuca się w oczy niepraktyczność tego wymagania w większych sieciach – dla każdego klienta na koncentratorze wymagałoby to konfiguracji odpowiedniego tunelu oraz podania adresu IP węzła klienckiego, a ten przecież może być przydzielany dynamicznie. Wielu operatorów nie pozwala na statyczną konfigurację adresu i często zmienia się on za każdym razem, gdy połączenie internetowe jest nawiązywane. Operator może również przydzielać adresy prywatne i dokonywać odpowiedniej translacji NAT w swojej sieci, aby zapewnić połączenie z internetem.

W DMVPN wykorzystywany jest specjalny typ tuneli GRE zwanych mGRE, czyli multipoint GRE. Dzięki takiemu rozwiązaniu na koncentratorze VPN tworzymy tylko jeden interfejs tunelu GRE i wiążemy go fizycznym lub logicznym interfejsem, który będzie służyć za powiązany z tunelem interfejs źródłowy – pamiętajmy, że musi on mieć stały, niezmienny adres IP. Jeżeli dla redundancji stosujemy dwa połączenia lub więcej, dla każdego z nich musimy stworzyć oddzielny interfejs tunelu GRE. O ile adresy podsieci wewnętrznej w tunelu (overlay network) muszą być znane (sami je ustalamy w projekcie rozwiązania), o tyle adres w sieci transportowej koncentratora w mGRE musi być znany jedynie urządzeniu klienckiemu. Oznacza to, że po stronie koncentratora nie musimy statycznie konfigurować adresu każdego urządzenia z węzła osobno, a dzięki temu te adresy mogą być przez operatora przydzielane dynamicznie.

> KONFIGURACJA IKEV2 I IPSEC

Aby zabezpieczyć dane przesyłane pomiędzy routerami, musimy je zaszyfrować. W DMVPN do szyfrowania danych wykorzystywany jest IPSec. Zestawienie szyfrowanego tunelu IPSec odbywa się na kilka sposobów różniących się od siebie wymaganymi parametrami czy zastosowanymi mechanizmami. Proces ten składa się z dwóch faz. Pierwsza z nich to faza negocjacji, w trakcie której urządzenia ustanawiają bezpieczny, uwierzytelniony kanał komunikacji, a także uzgadniają wykorzystywane klucze kryptograficzne. Powszechnie stosowanym protokołem tej fazy jest IKEv1 (w dokumentacji i konfiguracji Cisco używana jest nazwa ISAKMP, który tak naprawdę jest jedynie częścią IKEv1, lecz przyjęło się posługiwać tymi nazwami zamiennie). Obecnie IKEv1 jest sukcesywnie zastępowany nowszą wersją IKEv2. W trakcie drugiej fazy następuje zestawienie tuneli IPSec służących do przesyłania danych. Ponieważ są to tunele jednokierunkowe, zawsze powinniśmy pomiędzy parą urządzeń widzieć aktywne dwa tunele.

Ponieważ protokół IKEv1 jest sukcesywnie wypierany przez IKEv2, w tym artykule skupimy się na nowszej generacji protokołu. Konfiguracja ta będzie identyczna dla wszystkich urządzeń w sieci DMVPN (patrz ramka Konfiguracja IKEv2 i IPSec). Pierwszym jej elementem jest określenie parametrów szyfrowania i funkcji skrótu, które będą wykorzystywane w pierwszej fazie. Pamiętajmy, że muszą one być identyczne. Przykładowa konfiguracja w wierszach 1–4 ma zdefiniowane pojedyncze parametry szyfrowania, funkcji skrótu i grupy DH (dodatkowe zabezpieczenie). Konfiguracja ta zwana jest proposal (propozycja), gdyż każdy z tych trzech parametrów może być listą. Urządzenia porównują wtedy dozwolone w konfiguracji algorytmy i wykorzystują najsilniejszy z tych, które zostały ustawione na każdym z nich. Następnie podpinamy stworzony proposal do polityki. Jeżeli nasz router nie ma skonfigurowanych VFR-ów lub tunel ma być częścią globalnej tablicy routingu, musimy ustawić parametr match fvrf any.

 

[...]

 

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Pracuje jako niezależny konsultant IT. Posiada certyfikat CCIE.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"