Ostatnio WireGuard przyciąga dużo uwagi, w rzeczywistości jest nową „gwiazdą” wśród VPNAle czy jest tak dobrze, jak się wydaje? Chciałbym omówić kilka obserwacji i przeanalizować wdrożenie. WireGuard, aby wyjaśnić, dlaczego nie jest to rozwiązanie, które zastąpi IPsec lub OpenVPN.
W tym artykule chciałbym obalić kilka mitów [na temat WireGuard]. Tak, to długa lektura, więc jeśli jeszcze nie zaparzyłeś sobie herbaty lub kawy, to teraz jest na to czas. Chciałbym również podziękować Peterowi za korektę moich chaotycznych myśli.
Moim celem nie jest dyskredytowanie twórców oprogramowania. WireGuard, dewaluować ich wysiłki lub pomysły. Ich produkt działa, ale osobiście uważam, że jest przedstawiany jako coś zupełnie innego niż jest w rzeczywistości – jako zamiennik IPsec i OpenVPN, który w zasadzie już nie istnieje.
Jako uwagę chciałbym dodać, że odpowiedzialność za takie pozycjonowanie WireGuard są przekazywane przez media, które o nim informowały, a nie przez sam projekt czy jego twórców.
Ostatnio na temat rdzenia Linux Nie było zbyt wielu dobrych wiadomości. Powiedziano nam o monstrualnych lukach w zabezpieczeniach procesorów, które zostały złagodzone przez oprogramowanie, a relacja Linusa Torvaldsa na ten temat była zbyt prostacka i nudna, napisana utylitarnym językiem programisty. Harmonogram zadań czy stos sieciowy poziomu 0 to również nie do końca jasne tematy dla kolorowych magazynów. A potem pojawia się… WireGuard.
Na papierze wszystko brzmi świetnie: ekscytująca nowa technologia.
Ale spójrzmy na to trochę bliżej.
Dokumentacja techniczna WireGuard
Ten artykuł jest oparty na oficjalna dokumentacja WireGuard, napisany przez Jasona Donenfelda, w którym wyjaśnia koncepcję, cel i techniczną implementację [WireGuard] w rdzeniu Linux.
Pierwsze zdanie brzmi:
WireGuard […] ma na celu zastąpienie zarówno protokołu IPsec w większości przypadków użycia, jak i innych popularnych rozwiązań opartych na przestrzeni użytkownika i/lub protokole TLS, takich jak OpenVPN, będąc jednocześnie bezpieczniejszym, bardziej produktywnym i łatwiejszym w użyciu [narzędziem].
Oczywiście główną zaletą wszystkich nowych technologii jest ich prostota [w porównaniu do poprzedników]. Ale VPN też powinien być wydajne i bezpieczne.
Więc co dalej?
Jeśli powiesz, że to nie jest to, czego potrzebujesz [z VPN], możesz zakończyć czytanie tutaj. Zaznaczę jednak, że takie zadania są ustawione dla każdej innej technologii tunelowania.
Najciekawszy z powyższego cytatu zawiera się w słowach „w większości przypadków”, które oczywiście zostały zignorowane przez prasę. I tak oto znaleźliśmy się tam, gdzie wylądowaliśmy z powodu chaosu wywołanego przez to zaniedbanie - w tym artykule.
Czy to się wydarzy? WireGuard zastąpić mój VPN typu site-to-site [IPsec]?
Nie. Nie ma po prostu szans, że duzi dostawcy, tacy jak Cisco, Juniper i inni, wykorzystają tę technologię w swoich produktach. WireGuardNie „wskakują do przejeżdżających pociągów”, chyba że zajdzie taka pilna potrzeba. Później omówię niektóre powody, dla których prawdopodobnie nie będą mogli zainstalować swoich produktów na pokładzie. WireGuardnawet jeśli by chcieli.
Czy przetrwa? WireGuard mojego RoadWarriora z laptopa do centrum danych?
Nie. W tej chwili w WireGuard Brakuje wielu ważnych funkcji, aby to umożliwić. Na przykład, nie można używać dynamicznych adresów IP po stronie serwera tunelowego, co samo w sobie psuje cały sens tego produktu.
IPFire jest często używany do tanich łączy internetowych, takich jak DSL lub połączenia kablowe. Ma to sens w przypadku małych i średnich firm, które nie potrzebują szybkiego światłowodu. [Uwaga od tłumacza: nie zapominajmy, że pod względem komunikacji Rosja i niektóre kraje WNP znacznie wyprzedzają Europę i Stany Zjednoczone, ponieważ zaczęliśmy budować nasze sieci dużo później i wraz z pojawieniem się sieci Ethernet i światłowodowych jako standard, łatwiej było nam odbudować. W tych samych krajach UE czy USA szerokopasmowy dostęp xDSL o prędkości 3-5 Mb/s jest nadal powszechną normą, a połączenie światłowodowe kosztuje jakieś nierealne jak na nasze standardy pieniądze. Dlatego autor artykułu mówi o połączeniu DSL lub kablowym jako o normie, a nie o starożytności.] Jednak DSL, kabel, LTE (i inne metody dostępu bezprzewodowego) mają dynamiczne adresy IP. Oczywiście czasami nie zmieniają się one często, ale jednak się zmieniają.
Istnieje podprojekt o nazwie "wg-dynamic", który dodaje demona przestrzeni użytkownika w celu przezwyciężenia tego niedociągnięcia. Ogromnym problemem związanym z opisanym powyżej scenariuszem użytkownika jest pogorszenie dynamicznego adresowania IPv6.
Z punktu widzenia dystrybutora to wszystko też nie wygląda najlepiej. Jednym z celów projektowych było zachowanie prostoty i przejrzystości protokołu.
Niestety, to wszystko stało się w rzeczywistości zbyt proste i prymitywne, przez co musimy korzystać z dodatkowego oprogramowania, aby cały ten projekt nadawał się do rzeczywistego użytku.
WireGuard Czy jest to takie łatwe w użyciu?
Jeszcze nie. Nie mówię tego. WireGuard Nigdy nie będzie to dobra alternatywa dla tunelowania między dwoma punktami, ale na razie jest to tylko wersja alfa produktu, w który ma się przekształcić.
Ale co wtedy właściwie robi? Czy IPsec jest naprawdę dużo trudniejszy w utrzymaniu?
Oczywiście, że nie. Dostawca IPsec pomyślał o tym i dostarcza swój produkt wraz z interfejsem, takim jak IPFire.
Aby skonfigurować tunel VPN przez IPsec, będziesz potrzebować pięciu zestawów danych, które będziesz musiał wprowadzić do konfiguracji: własny publiczny adres IP, publiczny adres IP strony odbierającej, podsieci, które chcesz upublicznić za pośrednictwem to połączenie VPN i klucz wstępny. W ten sposób sieć VPN jest konfigurowana w ciągu kilku minut i jest kompatybilna z dowolnym dostawcą.
Niestety, w tej historii jest kilka wyjątków. Każdy, kto próbował tunelować przez IPsec do maszyny OpenBSD, wie o czym mówię. Istnieje kilka bardziej bolesnych przykładów, ale w rzeczywistości istnieje o wiele więcej dobrych praktyk dotyczących korzystania z protokołu IPsec.
O złożoności protokołu
Użytkownik końcowy nie musi martwić się o złożoność protokołu.
Gdybyśmy żyli w świecie, w którym użytkownik naprawdę by się tym przejmował, pozbylibyśmy się SIP, H.323, FTP i innych protokołów stworzonych ponad dziesięć lat temu, które nie działają dobrze z NAT.
Istnieją powody, dla których protokół IPsec jest bardziej złożony niż WireGuard:Oferuje o wiele więcej. Na przykład uwierzytelnia użytkowników za pomocą loginu i hasła lub karty SIM z protokołem EAP. Ma rozszerzoną możliwość dodawania nowych użytkowników. prymitywy kryptograficzne.
I o godz WireGuard to nie istnieje.
A to oznacza, że WireGuard W pewnym momencie nastąpi awaria, ponieważ jeden z prymitywów kryptograficznych zostanie osłabiony lub całkowicie skompromitowany. Autor dokumentacji technicznej ujmuje to w następujący sposób:
Należy zauważyć, że WireGuard Kryptograficznie zbyt pewny siebie. Celowo brakuje mu elastyczności w szyfrach i protokołach. Jeśli zostaną odkryte poważne luki w podstawowych elementach, wszystkie punkty końcowe będą wymagały aktualizacji. Jak pokazuje ciągły napływ luk w zabezpieczeniach SSL/TLS, elastyczność szyfrowania znacząco wzrosła.
Ostatnie zdanie jest jak najbardziej poprawne.
Osiągnięcie konsensusu co do tego, jakiego szyfrowania użyć, sprawia, że protokoły takie jak IKE i TLS więcej złożony. Zbyt skomplikowane? Tak, luki są dość powszechne w TLS/SSL i nie ma dla nich alternatywy.
O ignorowaniu prawdziwych problemów
Wyobraź sobie, że masz serwer VPN z 200 klientami produkcyjnymi na całym świecie. To dość standardowy przypadek użycia. Jeśli chcesz zmienić szyfrowanie, musisz przesłać aktualizację do wszystkich kopii. WireGuard na tych laptopach, smartfonach itp. Jednocześnie dostarczać. To dosłownie niemożliwe. Administratorzy próbujący to zrobić będą potrzebować miesięcy na wdrożenie wymaganych konfiguracji, a średniej wielkości firmie dosłownie lata na przeprowadzenie takiego zdarzenia.
IPsec i OpenVPN Zaoferuj funkcję negocjacji szyfrowania. Dzięki temu, przez krótki czas po włączeniu nowego szyfrowania, stare również będzie działać. Dzięki temu obecni klienci będą mogli zaktualizować system do nowej wersji. Po udostępnieniu aktualizacji wystarczy wyłączyć podatne na ataki szyfrowanie. I to wszystko! Gotowe! Jesteście niesamowici! A Wasi klienci nawet tego nie zauważą.
W rzeczywistości jest to bardzo powszechny przypadek w przypadku dużych wdrożeń, a nawet OpenVPN Napotyka to pewne trudności. Wsteczna kompatybilność jest ważna i nawet jeśli używasz słabszego szyfrowania, dla wielu nie jest to powód do zamykania działalności. Ponieważ sparaliżowałoby to setki klientów z powodu braku możliwości wykonywania ich obowiązków.
Zespół WireGuard Uprościł swój protokół, ale jest on całkowicie nieodpowiedni dla osób, które nie mają stałej kontroli nad oboma równorzędnymi elementami tunelu. Z mojego doświadczenia wynika, że jest to najczęstszy scenariusz.
Kryptografia!
Ale czym jest to nowe, ciekawe szyfrowanie, którego się używa? WireGuard?
WireGuard Wykorzystuje Curve25519 do wymiany kluczy, ChaCha20 do szyfrowania i Poly1305 do uwierzytelniania danych. Obsługuje również SipHash do haszowania kluczy i BLAKE2 do haszowania.
ChaCha20-Poly1305 jest standaryzowany dla IPsec i OpenVPN (za pośrednictwem TLS).
Oczywiste jest, że bardzo często wykorzystuje się rozwinięcie Daniela Bernsteina. BLAKE2 jest następcą BLAKE, finalisty SHA-3, który nie wygrał ze względu na podobieństwo do SHA-2. Gdyby SHA-2 miał zostać złamany, istniała duża szansa, że BLAKE również zostałby naruszony.
IPsec i OpenVPN SipHash nie jest wymagany ze względu na swoją konstrukcję. Dlatego jedyną rzeczą, której obecnie nie można z nimi używać, jest BLAKE2, i to tylko do czasu jego standaryzacji. Nie jest to poważna wada, ponieważ sieci VPN korzystają z HMAC do zapewnienia integralności, co jest uważane za solidne rozwiązanie nawet w połączeniu z MD5.
Doszedłem więc do wniosku, że wszystkie sieci VPN korzystają z niemal tego samego zestawu narzędzi kryptograficznych. Dlatego WireGuard nie jest ani bardziej, ani mniej bezpieczny niż jakikolwiek inny dostępny obecnie produkt pod względem szyfrowania i integralności przesyłanych danych.
Ale nawet to nie jest najważniejsze, na co według oficjalnej dokumentacji projektu warto zwrócić uwagę. W końcu najważniejsza jest szybkość.
WireGuard szybsze niż inne rozwiązania VPN?
Krótko mówiąc: nie, nie szybciej.
ChaCha20 to szyfr strumieniowy, który jest łatwiejszy do wdrożenia w oprogramowaniu. Szyfruje jeden bit na raz. Protokoły blokowe, takie jak AES, szyfrują blok 128 bitów na raz. Do implementacji wsparcia sprzętowego potrzeba znacznie więcej tranzystorów, więc większe procesory są dostarczane z AES-NI, rozszerzeniem zestawu instrukcji, które wykonuje niektóre zadania procesu szyfrowania, aby go przyspieszyć.
Spodziewano się, że AES-NI nigdy nie trafi do smartfonów [ale tak się stało — ok. za.]. W tym celu ChaCha20 został opracowany jako lekka, oszczędzająca baterię alternatywa. Dlatego może być dla ciebie nowością, że każdy smartfon, który możesz dziś kupić, ma jakąś akcelerację AES i działa szybciej i przy mniejszym zużyciu energii z tym szyfrowaniem niż z ChaCha20.
Oczywiście prawie każdy procesor do komputerów stacjonarnych/serwerów kupiony w ciągu ostatnich kilku lat ma AES-NI.
Dlatego spodziewam się, że AES przewyższy ChaCha20 w każdym scenariuszu. Oficjalna dokumentacja WireGuard Wspomniano, że dzięki AVX512, ChaCha20-Poly1305 będzie wydajniejszy niż AES-NI, jednak to rozszerzenie zestawu instrukcji będzie dostępne jedynie na większych procesorach, co z kolei nie pomoże w przypadku mniejszego i mobilnego sprzętu, który zawsze będzie szybszy dzięki AES-NI.
Nie jestem pewien, czy można było to przewidzieć w trakcie rozwoju. WireGuard, ale już dziś fakt, że jest on przywiązany do jednego szyfrowania jest wadą, która może nie mieć dobrego wpływu na jego działanie.
IPsec pozwala swobodnie wybrać, które szyfrowanie jest najlepsze w Twoim przypadku. I oczywiście jest to konieczne, jeśli na przykład chcesz przesłać 10 lub więcej gigabajtów danych przez połączenie VPN.
Problemy integracji w Linux
Chociaż WireGuard Wybrałem nowoczesny protokół szyfrowania, który już teraz stwarza wiele problemów. Zamiast korzystać z tego, co kernel obsługuje od razu, integracja WireGuard został odroczony na lata z powodu braku tych prymitywów w Linux.
Nie jestem do końca pewien, jak wygląda sytuacja w innych systemach operacyjnych, ale prawdopodobnie nie różni się ona zbytnio od Linux.
Jak wygląda rzeczywistość?
Niestety, za każdym razem, gdy klient prosi mnie o skonfigurowanie dla niego połączenia VPN, napotykam problem polegający na tym, że używają nieaktualnych danych uwierzytelniających i szyfrowania. 3DES w połączeniu z MD5 jest nadal powszechną praktyką, podobnie jak AES-256 i SHA1. I choć to drugie jest nieco lepsze, to nie jest to coś, z czego należy korzystać w 2020 roku.
Do wymiany kluczy zawsze Używane jest RSA - powolne, ale dość bezpieczne narzędzie.
Moi klienci są związani z organami celnymi oraz innymi organizacjami i instytucjami rządowymi, a także z dużymi korporacjami, których nazwy są znane na całym świecie. Wszyscy korzystają z formularza wniosku, który powstał kilkadziesiąt lat temu, a możliwość korzystania z SHA-512 po prostu nigdy nie została dodana. Nie mogę powiedzieć, że jakoś wyraźnie wpływa to na postęp technologiczny, ale oczywiście spowalnia proces korporacyjny.
Boli mnie to, ponieważ IPsec obsługuje krzywe eliptyczne od 2005 roku. Curve25519 jest również nowszy i dostępny do użytku. Istnieją również alternatywy dla AES, takie jak Camellia i ChaCha20, ale oczywiście nie wszystkie z nich są obsługiwane przez głównych dostawców, takich jak Cisco i inni.
I ludzie to wykorzystują. Istnieje wiele zestawów Cisco, istnieje wiele zestawów zaprojektowanych do pracy z Cisco. Są liderami rynku w tym segmencie i nie są zbytnio zainteresowani jakąkolwiek innowacją.
Tak, sytuacja [w segmencie korporacyjnym] jest fatalna, ale nie zobaczymy żadnych zmian z tego powodu WireGuardProducenci prawdopodobnie nigdy nie zauważą żadnych problemów z wydajnością narzędzi i szyfrowania, których już używają, ani nie zobaczą żadnych problemów z protokołem IKEv2 — dlatego też nie szukają alternatyw.
Ogólnie, czy kiedykolwiek myślałeś o porzuceniu Cisco?
Wzorce
Przejdźmy teraz do testów porównawczych z dokumentacji. WireGuardChociaż ta [dokumentacja] nie jest pracą naukową, spodziewałem się, że twórcy przyjmą bardziej naukowe podejście lub wykorzystają je jako punkt odniesienia. Punkty odniesienia są bezużyteczne, jeśli nie można ich odtworzyć, a tym bardziej bezużyteczne, gdy są uzyskiwane w warunkach laboratoryjnych.
W montażu WireGuard dla Linux Zyskuje przewagę dzięki wykorzystaniu technologii GSO (Generic Segmentation Offloading). Pozwala ona klientowi na utworzenie ogromnego pakietu o rozmiarze 64 kilobajtów i zaszyfrowanie/odszyfrowanie go w jednym przejściu. Zmniejsza to koszt wykonywania operacji kryptograficznych i połączeń. Jeśli chcesz zmaksymalizować przepustowość połączenia VPN, jest to dobry pomysł.
Jednak jak zwykle rzeczywistość nie jest taka prosta. Wysłanie tak dużego pakietu do karty sieciowej wymaga podzielenia go na wiele mniejszych pakietów. Normalny rozmiar wysyłania to 1500 bajtów. Oznacza to, że nasz gigant 64 kilobajtów zostanie podzielony na 45 pakietów (1240 bajtów informacji i 20 bajtów nagłówka IP). Wtedy na jakiś czas całkowicie zablokują pracę karty sieciowej, ponieważ muszą być wysłane razem i jednocześnie. W rezultacie doprowadzi to do przeskoku priorytetów, a pakiety, takie jak na przykład VoIP, zostaną umieszczone w kolejce.
Tak więc wysoka przepustowość, o której tak śmiało się mówi WireGuard, osiąga się poprzez spowolnienie wydajności sieci innych aplikacji. Zespół WireGuard już Potwierdzony to jest moja konkluzja.
Ale przejdźmy dalej.
Według benchmarków w dokumentacji technicznej łącze wykazuje przepustowość 1011 Mbps.
Imponujący.
Jest to szczególnie imponujące, ponieważ maksymalna teoretyczna przepustowość pojedynczego połączenia Gigabit Ethernet wynosi 966 Mb/s przy rozmiarze pakietu wynoszącym 1500 bajtów minus 20 bajtów na nagłówek IP, 8 bajtów na nagłówek UDP i 16 bajtów na sam nagłówek. WireGuardW zakapsułkowanym pakiecie znajduje się kolejny nagłówek IP i kolejny w protokole TCP, o długości 20 bajtów. Skąd więc bierze się ta dodatkowa przepustowość?
Przy ogromnych ramkach i zaletach GSO, o których mówiliśmy powyżej, teoretyczne maksimum dla rozmiaru ramki 9000 bajtów wynosiłoby 1014 Mb/s. Zwykle taka przepustowość jest w rzeczywistości nieosiągalna, ponieważ wiąże się z dużymi trudnościami. Mogę więc jedynie założyć, że test został przeprowadzony przy użyciu jeszcze grubszych, przewymiarowanych ramek o wielkości 64 kilobajtów z teoretycznym maksimum 1023 Mb/s, co jest obsługiwane tylko przez niektóre karty sieciowe. Ale jest to absolutnie nie do zastosowania w rzeczywistych warunkach lub może być używane tylko między dwiema bezpośrednio połączonymi stacjami, wyłącznie w obrębie stanowiska badawczego.
Ale ponieważ tunel VPN jest przekazywany między dwoma hostami za pomocą połączenia internetowego, które w ogóle nie obsługuje ramek jumbo, wyniku uzyskanego na stanowisku nie można traktować jako punktu odniesienia. Jest to po prostu nierealne osiągnięcie laboratoryjne, niemożliwe i nie do zastosowania w rzeczywistych warunkach bojowych.
Nawet siedząc w centrum danych nie mogłem przesyłać ramek większych niż 9000 bajtów.
Kryterium stosowalności w życiu jest bezwzględnie naruszone i jak sądzę autor przeprowadzonego „pomiaru” poważnie się zdyskredytował z oczywistych względów.
Ostatni promyk nadziei
Strona WireGuard Dużo się mówi o kontenerach i coraz bardziej oczywiste staje się, do czego właściwie służą.
Prosta i szybka sieć VPN, która nie wymaga konfiguracji i może być wdrożona i skonfigurowana za pomocą ogromnych narzędzi do orkiestracji, takich jak Amazon w swojej chmurze. W szczególności Amazon wykorzystuje najnowsze funkcje sprzętowe, o których wspomniałem wcześniej, takie jak AVX512. Odbywa się to w celu przyspieszenia pracy i braku powiązania z architekturą x86 lub inną.
Optymalizują przepustowość i rozmiary pakietów przekraczające 9000 bajtów – skutkuje to powstaniem ogromnych, hermetyzowanych ramek do komunikacji kontenerowej, tworzenia kopii zapasowych, tworzenia migawek czy wdrażania kontenerów. Nawet dynamiczne adresy IP nie wpływają na wydajność. WireGuard w przypadku scenariusza, który opisałem.
Dobrze rozegrane. Znakomita implementacja i bardzo cienki, niemal referencyjny protokół.
Ale po prostu nie nadaje się do świata poza centrum danych, nad którym masz pełną kontrolę. Jeśli podejmiesz ryzyko i zaczniesz używać WireGuard, będziesz musiał iść na ciągłe kompromisy podczas projektowania i wdrażania protokołu szyfrowania.
Wniosek
Nie jest mi trudno dojść do takiego wniosku WireGuard Jeszcze nie gotowy.
Miał on być lekkim i szybkim rozwiązaniem szeregu problemów występujących w istniejących rozwiązaniach. Niestety, aby osiągnąć te cele, poświęcono wiele funkcji, które byłyby istotne dla większości użytkowników. Dlatego nie może zastąpić IPsec ani… OpenVPN.
W celu WireGuard Aby stać się konkurencyjnym, musi przynajmniej dodać konfigurację adresów IP, routingu i DNS. Oczywiście, do tego potrzebne są szyfrowane kanały.
Bezpieczeństwo jest moim najwyższym priorytetem iw tej chwili nie mam powodu sądzić, że IKE lub TLS są w jakiś sposób zagrożone lub zepsute. Oba obsługują nowoczesne szyfrowanie, które zostało sprawdzone przez dziesięciolecia działania. To, że coś jest nowsze, nie oznacza, że jest lepsze.
Interoperacyjność jest kluczowa podczas komunikacji z podmiotami zewnętrznymi, których stacje nie podlegają Twojej kontroli. IPsec jest de facto standardem i jest obsługiwany niemal wszędzie. I działa. I jakkolwiek to wygląda w teorii, WireGuard w przyszłości może okazać się niekompatybilny nawet z różnymi wersjami samego siebie.
Każda ochrona kryptograficzna prędzej czy później zostanie zerwana i w związku z tym musi zostać wymieniona lub zaktualizowana.
Zaprzeczanie wszystkim tym faktom i ślepa chęć wykorzystania WireGuard aby połączyć swoje iPhone do domowego stanowiska pracy to mistrzowska lekcja chowania głowy w piasek.
Źródło: www.habr.com
