fbpx

Podkast 22T31 IPSec – IKEv1 oraz IKEv2

Więcej miejsc do posłuchania:

Spotify

WERSJA TEKSTOWA

Cześć, witam Cię w dzisiejszym odcinku mojego podkastu. Dzisiejszy temat to rozwinięcie IPsec-a w dostępie zdalnym dla użytkowników. W tamtym tygodniu wspominałem o różnych aspektach budowania i wybierania rozwiązania VPN-owego dla użytkowników końcowych. Dzisiaj trochę więcej na temat różnic pomiędzy IKEv1 i IKEv2.

Wspomniałem ostatnio, że ograniczeniem protokołu IPsec (IPsec jest pewnym frameworkiem, czyli takim zbiorem protokołów) i mamy dwie fazy negocjowania kluczy i zestawów dotyczących szyfrowania i sprawdzania integralności danych. Pierwsza faza to jest IKE, czyli faza, w której dwie strony wymieniają informacje pomiędzy sobą na temat tego, jakim zestawem parametrów będą zabezpieczać transmisje docelowych danych, które będą transmitowane i zabezpieczane w fazie drugiej. Wspominałem w tamtym tygodniu, że w IKEv1 nie umożliwiało uwierzytelniania użytkowników. Po prostu nie zaimplementowano takiej możliwości, bo pierwotnie ten protokół był planowany bardziej do implementacji typu Site to Site, czyli łączymy dwie lokalizacje i je ze sobą komunikujemy.

Natomiast relatywnie niedawno, patrząc na cały protokół IPsec (cały ten framework, wprowadzono IKEv2 i to co jest ważne to w tej wersji dodano możliwość uwierzytelniania użytkowników w trzech metodach.

Pierwsza metoda to MS-CHAP. Czyli metoda, w której możemy wykorzystać protokół Microsoftu do uwierzytelniania użytkowników w oparciu o login i hasło. Jeżeli korzystamy np z jakiegoś rozwiązania domenowego. Druga możliwość to dostęp w wykorzystaniu tokenów, czyli GTC. Trzecia możliwość to wersja TLS, czy EAP-TLS, daje nam możliwość wykorzystania certyfikatów do uwierzytelnienia użytkownika końcowego i możemy wtedy cały nasz schemat uwierzytelniania oprzeć tylko o protokół, czy o ten framework, IPsec czy o protokół IKEv2 + IPsec w drugiej fazie szyfrowania i sprawdzenie integralności danych.

Jeżeli chodzi o IKEv1, czyli tak jak się to robiło wcześniej, stosowało się pewne obejście do tego braku funkcjonalności uwierzytelniania użytkowników. Czyli nakładało się na tunel IPsec-owy, czyli bardziej wkładało się do niego protokół L2TP (Layer 2 Tunneling Protocol). Jest to protokół, który umożliwia tunelowanie ruchu i umożliwia również uwierzytelnianie użytkowników. Ta część uwierzytelniania użytkowników była wykorzystywana jako uzupełnienie tej funkcji dotyczącej IKEv1 do tego, żeby dostarczyć tą funkcjonalność wpisywania użytkownika i hasła do całego schematu uwierzytelniania. Oczywiście w większości implementacji takich produkcyjnych czy komercyjnych to jest niewidoczne dla użytkownika. Czyli nie jest to też widoczne dla administratora. Jest to realizowane pod spodem w sposób automatyczny, przez danego producenta zaimplementowane. Natomiast jeżeli robisz to w jakiś implementacjach bardziej manualnych. Sam sobie to konfigurujesz na jakimś Linuxie albo korzystasz bardziej z MikroTika, to możesz sobie wtedy wykonać tego typu konfigurację, ale musisz ją wykonać bardziej ręcznie, czyli zaplanować jeden protokół, skonfigurować go, zaplanować drugi protokół, skonfigurować. Połączyć oba elementy i wtedy mieć dostęp zdalny.

Generalnie jest to podsumowanie tego, czym się też różnią te rozwiązania droższe od tych tańszych i od tych Open Source. Te po prostu droższe najczęściej oprócz tego, że mają support, dostarczają większy poziom automatyzacji i scenariusze automatycznego onboardingu. Dodatkowe elementy, które są przydatne w większej skali. W mniejszej skali one nie są pewnie takie istotne i tak mniej więcej ten podział wygląda jak go obserwuje, czyli więksi klienci używają produktów płatnych, mniejsi klienci używają produktów tańszych albo wręcz open source. Podobna jest analogia do routingu. Też widziałem takie implementacje, gdzie ktoś sobie na Linuxie stawia router lub na grupie takich Linuxów. W momencie, gdy tego ruchu mu się pojawia więcej albo rozwija się ten biznes bardziej i pojawia się więcej osób bądź nakład administracyjny jest już za duży, to przechodzi na rozwiązanie komercyjne. W związku z tym zawsze ten balans pomiędzy tą łatwością konfiguracji, dostępnością informacji, wsparciem a ceną jest zawsze oceniany indywidualnie przez każdego administratora, czy przez każdego dyrektora, który odpowiada za IT i za budżet.

Na dziś to tyle, dziękuję Ci za uwagę i do usłyszenia już za tydzień.


Kliknij w obrazek, aby przejść do zapisu na warsztaty

Autor: Darek Koralewski

Od początku swojej kariery, czyli od 2004 roku, zajmuję się sieciami komputerowymi ze szczególnym uwzględnieniem ich bezpieczeństwa oraz sieciami programowalnymi. Mam na swoim koncie całą listę certyfikatów różnych producentów, dwa najważniejsze to te poświadczające najwyższy poziom wiedzy eksperckiej z zakresu rozwiązań Aruba ClearPass ACCX#901 oraz z projektowania sieci opartych o rozwiązania Aruba ACDX#1255. Więcej informacji możesz znaleźć na moich portalach społecznościowych.