Publiczny prefiks dla klientów VPN: co naprawdę psuje

Pula klientów wybrana dlatego, że liczby wyglądają schludnie, jest trasą czekającą na instalację. Prefiks nie musi być prywatny, aby VPN działał, a użycie bloku należącego do kogoś innego też nie wystawia użytkowników automatycznie na internet. To, co robi, sprawia, że te adresy znaczą coś innego, dopóki tunel jest podniesiony, a potem znowu coś innego, gdy pada. Przejdź przez pięć kontroli poniżej po kolei i zatrzymaj się tam, gdzie odpowiedź brzmi „przydzielono gdzie indziej”.

Przydział nie jest ogłoszeniem

Umieszczenie adresu na interfejsie tunelu nie ogłasza go internetowi. Publiczna osiągalność wymaga trasy, autoryzowanej ścieżki i dostawcy gotowego ją nieść, a nic z tego nie pojawia się dlatego, że klient dostał adres z puli. Polityka zapory i autoryzacja hosta to znów osobne decyzje.

Dlatego ryzyko nie jest tym, co zakłada większość. Pożyczony prefiks nie czyni twoich klientów osiągalnymi; czyni cele kogoś innego nieosiągalnymi z twoich klientów, co jest inną awarią z innym właścicielem. Nikt nie jest atakowany i żadne ogłoszenie nie wycieka. Użytkownik po prostu nie może otworzyć strony, która działała wczoraj, a helpdesk nie ma powodu podejrzewać puli VPN.

Różnica ma znaczenie przy wyborze puli. Gdyby jedynym zmartwieniem było wystawienie na internet, publiczny blok wyglądałby bezpiecznie, bo nic go nie ogłasza. Zmartwieniem jest lokalna trasa, którą klient instaluje dla tego prefiksu, i ta trasa jest instalowana niezależnie od tego, czy ktoś inny ją widzi.

Co właściwie przechwytuje trasa klienta

Gdy tunel się podnosi, klient otrzymuje trasę dla prefiksu puli, a ta trasa wygrywa z trasą domyślną dla każdego celu w jej obrębie. Żądanie do legalnego hosta w tym bloku trafia teraz do VPN zamiast do internetu. Czy zawiedzie, zawiesi się czy dotrze do złego serwera, zależy od tego, co robi z nim twoja strona.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Uruchom wyszukiwanie z tunelem podniesionym i ponownie ze spuszczonym. Adres znaczy jedno w pierwszym przypadku i coś zupełnie innego w drugim, a każda aplikacja, która zbuforowała połączenie lub rozwiązywanie nazwy przez to przejście, będzie zachowywać się niespójnie. Ta niespójność jest trudniejsza do wsparcia niż czysta awaria, bo zależy od czasu. Użytkownik, który połączy się ponownie w złym momencie, ma inne doświadczenie niż ten, który tego nie robi.

Dlatego też znany adres IP nie jest dowodem tożsamości. Zachowaj walidację certyfikatu i nazwy serwera dla prawdziwego celu, bo adres numeryczny, do którego dotarłeś pięć minut temu, może teraz należeć do innej rozmowy.

Porównaj pulę z każdą siecią, którą znasz

RFC 1918 rezerwuje trzy bloki do użytku prywatnego: 192.168.0.0/16, 172.16.0.0/12 i 10.0.0.0/8. Miliony oddzielnych organizacji używa ich ponownie, więc prywatny to stwierdzenie o przydziale i nigdy obietnica, że nikt inny nie wybrał tych samych numerów.

Porównaj pulę kandydacką z sieciami LAN w biurach, chmurowymi VPC, innymi pulami VPN, łączami partnerskimi i zakresami, które pracownicy zdalni prawdopodobnie mają w domu. Przypadek domowy nie jest powodem do wymyślania dziwnego prefiksu; to powód, by trzymać pulę małą i udokumentowaną.

Skoordynuj przydział z tym, kto posiada routing, i zapisz trasę powrotną w tym samym miejscu. Pula, do której nikt nie może routować z powrotem, to pula, która zostanie odkryta ponownie podczas awarii. Umieść pulę w tym samym dokumencie co zakresy lokalizacji, a nie w konfiguracji klienta, którą edytowała tylko jedna osoba. Dokument jest tym, co czyni następną kolizję możliwą do uniknięcia.

Kiedy adresacja publiczna jest właściwą odpowiedzią

Organizacje z prawidłowo przydzieloną przestrzenią globalną mogą z powodzeniem zbudować pulę VPN z publicznymi adresami, a niektóre robią to celowo, aby uniknąć translacji. Ten projekt nadal wymaga routingu, walidacji źródła, reguł dostępu i uwierzytelniania klientów; przydział nie daje żadnego z nich.

To, co daje, to unikalność, cecha, której pożyczonemu prefiksowi brakuje. Jeśli posiadasz blok, trasa instalowana przez klienta wskazuje adresy, które naprawdę są twoje, a znaczenie nie zmienia się, gdy tunel pada.

Nie dodawaj NAT automatycznie, aby zrekompensować wybór puli. Routowany projekt prywatny z jawnymi trasami powrotnymi jest czystszy niż translacja stosowana dlatego, że adresacja nigdy nie była zaplanowana, a IPv6 potrzebuje własnego świadomego planu, a nie kopii założeń IPv4.

Wycofaj złą pulę bez utraty dostępu

Jeśli pula jest już wdrożona, zrób inwentaryzację, zanim ją zmienisz: rezerwacje adresów, zainstalowane trasy, rekordy DNS rozwiązujące się w blok, zakresy zapory i aplikacje, które od nich zależą. Następnie zaplanuj zmianę z taką samą starannością jak każde inne przejście routingu. Ogłoś ją ludziom, którzy to zauważą, bo ich sesje padną, gdy pula się przesunie. Cicha zmiana adresacji klientów generuje zgłoszenia do pomocy technicznej, które wyglądają na niezwiązane z pracą.

Zachowaj ścieżkę odzyskiwania, która nie zależy od puli, którą usuwasz, bo moment jej wycofania to moment, w którym twój dostęp zdalny może zniknąć razem z nią. Potem zweryfikuj oba kierunki: zamierzone cele prywatne nadal działają, a cele internetowe, które wcześniej były przechwytywane, teraz rozwiązują się do swoich prawdziwych właścicieli.

Chcesz puli, którą zespół sieciowy może przydzielić, routować i wycofać jako jedną spójną rzecz. Format adresu sam w sobie nie zapewnia ani bezpieczeństwa, ani łączności.