Co musi pozwolić VPS, zanim będzie mógł hostować Twój VPN

Instancja się uruchamia, instalacje pakietów kończą się sukcesem, a usługa zgłasza nawet stan działania, ale nic się nie łączy. Ten wzorzec jest częsty na wirtualnych serwerach prywatnych, ponieważ gość, który swobodnie dociera do internetu, wciąż może nie umieć utworzyć interfejsu wymaganego przez Twój protokół. Pięć kontroli oddziela hosta, który potrafi obsłużyć tunel, od takiego, który tylko wygląda na gotowy, a pierwsza nieudana kontrola zwykle wyjaśnia wszystko po niej. Każda jest tania w uruchomieniu i kończy się decyzją, a nie notatką.

Potwierdź interfejs wymagany przez protokół

OpenVPN przez TUN wymaga urządzenia znakowego i modułu jądra za nim; WireGuard wymaga własnego wsparcia jądra lub implementacji w przestrzeni użytkownika z odpowiednimi oczekiwaniami. Zarządzane kontenery mogą współdzielić jądro hosta, które nigdy nie udostępnia urządzenia, a niektóre platformy całkowicie zabraniają tworzenia interfejsów tunelu, niezależnie od tego, co jest zainstalowane.

Testuj możliwość zamiast czytać stronę wsparcia, bo etykiety marketingowe zmieniają się szybciej niż leżące u podstaw limity. Lista funkcji napisana dla jednego planu może nie opisywać jądra, na którym gość faktycznie działa. Dwie krótkie komendy odpowiadają na pytanie dla powszechnie używanych protokołów i obie sprzątają po sobie. Komendy poniżej nie tworzą nic trwałego i są natychmiast usuwane.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Odmowa przy pierwszej parze oznacza, że TUN jest niedostępny i domyślny tryb OpenVPN nie może wystartować; odmowa w ostatniej linii oznacza brak interfejsu jądra WireGuard. Dokumentacja jądra dotycząca TUN/TAP opisuje urządzenie, które sprawdza pierwsza kontrola. Żadnej z tych awarii nie naprawia ponowna instalacja pakietu VPN.

Pamiętaj, że ścieżka wejściowa ma dwóch właścicieli

Reguły sieciowe dostawcy i zapora gościa to odrębne systemy, a ruch musi przetrwać oba. Nasłuchujący związany na gościu nic nie znaczy, jeśli grupa zabezpieczeń dostawcy odrzuci port, a otwarta reguła dostawcy nic nie robi, jeśli gość odrzuci pakiet. Sprawdź nasłuchujący, potem reguły gościa, potem panel dostawcy, w tej kolejności, i potwierdź zarówno protokół, jak i numer portu. Przeskakiwanie od razu do panelu dostawcy to sposób, w jaki ludzie otwierają zakres, którego nie potrzebowali.

UDP jest zwykłą ofiarą: wiele platform domyślnie zezwala na TCP i traktuje reguły UDP jako osobny wpis. Jeśli instancja stoi za NAT dostawcy, a nie ma publicznego adresu, przekazywanie portów po stronie dostawcy staje się trzecią konfiguracją do uzgodnienia.

Zaplanuj drogę powrotną, nie tylko wyjście

Usługa pełnego tunelu wymaga włączonego przekazywania, schematu tłumaczenia lub routingu ruchu klientów oraz drogi powrotnej docierającej do puli klientów. Otwarcie nasłuchującego nie daje niczego z tego. Tunel, który się zestawia, ale nie niesie użytecznego ruchu, zwykle zawodzi tutaj, a nie na uwierzytelnianiu. Traktuj udane uzgodnienie jako początek diagnozy, a nie jej koniec.

Zapisz plan jako trzy konkretne decyzje: jaki zakres źródłowy otrzymują klienci, jak ich ruch wychodzi do internetu i jak odpowiedzi znajdują drogę powrotną. Następnie potwierdź, że jądro zgadza się z planem, zanim przetestujesz klienta, aby cicha niezgodność nie została wzięta za usterkę po stronie klienta.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Rozstrzygnij kwestię IPv6 jednoznacznie

IPv6 przychodzi kilkoma mechanizmami, które zachowują się różnie dla bramy: adres na instancji, trasowany prefiks albo nic. Tylko trasowany prefiks pozwala serwerowi nadawać adresy klientom w zwykły sposób. Założenie, że działający adres IPv6 na hoście oznacza użyteczny prefiks klienta, jest błędem, który ujawnia się później jako na wpół zepsuta łączność. To rodzaj usterki, która przetrwa każdy test wykonany tylko z IPv4.

Jeśli dostawca nie trasuje żadnego prefiksu, zdecyduj, czy tunel jest tylko IPv4 i czy klienci powinni o tym wiedzieć. Udokumentowany brak jest bezpieczniejszy niż częściowa konfiguracja, która po cichu wysyła cele IPv6 w czarną dziurę dla podłączonych użytkowników.

Udowodnij to z zewnętrznego klienta

Lokalny stan usługi opisuje jeden proces na jednym hoście. Użyteczny test to autoryzowany klient w innej sieci, który łączy się z profilem, który zamierzasz rozdawać, następnie dociera do aplikacji i rozwiązuje nazwę. Połącz się jeszcze raz, ponieważ tunel działający tylko za pierwszym razem nie spełnia wymagania, które w praktyce liczy się najbardziej.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Trzymaj podstawy operacyjne obok testu: miejsce na aktualizacje, ograniczone logi, dostęp administracyjny niezależny od tunelu, konsolę odzyskiwania i notatkę o tym, co dzieje się z profilami klientów, gdy instancja jest odtwarzana, a jej publiczny adres się zmienia. Jeśli wymagany interfejs lub model przekazywania po prostu nie jest dostępny, żadna zmiana po stronie klienta tego nie zapewni, a uczciwym następnym krokiem jest inny typ instancji, a nie więcej konfiguracji.