IPSec z L2TP lub bez?

Mam na myśli to pytanie . Żeby było jasne: tak naprawdę nie chodzi o starą debatę PPTP kontra L2TP. ;-)

Z powodzeniem skonfigurowałem racoon jako serwer IKE bez uruchomionej implementacji L2TP i działa całkiem dobrze. Mogę założyć tunel z laptopa do serwera VPN i używać go jako bramy internetowej. O ile widzę, wszystkie pakiety IP są bezpiecznie enkapsulowane. Voilà, to wszystko, czego chciałem. Ale, ups, tylko OS X / iOS obsługuje ten typ „zwykłego IPSec” VPN od razu po wyjęciu z pudełka, ale muszę też obsługiwać inne platformy. Wszystkie inne systemy operacyjne, w tym Windows i Android, wydają się wymagać dodatkowego połączenia PPP, które jest ustanawiane przy użyciu L2TP przy użyciu oprogramowania takiego jak xl2tpd. Byłem ciekawy, więc ustawiłem go ponownie za pomocą racoon + xl2tpd i stworzyłem tunel L2TP / IPSec. I działa dokładnie tak samo jak bez L2TP.

Jaka jest w ogóle korzyść z używania L2TP? Tak, mogę tunelować inne protokoły, takie jak X.25, ale większość użytkowników nie potrzebuje niczego poza IP. Mogę założyć powody, dla których stwardnienie rozsiane robi to bardziej skomplikowane niż rzeczy VPN. Ale przynajmniej nie rozumiem, dlaczego Android nadal potrzebuje tej warstwy L2TP, co moim zdaniem tylko dodaje złożoności i narzutu. I tak, wiem, że istnieje dodatkowe oprogramowanie klienckie, aby pokonać ograniczenia systemu operacyjnego.

Nawet przy uwierzytelnianiu nie ma różnicy: zdalne uwierzytelnianie odbywa się zwykle przy użyciu wstępnie współdzielonych kluczy lub certyfikatów, a uwierzytelnianie użytkownika odbywa się za pośrednictwem XAuth lub CHAP / PAP. - Jep, upraszczam tutaj, ale wiesz o co mi chodzi.

Czy ktoś wie, dlaczego L2TP jest nadal standardowym sposobem w IPSec? Czy coś brakuje?

Android od 4.0 obsługuje zwykły protokół IPsec od razu po wyjęciu z pudełka. Jest też kilka aplikacji dla 4.x, które zapewniają inne protokoły VPN na nierootowanych urządzeniach (np. IKEv2 / IPsec z klientem strongSwan VPN ).

Od systemu Windows 7 można korzystać z wbudowanego klienta IKEv2 / IPsec. Udzielony racoon nie obsługuje IKEv2, ale istnieją inne implementacje typu open source (np. StrongSwan lub Libreswan ).

Czy ktoś wie, dlaczego L2TP jest nadal standardowym sposobem w IPSec?

Nie powiedziałbym, że jest to standardowy sposób, ponieważ np. Windows 7 i nowsze najpierw wypróbowują IKEv2, ale zgadzam się, że klienci nadal oferują go dość wyraźnie.

Jednym z powodów jego początkowego sukcesu było prawdopodobnie to, że pozwoliło to na ponowne wykorzystanie infrastruktury PPP, która istniała dla połączeń telefonicznych (będąc jednocześnie bezpieczniejszym i znormalizowanym niż PPTP). A ponieważ instalacje L2TP istnieją już od dłuższego czasu i zostały wdrożone dość szeroko, o każdym kliencie miał (i nadal ma) je obsługiwać. Ułatwia to oczywiście dostawcom VPN, ponieważ mogą zmniejszyć liczbę oferowanych technologii VPN. Zmniejsza to jednak motywację do wdrażania innych protokołów u klientów.

Mogą również występować problemy z licencjonowaniem uniemożliwiające korzystanie z innych protokołów, na przykład wspomniane powyżej implementacje IKEv2 są licencjonowane na licencji GPL, których Apple w iOS i Google w Androidzie zwykle unikają na korzyść bardziej licencjonowanego oprogramowania, takiego jak racoon (które oba używać w swoich produktach).

Na początku (dawno temu, zanim implementacja BSD IPsec została zintegrowana z jądrem Linuksa) nie było możliwe użycie IPsec VPN przez bramę NAT, ponieważ nie było możliwe NAT IPsec. IPsec został opracowany dla IPv6, który już nie zna NAT, a używanie IPsec dla IPv4 zawsze było pewnego rodzaju włamaniem. Brak NAT dla tak zwanych wojowników drogowych korzystających z IPv4 był nieunikniony. Jedynym sposobem, aby działał w latach 90., było użycie L2TP, ponieważ L2TP działa na UDP i NAT jest możliwy. Cisco wybrało to rozwiązanie i wdrożyło je w swoich koncentratorach VPN. To czas, kiedy stał się „standardem”. Aby zapewnić zgodność z Cisco, wielu innych dostawców wdrożyło go. To jest powód, dla którego Apple go wdrożył i dlatego też Android go obsługuje.

Ale tunelowanie ramek Ethernet warstwy 2 przez tunel IPsec nigdy nie było świetnym pomysłem na komunikację tylko IP. W latach 90. istniały inne protokoły, które wymagały mostkowania, takie jak IPX, ale obecnie wszyscy mówią IP. Aby pozbyć się napowietrznych ramek warstwy 2, RFC 3948 zaproponował „Hermetyzację pakietów UDP protokołu IPsec ESP”. Działa to również poprzez umieszczenie protokołów ESP i AH w pakietach UDP i dzięki temu NAT jest możliwe. Ale pozwala uniknąć ramek warstwy 2. To nowoczesne rozwiązanie, które każdy powinien wypróbować w pierwszej kolejności. Korzystanie z L2TP jest starszym sposobem, który istnieje tylko dla kompatybilności wstecznej.