Otthoni VPN-kiszolgáló vagy felhőkiszolgáló: melyik éri el a NAS-odat?
Az alagút feljön, de az otthoni NAS elérhetetlen marad. Az erőforrás alapján válaszd ki a végpont helyét, amelyet el kell érned, majd ellenőrizd az útvonalat.
Az alagút feljön, a kliens zöld pontot mutat, és ssh 192.168.1.20 még mindig lóg, amíg le nem jár az idő. Pontosan ezt éltem át, miután béreltem egy kis felhőpéldányt és WireGuardot tettem rá: kézfogás rendben, DNS rendben, és az asztalomon lévő NAS olyan elérhetetlen, mintha a Holdon lenne. Az alagúttal semmi sem volt baj. A végpont olyan hálózatban állt, amelyből nincs útvonal a házamhoz. A végpont helye dönti el, mely hálózatok szomszédosak, ezért az erőforrás szerint válaszd, amelyet először el kell érned, és a tárhelyet csak másodszor hasonlítsd össze.
Az alagút csak azokat a hálózatokat éri el, amelyeket a végpont tud route-olni
A VPN a végpont saját routingtartományán belül ad címet a kliensnek. Amikor a kliens csomagot küld a 192.168.1.20-ra, a végpontnak tudnia kell, hová megy. Egy felhő-VM táblája ismeri a szolgáltató VPC-alhálózatait; a te LAN-odról soha nem hallott. Csatlakoztatva és elérhető két különböző tény, és az otthon-felhő zavar nagy része abból jön, hogy az elsőt a második bizonyítékának veszik.
Egy parancs eldönti. A végponton a ip route get 192.168.1.20 vagy egy LAN-interfészt nevez meg, vagy az alapértelmezett útvonalra mutat. Otthoni gépen a válasz a LAN-oldal. Felhőpéldányon a csomag az internet felé indul és meghal. A net.ipv4.ip_forward=1 bekapcsolása és egy MASQUERADE-szabály hozzáadása nem változtat ezen, mert nincs hová továbbítani, amíg valami az otthoni oldalon le nem zár egy kapcsolatot a felhő felé.
Az otthoni esetnek van egy második fele: a visszaút. A LAN-t az alagútdobozon át elhagyó csomagok NAT-olódnak, vagy a LAN-nak statikus útvonalra van szüksége vissza az alagút alhálózatába. Ha csak egy irány működik, ellenőrizd a sysctl net.ipv4.conf.all.rp_filter. A szigorú fordított útvonal szűrés eldobja azokat a válaszokat, amelyek más interfészen érkeznek, mint amit az útvonal jelez, és a tünet pontosan egy tűzfal-szabályra hasonlít.
Olvasd el a tünetet, mielőtt a konfigurációhoz nyúlsz
Az alagút nem jön létre: kulcsok, végpontcím vagy blokkolt UDP-port. Az alagút fent, de a LAN-gazdák halottak: elhelyezés és routing. Az alagút fent, de a böngészés halott: továbbítás, NAT vagy DNS. Ez három réteg és három különböző ellenőrzés, és egy már helyes konfiguráció újraírása egy estét pazarol el.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
Az otthoni bejövő elérhetőség külön ellenőrzést érdemel, mert ez dönti el, egyáltalán lehetséges-e az otthoni tárhely. Hasonlítsd össze a router által jelentett WAN-címet azzal a címmel, amelyet egy külső gazda lát. Ha 100.64.0.0/10-be esik, vagy a kettő nem egyezik, carrier-grade NAT mögött vagy, és semmilyen porttovábbítás nem fog működni. A valódi lehetőségek egy relay, egy felhőkapcsolat, amely otthonról kifelé tárcsáz, vagy a végpont áthelyezése.
Mit ad az otthoni tárhely, és mennyibe kerül
Az otthon az egyetlen hely, amely alapértelmezés szerint a LAN-on belül van, és ez az egész oka annak, hogy ott szervert tartasz. Azok az eszközök, amelyek csak a helyi szegmensen válaszolnak, például a nyomtatók és a nem helyi alhálózatokat elutasító NAS-admin oldalak, extra routing nélkül működnek. A gépet, a routert és a feltöltési kapcsolatot is te üzemelteted.
A költségek fizikaiak. Az otthoni feltöltés minden kliens számára egyszerre a plafon, így a videóhívás és a biztonsági mentés ugyanazért a csőért verseng. Áram, lemezkopás, javítások, egy dinamikus cím, amelyhez DDNS kell, egy router, amelynek UDP-t kell befelé továbbítania, és esetleg kettős NAT — mindez rajtad landol. Amit az emberek kihagynak, az a helyreállítás: ha a doboz meghal, miközben távol vagy, a házba vezető egyetlen utad is meghal vele. Tarts egy második eszközt ugyanazokkal a kulcsokkal, vagy legalább egy tervet a fizikai hozzáférésre.
Ha LAN-hozzáférést szeretnél otthoni doboz nélkül, építs kapcsolatot a színlelés helyett. A felhő-végpont routerré válik: alagút az otthoni oldalról AllowedIPs = 192.168.1.0/24 beállítással a felhő-peer-en, plusz továbbítás és NAT a felhődobozon. A strongSwan továbbítási útmutatója végigveszi a beállítás visszaút-felét, és itt bukik el e kísérletek többsége. Az otthoni peernek most futnia kell ahhoz, hogy bármi működjön, tehát egy függőséget cseréltél egy másikra, és ezt írd fel.
Mire való valójában egy felhő-végpont
A felhő-végpont megváltoztatja a nyilvános kilépést. A forgalom a szolgáltató címtartományából indul, és az oldalak ezt a címet látják az otthoni helyett. Ez az érték, és ezért nem ad felhő-VPN NAS-t: a kilépést mozgattad el, nem a LAN-t.
Te továbbra is a vendégrendszert, a VPN-szolgáltatást és annak hitelesítő adatait futtatod, míg a szolgáltató a hipervizort és a fizikai hálózatot, és ez a felosztás számít, amikor hajnali 2-kor elromlik valami. A nyilvános végpontot folyamatosan szkennelik, ezért tartsd zárva a kezelőportot, csak a VPN-portot engedélyezd, és ütemezetten foltozz. A biztonsági csoportoknak és a szolgáltató tűzfalainak engedélyezniük kell ezt a portot, és néhány felhő eldobja a továbbított forgalmat, hacsak nem állítod be a forrás- és cél-ellenőrzést a példányon.
Egy kis példány maroknyi klienst fed le, de a titkosítás CPU-munka, és a kreditjeit kimerítő burstable példány egyenetlenül viselkedik tartós terhelés alatt. A ténylegesen használt utat nézd, ne az adatlapot.
Egy döntés, amit le lehet írni
A feladat dönti el az elhelyezést, nem a dobozon lévő címke. Ha eszköz kell az otthoni LAN-on, a legolcsóbb helyes válasz egy otthoni végpont; a felhődoboz csak azután működik, hogy felépítetted a vissza kapcsolatot. Ha más nyilvános kilépés kell, a válasz a felhő, és a LAN kérdése fel sem merül. Mindkettőt akarni jogos, de ez két végpontot, két kulcskészletet és két dokumentált útvonalat jelent.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
Ellenőrizd a klienstől sorrendben: kézfogás, peer-cím, LAN-gazda, majd a kilépő IP. curl -s https://ifconfig.me mutatja, mit lát az internet, és ip route get 192.168.1.20 mutatja, mit hisz a végpont. Amikor a kilépés-ellenőrzés átmegy és a NAS-ellenőrzés lóg, már megvan a válaszod az elhelyezésről; az AllowedIPs módosítása a kliensen nem varázsol útvonalat. Egy osztott sor, mint a 10.8.0.0/24, 192.168.1.0/24 csak akkor tartja a LAN-forgalmat az alagútban, ha az az útvonal valóban létezik.