Domowy serwer VPN a serwer w chmurze: który dotrze do twojego NAS?

Tunel wstaje, klient pokazuje zieloną kropkę, a ssh 192.168.1.20 nadal wisi, aż upłynie limit czasu. Dokładnie to spotkało mnie po wynajęciu małej instancji w chmurze i postawieniu na niej WireGuard: uzgadnianie w porządku, DNS w porządku, a NAS na moim biurku tak nieosiągalny, jakby był na Księżycu. Z tunelem nie było nic nie tak. Endpoint stał w sieci bez trasy do mojego domu. Lokalizacja endpointu decyduje, które sieci są sąsiednie, więc wybierz ją według zasobu, do którego musisz dotrzeć najpierw, a hosting porównuj dopiero potem.

Tunel dociera tylko do sieci, które endpoint potrafi trasować

VPN daje klientowi adres w obrębie własnej domeny routingu endpointu. Gdy klient wysyła pakiet do 192.168.1.20, endpoint musi wiedzieć, dokąd on idzie. Tablica maszyny w chmurze zna podsieci VPC dostawcy; o twoim LAN nie słyszała nigdy. Połączony i osiągalny to dwie różne fakty, a większość zamieszania między domem a chmurą bierze się z brania pierwszego za dowód drugiego.

Jedno polecenie rozstrzyga. Na endpoincie ip route get 192.168.1.20 albo nazywa interfejs LAN, albo wskazuje trasę domyślną. Na maszynie domowej odpowiedzią jest strona LAN. Na instancji w chmurze pakiet wychodzi ku internetowi i ginie. Włączenie net.ipv4.ip_forward=1 i dodanie reguły MASQUERADE niczego nie zmienia, bo nie ma czego przekazywać, dopóki coś po stronie domu nie zakończy łącza do chmury.

Przypadek domowy ma drugą połowę: drogę powrotną. Pakiety opuszczające LAN przez skrzynkę tunelu są NATowane, albo LAN potrzebuje trasy statycznej z powrotem do podsieci tunelu. Gdy działa tylko jeden kierunek, sprawdź sysctl net.ipv4.conf.all.rp_filter. Ścisłe filtrowanie trasy odwrotnej odrzuca odpowiedzi przychodzące innym interfejsem, niż przewiduje trasa, a objaw wygląda dokładnie jak reguła zapory.

Przeczytaj objaw, zanim dotkniesz konfiguracji

Tunel się nie nawiązuje: klucze, adres endpointu lub zablokowany port UDP. Tunel wstał, ale hosty LAN martwe: umiejscowienie i routing. Tunel wstał, ale przeglądanie martwe: przekazywanie, NAT lub DNS. To trzy warstwy i trzy różne kontrole, a przepisywanie już poprawnej konfiguracji marnuje wieczór.

Dostępowość przychodząca z domu zasługuje na osobną kontrolę, bo decyduje, czy hosting w domu jest w ogóle możliwy. Porównaj adres WAN zgłaszany przez router z adresem, który widzi host zewnętrzny. Jeśli wpada w 100.64.0.0/10 albo oba się nie zgadzają, jesteś za carrier-grade NAT i żadne przekierowanie portu nigdy nie zadziała. Realne opcje to przekaźnik, łącze chmurowe, które dzwoni z domu na zewnątrz, albo przeniesienie endpointu.

Co daje hosting w domu i ile kosztuje

Dom to jedyne umiejscowienie, które domyślnie znajduje się w LAN, i to jest cały powód, by stawiać tam serwer. Urządzenia odpowiadające tylko w segmencie lokalnym, jak drukarki i strony administracji NAS odrzucające podsieci nielokalne, działają bez dodatkowego routingu. Sam też obsługujesz maszynę, router i łącze.

Koszty są fizyczne. Upload domowy jest pułapem dla wszystkich klientów naraz, więc wideorozmowa i kopia zapasowa rywalizują o tę samą rurę. Prąd, zużycie dysku, aktualizacje, dynamiczny adres wymagający DDNS, router, który musi przekierowywać UDP do środka, i być może podwójny NAT — wszystko spada na ciebie. To, co ludzie pomijają, to odtworzenie: jeśli skrzynka umrze, gdy cię nie ma, twoja jedyna droga do domu umiera razem z nią. Trzymaj drugie urządzenie z tymi samymi kluczami albo przynajmniej plan dostępu fizycznego.

Jeśli chcesz dostępu do LAN bez skrzynki w domu, zbuduj łącze zamiast udawać. Endpoint w chmurze staje się routerem: tunel od strony domu z AllowedIPs = 192.168.1.0/24 na peerze chmurowym, plus przekazywanie i NAT na skrzynce w chmurze. Przewodnik strongSwan po przekazywaniu przechodzi przez połowę powrotną tego układu i właśnie tam większość takich prób zawodzi. Peer domowy musi teraz działać, żeby cokolwiek działało, więc zamieniłeś jedną zależność na inną i powinieneś to zapisać.

Do czego właściwie służy endpoint w chmurze

Endpoint w chmurze zmienia twoje publiczne wyjście. Ruch wychodzi z zakresu adresów dostawcy, a witryny widzą ten adres zamiast domowego. W tym jest wartość i dlatego VPN w chmurze nie daje ci NAS: przeniosłeś wyjście, nie LAN.

Nadal prowadzisz system gościa, usługę VPN i jej dane logowania, podczas gdy dostawca prowadzi hiperwizor i sieć fizyczną, a ten podział ma znaczenie, gdy coś psuje się o 2 w nocy. Publiczny endpoint jest stale skanowany, więc trzymaj port zarządzania zamknięty, zezwalaj tylko na port VPN i łataj według harmonogramu. Grupy bezpieczeństwa i zapory dostawcy muszą dopuszczać ten port, a niektóre chmury odrzucają przekazywany ruch, jeśli nie dostroisz sprawdzania źródła i celu na instancji.

Mała instancja obsłuży garść klientów, ale szyfrowanie to praca CPU, a instancja burstable, której skończą się kredyty, zachowuje się nierówno pod stałym obciążeniem. Patrz na drogę, której naprawdę używasz, nie na kartę katalogową.

Decyzja, którą można zapisać

Zadanie decyduje o umiejscowieniu, nie etykieta na skrzynce. Jeśli potrzebujesz urządzenia w domowym LAN, najtańszą poprawną odpowiedzią jest endpoint w domu; skrzynka w chmurze działa dopiero po zbudowaniu łącza powrotnego. Jeśli potrzebujesz innego publicznego wyjścia, odpowiedzią jest chmura i pytanie o LAN w ogóle nie powstaje. Chcieć oba to legalne, ale oznacza dwa endpointy, dwa zestawy kluczy i dwie udokumentowane trasy.

Sprawdzaj od klienta po kolei: uzgadnianie, adres peera, host w LAN, potem IP wyjścia. curl -s https://ifconfig.me pokazuje, co widzi internet, a ip route get 192.168.1.20 pokazuje, w co wierzy endpoint. Gdy kontrola wyjścia przejdzie, a kontrola NAS wisi, odpowiedź o umiejscowieniu już masz; dostrajanie AllowedIPs na kliencie nie wyczaruje trasy. Podzielona linia jak 10.8.0.0/24, 192.168.1.0/24 trzyma ruch LAN w tunelu tylko wtedy, gdy ta trasa naprawdę istnieje.