W dzisiejszym materiale opowiem o Overlay VPN. Przykłady takich sieci to NetBeard, ZeroTier oraz coraz bardziej popularny TailScale, którym posłużymy się jako przykładem. Nie twierdzę, że jest on najlepszy, ale używamy go najwięcej.
Porozmawiamy o tym, czym się różnią Overlay VPN od klasycznych VPN, np. WireGuard, IPSec, OpenVPN. Spróbujemy także odpowiedzieć na pytanie, który rodzaj VPN dla Ciebie będzie lepszy i kiedy?
Przykład standardowej infrastruktury możemy zobaczyć na rysunku. Cechą charakterystyczną jest jeden centralny punkt, którym jest serwer VPN. W rzeczywistych rozwiązaniach często mogą być to elementy powielone ze względów redundancyjnych lub nawet zwielokrotnione ze względów wydajnościowych.
Niezależnie od tego, będzie je cechował jeden wspólny element w postaci centralnego punktu, z którym będą rozmawiały wszystkie elementy systemu. Przykładami otwartych rozwiązań są WireGuard, IPSeek czy OpenVPN. Niewątpliwą zaletą takiego rozwiązania jest prostota. Mamy firewall z VPNem, konfigurujemy, wystawiamy do Internetu cały firewall lub tylko jeden jego port i działa.
Rozwiązań dobrze znanych i opracowanych jest wiele. Niestety, te rozwiązania mają kilka wad. Ważnym minusem standardowych serwerów VPN takich jak OpenVPN jest fakt, że musi on mieć publiczny adres IP, najlepiej niezmienny. Nie jest to duży problem czy przeszkoda do rozwiązania, ale czasem np. dostawcy Internetu żądają dodatkowych opłat.
Kolejną wadą jest fakt, że każdy ruch transmitowany przez którykolwiek z elementów sieci będzie musiał przechodzić przez węzeł centralny. Jeśli użytkowników nie jest wielu, a ilość transmitowanego ruchu jest niewielka, nie ma problemu. Niech jednak jeden z użytkowników, jak na rysunku, zacznie ściągać jakieś duże pliki z jednego z biur. W takim wypadku wszystkie dane będą przechodziły przez serwer VPN bezlitośnie, dwukrotnie konsumując zasoby FireWalla. Innym przykładem będzie potrzeba regularnych synchronizacji większych ilości danych między biurami, np. materiały wideo lub nagrania monitoringu. Rozumiecie do czego zmierzam? Dosyć łatwo dochodzimy do sytuacji, gdzie zaczyna się wyczerpywać moc firewalla z VPN, albo pasmo internetowe w centrali. Wysycenie mocy firewall przez jeden lub kilka dużych strumieni może wpłynąć negatywnie na stabilność całej sieci VPN.
Nieuchronnym skutkiem takiej topologii będzie wydłużenie czasu transmisji pakietów. Będzie się sumował czas od klienta do serwera VPN oraz od serwera VPN do drugiego klienta. W większości wypadków przy współczesnych szerokopasmowych sieciach nie powinno to stanowić problemu, ale niektóre aplikacje są wrażliwe na wydłużanie się czasu odpowiedzi. Sieci oparte o Overlay VPN mają trochę inną infrastrukturę logiczną porównując ją do standardowych VPNów.
Przykładem takich rozwiązań są ZeroTier, Nebula czy Tailscale. Zacznijmy od podstawowej różnicy, która zawsze pierwsza rzuci się nam w oczy, czyli dodatkowy element w postaci Coordination Managera. To taki nasz logiczny punkt centralny, tylko, że nie transmituje on żadnych danych. Jego podstawowym zadaniem jest koordynacja transmitowanych danych. Dodatkowo zarządza on uprawnieniami.
Kto może podłączyć się do danej sieci a kto nie? Coordination Manager potrafi zarządzać filtrowaniem ruchu. Kto może otworzyć komunikację do kogo i na jakim porcie? Działa to w ten sposób, że każdy klient dołączający do sieci łączy się do naszego Coordination Managera gdzieś tam w sieci. Po właściwym uwierzytelnieniu dostaje informacje o wszystkich urządzeniach dostępnych w jego sieci, do których może się dostać. W Overlay VPN, jak Tailscale, tworzy się dodatkowy wirtualny interfejs i w systemie widoczny jest on jako nowa dodatkowa karta sieciowa. Od tego momentu komputer może się komunikować bezpośrednio z urządzeniami w sieci VPN przez nowy interfejs, jakby były one w sieci lokalnej.
Aby rozpocząć transmisję danych między komputerami w sieci trzeba ją najpierw ze sobą połączyć. I tu zaczyna się dziać magia overlay VPN-a. Każdy komputer jest połączony z Coordination Managerem. Przy jego pomocy i bardzo wyszukanej manipulacji pakietami sieciowymi, każdy komputer tworzy bezpośredni szyfrowany tunel z każdym innym komputerem w swojej sieci VPN, z którym będzie chciał wymieniać dane.
Niezależnie od tego za iloma i za jakimi natami są pochowane komputery, protokół znajdzie najkrótszą i najprawdopodobniej najbardziej optymalną drogę między dwoma konkretnymi komputerami i zestawi zaszyfrowany tunel punkt-punkt. W efekcie tworzy się zestaw wielu tuneli punkt-punkt, który tworzy sieć każdy do każdego, tzw. full mesh. Na tej fizycznej infrastrukturze wielu tuneli tworzy się logiczna sieć komputerów widzących się w jednej wirtualnej sieci. Niewątpliwą zaletą Overlay VPN, np. Tailscale czy NetBeard, jest nawiązywanie bezpośredniego połączenia między komputerami wymieniającymi ze sobą ruch, sprawiając, że ruch jest transmitowany najkrótszą trasą, a transmisja jest najszybszą z możliwych przez pominięcie dodatkowych punktów pośrednich.
Następną zaletą jest eliminacja wąskiego gardła jaką jest centralny serwer VPN. Nie transmitujemy przez niego ruchu, nie obciążamy procesorów, nie dociążamy pasma internetowego. Nasz punkt centralny, czyli Coordination Manager, jako że nie transmituje żadnego ruchu, ma znacznie mniejsze wymagania sprzętowe niż w wypadku centralnego serwera VPN. Nadal musi być on wystawiony do Internetu, ale nie musi być w żadnej z naszych lokalizacji. Konfiguracja klientów wszystkich Overlay VPN jest zupełnie przezroczysta z perspektywy miejsca, z którego się łączą. Nie ma potrzeby publicznego IP, nie trzeba żadnych regułek na firewallu, żadnego przekierowania portów. Nic, po prostu działa.
Ciekawą opcją w tej Scale jest opcja exit node. Dosłownie zaznaczając jedną kratkę pozwalamy innym członkom sieci na korzystanie z naszego komputera lub z naszego firewalla jako punktu wyjścia na świat. Bardzo wygodnie i prosto.
Zaletą i jednocześnie wadą Overlay VPN znowu jest Coordination Manager. Mamy opcję skorzystania z usług dostawców, albo skorzystania z wersji self-hosted. W wypadku NetBeard i ZeroTier można to zrobić, ale w TateScale nie ma udostępnionej wersji self-hosted, choć można użyć odpowiednika headscale, który jest i działa całkiem poprawnie. Dlaczego o tym wspominam? Ponieważ, jeśli będziemy hostować serwer koordynacyjny samemu, to w zasadzie wszystko jest ok, jak do tej pory wszystko trzymamy w swoich rękach.
Jednak przyznam, że korzystanie z usług dostawców, jest tutaj bardzo kuszącą opcją. Zwłaszcza że wszystkie omawiane rozwiązania oferują darmowe plany swoich rozwiązań. W NetBeard i TailScale nawet do 100 urządzeń. Dobrze, ale dlaczego mówię o tym przy okazji wad? Zakładamy, że ktoś przejmie kontrolę nad dostawcą naszego overlay VPN. Naprawdę nie traktowałbym tego jako science fiction. Mamy liczne przykłady przejęć kontroli nad serwerami dostawców usług bezpieczeństwa, a w efekcie przejęcia kontroli nad urządzeniami klientów. W praktyce, w tym momencie zarządzający dostawca, a właściwie ten, kto przejął nad nim kontrolę, kontroluje jaki komputer pojawi się u nas w sieci i domyślnie traktowany będzie jako sieć zaufana i bezpieczna. Kontroluje on również możliwe ustawienia reguł Firewalla w tej sieci. Zgodnie z maksymą, że kontrola jest wyższą formą zaufania, powinno nas to prowadzić do jedynego słusznego wniosku, że w praktyce powinniśmy takie sieci traktować w najlepszym wypadku jako DMZ, ale absolutnie nie jako strefę bezpieczną.
W mocy pozostaje obowiązek szyfrowania i filtrowania całego ruchu. Obowiązuje zasada ograniczonego zaufania. Na chwilę obecną, czyli wrzesień 2024, niewiele urządzeń czy systemów swobodnie obsługuje overlay VPN. Są dostępne wersje klientów na Windowsa MacOSa czy Linuxa. Można również spotkać wbudowaną obsługę OpenVPNa w najprostszych urządzeniach sieciowych, routerach, dyskach sieciowych, takich jak TrueNAS Synology lub najmniejszych urządzeniach IoT. Często da się je skonfigurować i działa. Inaczej sprawa wygląda w wypadku klientów overlay VPN. Trzeba się tutaj posiłkować routerami wspierającymi Overlay VPN, z wszystkimi tego wadami i zaletami, np. pfsense wspiera tailscale, albo tworzyć dodatkowe instancje np. kontenery będące pośrednikami ruchu.
Ciekawym rozwiązaniem jest dodatek Tailscale do PFSense. Bardzo prosty, intuicyjny, a konfiguracja ogranicza się do zainstalowania i wpisania klucza. To wszystko. Ale uwaga, będzie o wadach. Jeżeli otarłeś się o zarządzanie sieciami, to ten kawałek będzie mocno nieintuicyjny. Jeśli stworzycie za pomocą TailScale ipf sence tunel side to side to okaże się, że ruch w innej lokalizacji natowany jest przez nasz firewall. Wynikiem czego, w innej lokalizacji, wygląda to tak, jakby ruch pochodził z naszego firewalla. To w praktyce duży problem, jeśli chcecie się trzymać dobrych praktyk i filtrować ruch, a nie wiecie, czy pochodzi on z waszego firewalla, czy z telefonu kogoś w jednym z biur.
Pamiętacie opcję exit node, o której wspominałem? No właśnie, tutaj też trzeba o tym pamiętać. Jeśli umożliwimy korzystanie z naszego firewalla jako exit node’a, to bez specjalnej kontroli pozwalamy innym wychodzić na świat jako nasz firewall. To nie zawsze dobrze.