Jak zaplanować pulę adresów klientów VPN, która pasuje

Zacznij od pola puli na serwerze VPN, a nie w arkuszu kalkulacyjnym. To, co tam wpiszesz, staje się wewnętrzną przestrzenią adresową każdego klienta, który połączy się później, i musi współistnieć z siecią LAN, do której docierają ci klienci, z trasowanymi witrynami za nią oraz z każdym adresem, który klient ma już w domu. Podłącz jednego klienta zaraz po zapisaniu puli, bo to pierwsze połączenie mówi, czy wartość działa w praktyce. Stamtąd przewodnik wychodzi na zewnątrz: adres, który klient otrzymał, droga, którą podąża odpowiedź, i notatka, którą zostawiasz.

Zacznij od pola puli, zanim połączy się jakikolwiek klient

Każdy produkt pokazuje to inaczej, więc znajdź obiekt, który naprawdę przydziela adresy. OpenVPN ma dyrektywę puli po stronie serwera, która wydaje następny wolny adres, brama IKEv2 ma sekcję puli powiązaną z konfiguracją peera, a WireGuard nie ma żadnej, bo każdy peer niesie własny adres w swoim pliku konfiguracyjnym. Dyrektywa puli i adres per peer nie są wymienne, a edycja niewłaściwej marnuje resztę przewodnika.

Gdy masz pole, wypisz zakresy, które już istnieją: sieć LAN biura, każdą trasowaną witrynę, VPC w chmurze i każdą inną pulę wciąż w użyciu. Nakładanie rozstrzyga arytmetyka prefiksu, a nie to, czy numery hostów wyglądają znajomo, więc porównaj agregat z każdym z tych zakresów. Dwa zakresy, które oba wyglądają jak 10.x, są nieszkodliwe, gdy ich agregaty się nie przecinają, i incydentem wsparcia, gdy się przecinają.

Potem zdecyduj, czy adres jest funkcją tego, kto się łączy, czy tego, kiedy się łączą. Przydział dynamiczny wydaje to, co wolne, a przydział według tożsamości wiąże stały adres z poświadczeniem. Zapisz wybór, bo zmienia on, jak później powinno wyglądać ponowne połączenie.

Odczytaj adres, który klient faktycznie otrzymał

Podłącz jednego klienta i czytaj, co raportuje tunel, a nie co obiecała pula. Klient pokazuje swój adres wewnętrzny w stanie połączenia, a w systemie Linux interfejs nosi go bezpośrednio.

Porównaj ten adres z zakresem, który zapisałeś. Jeśli leży poza zakresem, widzisz inną ścieżkę przydziału niż ta, którą edytowałeś. Sprawdź też długość prefiksu, bo klient z /32 nie ma peera na łączu i wysyła każdy cel przez swoją trasę domyślną.

ip -4 addr show tun0
ip route get 192.168.50.20

Klient, który łączy się z domowego routera używającego tego samego zakresu, połączy się, a potem nie dotrze prawie nigdzie. Klient zachowuje swoją trasę lokalną dla tego prefiksu, więc adres tunelu koliduje z siecią za nim, a ruch wychodzi przez niewłaściwy interfejs. Tego przypadku nie da się naprawić na serwerze; udokumentowanym środkiem jest przenumerowanie sieci domowej albo wybór zakresu puli wystarczająco odległego, by kolizje pozostawały rzadkie. Zapisz zarówno awarię, jak i środek, bo pomoc techniczna spotka go ponownie.

Podłącz tego samego klienta ponownie i obserwuj adres. Pula dynamiczna może zwrócić tę samą lub inną wartość i obie są poprawne, natomiast pula według tożsamości, która zmienia adres, nie respektuje wiązania. To sprawdzenie trwa sekundy i rozstrzyga, czy tryb zapisany w pierwszej części jest trybem obowiązującym.

Prześledź odpowiedź z powrotem od usługi

Pula działa tylko wtedy, gdy odpowiedzi mogą wracać do niej. Usługa w sieci LAN odpowiada na adres wewnętrzny, więc jej brama potrzebuje trasy dla puli albo translacji przed usługą. Gdy żądanie przychodzi przez tunel, a odpowiedź wychodzi inną drogą, zapora stanowa lub kontrola trasy odwrotnej ją odrzuca, a klient widzi usługę, która się łączy, a potem zawiesza. Umieść pulę w projekcie routingu jako jeden blok do agregacji, zamiast dodawać trasy dla każdego hosta.

Translacja zmienia to, co widzi reszta systemu. Gdy źródło jest przepisywane, adres w zaporze hosta i w dzienniku aplikacji jest przetłumaczony, więc reguła napisana wobec adresu puli nie pasuje do niczego, a wiersza dziennika nie da się prześledzić do klienta. Dokumentacja strongSwan dotycząca przekazywania obejmuje serwerową połowę tej drogi dla bramy IKEv2. DNS niesie to samo ograniczenie, bo nazwa, która rozwiązuje się na adres nieosiągalny dla klienta, zawodzi później i gdzie indziej.

Dwóch klientów, potem jedno unieważnienie

Podłącz dwóch klientów jednocześnie i odczytaj oba adresy. Muszą być różne, użyteczne i wewnątrz puli, a każdy musi docierać do usługi, dla której jest przeznaczony. Pula, która wydaje zduplikowane adresy, zwykle ujawnia się tutaj, a nie w pierwszym teście z jednym klientem.

Unieważnij jedno poświadczenie, gdy drugi klient pozostaje połączony, a następnie wypróbuj usługę z ocalałego klienta. Unieważnienie, które zakłóca drugą sesję, wskazuje na stan współdzielony, najczęściej jedno poświadczenie albo jeden adres używany ponownie między urządzeniami. Podłącz unieważnionego klienta ponownie i potwierdź, że spotyka go odmowa, a nie wydanie zwolnionego adresu.

Zakończ celem, który powinien zostać odrzucony. Klient, który dociera wszędzie, został podłączony, a nie przetestowany.

Zapisz te cztery wartości tam, gdzie znajdzie je następna zmiana

Notatka jest krótka: zakres i prefiks puli, tryb przydziału, droga powrotna lub używana translacja oraz zasięg DNS, który odpowiada za te cele. Połóż ją obok konfiguracji serwera, a nie w zgłoszeniu, i opatrz datą. Kto później zmieni jedną z czterech, potrzebuje pozostałych trzech przed sobą, bo zmiana rozmiaru puli psuje trasę, a zmiana trasy psuje odpowiedź DNS.

Trzymaj przy niej notatkę o własności: zakres tunelu należy do serwera VPN, a rezerwacja zrobiona w zakresie DHCP sieci LAN niczego nie rezerwuje dla klienta wewnątrz tunelu. Ta jedna linia zapobiega najczęstszej przeróbce, w której ktoś dodaje rezerwację i oczekuje, że adres tunelu pójdzie za nią.