Domácí VPN server versus cloud server: který dosáhne na váš NAS?

Tunel se naváže, klient ukáže zelenou tečku a ssh 192.168.1.20 stále visí, dokud nevyprší čas. Přesně to jsem zažil, když jsem si pronajal malou cloudovou instanci a nainstaloval na ni WireGuard: handshake v pořádku, DNS v pořádku a NAS na mém stole stejně nedostupný, jako by byl na Měsíci. S tunelem nebylo nic špatně. Endpoint stál v síti, která nemá trasu k mému domu. Umístění endpointu určuje, které sítě jsou sousední, proto ho vyberte podle prostředku, ke kterému musíte dosáhnout nejdřív, a hosting srovnávejte až druhotně.

Tunel dosáhne jen na sítě, které endpoint umí směrovat

VPN přidělí vašemu klientovi adresu uvnitř směrovací domény endpointu. Když klient pošle paket na 192.168.1.20, endpoint musí vědět, kam jde. Tabulka cloudové VM zná podsítě VPC poskytovatele; o vaší LAN nikdy neslyšela. Připojeno a dostupné jsou dvě různé skutečnosti a většina zmatení mezi domovem a cloudem pramení z toho, že se první bere jako důkaz druhého.

Jediný příkaz to rozhodne. Na endpointu ip route get 192.168.1.20 buď pojmenuje LAN rozhraní, nebo ukáže na výchozí trasu. Na domácím boxu je odpověď LAN strana. Na cloudové instanci paket odejde k internetu a zemře. Zapnutí net.ipv4.ip_forward=1 a přidání pravidla MASQUERADE to nezmění, protože není kam směrovat, dokud něco na domácí straně neukončí spojení do cloudu.

Domácí případ má druhou polovinu: zpáteční cestu. Pakety opouštějící LAN přes tunelový box procházejí NAT, nebo LAN potřebuje statickou trasu zpět do podsítě tunelu. Když funguje jen jeden směr, zkontrolujte sysctl net.ipv4.conf.all.rp_filter. Striktní filtrování zpětné cesty zahazuje odpovědi, které dorazí na jiné rozhraní, než trasu předpovídá, a příznak vypadá přesně jako pravidlo firewallu.

Přečtěte si příznak, než sáhnete na konfiguraci

Tunel se nenaváže: klíče, adresa endpointu nebo blokovaný UDP port. Tunel běží, ale LAN hostitelé jsou mrtví: umístění a směrování. Tunel běží, ale prohlížení je mrtvé: přesměrování, NAT nebo DNS. To jsou tři vrstvy a tři různé kontroly, a přepisování už správné konfigurace promarní večer.

Příchozí dostupnost domova si zaslouží vlastní kontrolu, protože rozhoduje, zda je hostování doma vůbec možné. Srovnejte WAN adresu, kterou hlásí router, s adresou, kterou vidí vnější hostitel. Pokud spadne do 100.64.0.0/10 nebo se obě neshodují, jste za carrier-grade NAT a žádné přesměrování portu nebude nikdy fungovat. Skutečné možnosti jsou relay, cloudové spojení, které volá z domova ven, nebo přesunutí endpointu.

Co domácí hosting přináší a co stojí

Domov je jediné umístění, které je ve výchozím stavu uvnitř LAN, a to je celý důvod, proč tam server dávat. Zařízení, která odpovídají jen na lokálním segmentu, jako tiskárny a admin stránky NAS odmítající nelokální podsítě, fungují bez dalšího směrování. Také sami provozujete stroj, router i uplink.

Náklady jsou fyzické. Domácí upload je strop pro všechny klienty najednou, takže videohovor a záloha soupeří o stejnou trubku. Elektřina, opotřebení disku, záplaty, dynamická adresa, která potřebuje DDNS, router, který musí přesměrovávat UDP dovnitř, a případný dvojitý NAT — to všechno padá na vás. Co lidé přeskakují, je obnova: když box zemře, zatímco jste pryč, zemře s ním i vaše jediná cesta domů. Držte druhé zařízení se stejnými klíči, nebo aspoň plán fyzického přístupu.

Pokud chcete přístup do LAN bez boxu doma, postavte spojení, místo abyste to předstírali. Cloudový endpoint se stane routerem: tunel z domácí strany s AllowedIPs = 192.168.1.0/24 na cloudovém peeru, plus přesměrování a NAT na cloudovém boxu. Návod strongSwan pro přesměrování prochází zpáteční polovinu této konfigurace a právě tam většina těchto pokusů selhává. Domácí peer teď musí být nahoru, aby cokoli fungovalo, takže jste vyměnili jednu závislost za jinou a měli byste si to zapsat.

K čemu cloudový endpoint vlastně je

Cloudový endpoint mění váš veřejný výstup. Provoz odchází z rozsahu adres poskytovatele a weby vidí tuto adresu místo vaší domácí. V tom je hodnota, a proto vám cloudová VPN nedává NAS: přesunuli jste výstup, ne LAN.

Stále spravujete hostovaný systém, službu VPN a její přihlašovací údaje, zatímco poskytovatel spravuje hypervisor a fyzickou síť, a toto rozdělení je důležité, když se něco pokazí ve 2 hodiny ráno. Veřejný endpoint je nepřetržitě skenován, proto držte řídicí port zavřený, povolte jen port VPN a záplatujte podle plánu. Bezpečnostní skupiny a firewally poskytovatele musí tento port povolit a některé cloudy zahazují přesměrovaný provoz, dokud na instanci nenastavíte kontrolu zdroje a cíle.

Malá instance pokryje hrst klientů, ale šifrování je práce CPU a burstable instance, které dojdou kredity, se při trvalé zátěži chová nerovnoměrně. Sledujte cestu, kterou opravdu používáte, ne specifikační list.

Rozhodnutí, které si můžete zapsat

Úkol určuje umístění, ne etiketa na boxu. Pokud potřebujete zařízení v domácí LAN, nejlevnější správná odpověď je endpoint doma; cloudový box funguje jen poté, co postavíte spojení zpět. Pokud potřebujete jiný veřejný výstup, odpověď je cloud a otázka LAN vůbec nevzniká. Chtít obojí je legitimní, ale znamená dva endpointy, dvě sady klíčů a dvě zdokumentované trasy.

Ověřujte z klienta popořadě: handshake, adresa peeru, hostitel LAN, pak IP výstupu. curl -s https://ifconfig.me ukazuje, co vidí internet, a ip route get 192.168.1.20 ukazuje, co si endpoint myslí. Když kontrola výstupu projde a kontrola NAS visí, odpověď o umístění už máte; nastavení AllowedIPs na klientu trasu nevytvoří. Rozdělený řádek jako 10.8.0.0/24, 192.168.1.0/24 udrží provoz LAN uvnitř tunelu jen tehdy, když tato trasa skutečně existuje.