VPN między lokalizacjami a dostęp zdalny: co łączy każde z nich
Jedno łączy bramy, drugie łączy urządzenia. Porównaj selektory ruchu z trasami, zaplanuj adresację, a następnie przetestuj przekazywanie i politykę z rzeczywistego hosta.
Oba rozwiązania nazywa się VPN i rozwiązują różne problemy. Tunel między lokalizacjami łączy dwie bramy, więc każdy host za nimi może dotrzeć do dozwolonych adresów po drugiej stronie bez instalowania czegokolwiek. Tunel dostępu zdalnego łączy pojedyncze urządzenia z siecią, po jednym kliencie naraz. Porównanie jest ważne, bo większość błędów wdrożeniowych bierze się z konfigurowania jednego rozwiązania przy oczekiwaniu zachowania drugiego, a objawem jest zwykle przekroczenie limitu czasu w usłudze, do której tunel rzeczywiście dotarł.
Dwa rozwiązania, dwie granice
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Żadne z rozwiązań nie rozszerza domeny rozgłaszania LAN. Urządzenia po drugiej stronie nie pojawiają się na lokalnej liście wykrywania, a oczekiwanie tego jest pierwszym założeniem, z którego trzeba zrezygnować. Prywatne nazwy DNS, które świadomie publikujesz, są bardziej przewidywalne niż jakikolwiek protokół wykrywania i przetrwają zmianę dostawcy.
Weź 10.10.0.0/24 w jednej lokalizacji i 10.20.0.0/24 w drugiej. Brama A potrzebuje trasy lub selektora ruchu, który wysyła prefiks 10.20.0.0/24 do tunelu, a brama B potrzebuje jego lustrzanego odbicia. Hosty po obu stronach używają wtedy zwykłej łączności IP i nigdy nie dowiadują się, że tunel istnieje. Ta niewidzialność jest cechą, i dlatego awarie wyglądają jak zwykłe błędy sieci, a nie błędy tunelu.
Oparte na polityce i oparte na trasie to nie ten sam tunel
We wdrożeniu IPsec opartym na polityce wynegocjowane selektory ruchu dokładnie określają, które pary źródła i celu są chronione. Jeśli za jedną bramą pojawi się nowa podsieć i żaden selektor jej nie obejmie, tunel pozostanie aktywny, a nowa podsieć po prostu nie będzie przenoszona. W rozwiązaniu opartym na trasie interfejs odbiera ruch, a decyduje tabela routingu, co sprawia, że dodanie prefiksu jest zmianą trasy, a nie ponownymi negocjacjami tunelu.
StrongSwan pokazuje oba widoki bezpośrednio, a czytanie ich razem to sposób, aby ustalić, który model naprawdę wdrożyłeś.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'Lista selektorów, w której brakuje potrzebnego prefiksu, wyjaśnia awarię bez żadnego przechwytywania pakietów, a trasa wskazująca niewłaściwy interfejs wyjaśnia lustrzaną awarię w drodze powrotnej. Przeczytaj oba, zanim cokolwiek ponownie wynegocjujesz, bo odnowienie klucza nie doda selektora, którego nigdy nie skonfigurowałeś.
Zaplanuj adresację przed tunelem
Nakładające się zakresy to błąd projektowy, którego nie da się naprawić konfiguracją. Jeśli obie lokalizacje używają 192.168.1.0/24, host potrzebujący 192.168.1.50 ma dwóch kandydatów i żadnego sposobu wyboru. Tunel się uwierzytelni, asocjacje bezpieczeństwa zostaną ustanowione, a decyzja routingu i tak będzie błędna lub niejednoznaczna.
Wybierz jedną z trzech uczciwych opcji: przenumeruj jedną lokalizację, przetłumacz nakładający się zakres na bramie, aby każda strona widziała odrębny prefiks, albo zrezygnuj z bezpośredniego routingu dla tych hostów i opublikuj usługę w inny sposób. Każda ma koszt, a pierwsza jest zwykle najtańsza w perspektywie dwóch lat. Zdecyduj, zanim tunel powstanie, bo później zmiana dotknie każde urządzenie ze starym adresem.
Rozwiąż też kwestię MTU wcześnie. Tunel zmniejsza użyteczny ładunek, a rozwiązanie opierające się na fragmentacji zachowuje się inaczej niż takie, które ustala MSS na bramach.
Przekazywanie i polityka znajdują się poza tunelem
Brama musi być gotowa przekazywać pakiety między interfejsem tunelu a interfejsem LAN, a oba kierunki potrzebują polityki, która zezwala na usługę. W Linuksie to dwa osobne ustawienia, plus reguły firewalla, które decydują, czy przekazywany strumień jest w ogóle dozwolony.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTHost odbierający dodaje trzecią warstwę: jego własny firewall nadal musi zaakceptować klienta ze zdalnej podsieci. Serwer plików, który zezwala tylko na swoje lokalne /24, odrzuci przekazywany ruch z 10.20.0.7, niezależnie od tego, jak zdrowy wygląda tunel, a to odrzucenie łatwo odczytać jako awarię routingu.
Testuj z hosta, nie z bramy
Ping wysłany przez samą bramę może używać innego adresu źródłowego i innej polityki niż przekazywany ruch użytkownika. To czyni go słabym testem, a czasami mylącym: udaje się, gdy aplikacja zawodzi, albo zawodzi, gdy aplikacja działa.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullUżyj rzeczywistego hosta, rzeczywistego adresu źródłowego i rzeczywistego protokołu, którego używa aplikacja. Potem odczytaj osobno drogę powrotną, bo działający kierunek do przodu bez trasy powrotnej daje przekroczenie limitu czasu, które wygląda identycznie jak zablokowana usługa.
Wybierz rozwiązanie według pytania, na które odpowiadasz: łączysz sieci czy przyjmujesz urządzenia? Wszystko inne, w tym to, którego dostawcę konfigurujesz, wynika z tej odpowiedzi.