Hjemme-VPN-server kontra cloudserver: hvilken når din NAS?
Tunnelen kommer op, men hjemmets NAS forbliver uopnåelig. Vælg endpointets placering efter den ressource, du skal have fat i, og kontroller derefter ruten.
Tunnelen kommer op, klienten viser en grøn prik, og ssh 192.168.1.20 hænger stadig, indtil den timer ud. Det oplevede jeg præcis, efter at jeg havde lejet en lille cloudinstans og lagt WireGuard på den: håndtryk fint, DNS fint, og NAS'en på mit skrivebord lige så uopnåelig, som hvis den stod på månen. Der var intet galt med tunnelen. Endpointet var placeret i et netværk uden rute til mit hus. Endpointets placering afgør, hvilke netværk der er naboer, så vælg den efter den ressource, du først skal have fat i, og sammenlign hosting bagefter.
En tunnel når kun netværk, som endpointet kan route til
En VPN giver din klient en adresse inde i endpointets eget routingdomæne. Når klienten sender en pakke til 192.168.1.20, skal endpointet vide, hvor den skal hen. En cloud-VMs tabel kender udbyderens VPC-subnetter; den har aldrig hørt om dit LAN. Forbundet og tilgængelig er to forskellige fakta, og det meste af forvirringen mellem hjem og cloud kommer af at tage det første som bevis for det andet.
Én kommando afgør sagen. På endpointet ip route get 192.168.1.20 angiver enten et LAN-interface eller peger på standardruten. På en hjemmeboks er svaret LAN-siden. På en cloudinstans forlader pakken mod internettet og dør. At slå net.ipv4.ip_forward=1 til og tilføje en MASQUERADE-regel ændrer ikke det, for der er intet at videresende til, før noget på hjemsiden afslutter et link ind i skyen.
Hjemmesagen har en anden halvdel: returvejen. Pakker, der forlader LAN'et gennem tunelboksen, bliver NAT'et, eller LAN'et har brug for en statisk rute tilbage til tunel-subnettet. Når kun én retning virker, så tjek sysctl net.ipv4.conf.all.rp_filter. Streng reverse-path-filtrering dropper svar, der ankommer på et andet interface, end ruten forudsiger, og symptomet ligner præcis en firewallregel.
Læs symptomet, før du rører konfigurationen
Tunnel etableres ikke: nøgler, endpointadresse eller en blokeret UDP-port. Tunnel oppe, men LAN-værter døde: placering og routing. Tunnel oppe, men browsing død: forwarding, NAT eller DNS. Det er tre lag og tre forskellige tjek, og at skrive en konfiguration om, som allerede var korrekt, spilder en aften.
| 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 |
Indgående tilgængelighed hjemmefra fortjener sit eget tjek, fordi det afgør, om hosting derhjemme overhovedet er muligt. Sammenlign den WAN-adresse, routeren rapporterer, med den adresse, en ekstern vært ser. Hvis den ligger i 100.64.0.0/10, eller de to er uenige, er du bag carrier-grade NAT, og ingen portforwarding vil nogensinde virke. De reelle muligheder er en relay, et cloud-link, der ringer udad hjemmefra, eller at flytte endpointet.
Hvad hjemmehosting giver dig, og hvad det koster
Hjemmet er den eneste placering, der som standard ligger inde i LAN'et, og det er hele grunden til at sætte en server der. Enheder, der kun svarer på det lokale segment, som printere og NAS-adminsider, der afviser ikke-lokale subnets, virker uden ekstra routing. Du driver også selv maskinen, routeren og uplinket.
Omkostningerne er fysiske. Hjemmeupload er loftet for alle klienter på én gang, så et videosamtale og en backup konkurrerer om samme rør. Strøm, diskslid, patches, en dynamisk adresse, der kræver DDNS, en router, der skal forwarde UDP indad, og muligvis dobbelt NAT lander alt på dig. Det, folk springer over, er gendannelse: dør boksen, mens du er væk, dør din eneste vej ind i huset med den. Hold en ekstra enhed med de samme nøgler, eller i det mindste en plan for fysisk adgang.
Vil du have LAN-adgang uden boksen derhjemme, så byg et link i stedet for at lade som om. Cloud-endpointet bliver en router: en tunnel fra hjemsiden med AllowedIPs = 192.168.1.0/24 på cloud-peeren, plus forwarding og NAT på cloud-boksen. strongSwans forwarding-guide gennemgår returhalvdelen af den opsætning, og det er der, de fleste af disse forsøg fejler. Hjemme-peeren skal nu være oppe, for at noget som helst virker, så du har byttet en afhængighed for en anden og bør skrive det ned.
Hvad et cloud-endpoint egentlig er til
Et cloud-endpoint ændrer din offentlige udgang. Trafik forlader udbyderens adresseområde, og websteder ser den adresse i stedet for din hjemmeadresse. Det er værdien, og det er også derfor en cloud-VPN ikke giver dig NAS'en: du flyttede udgangen, ikke LAN'et.
Du kører stadig gæstesystemet, VPN-tjenesten og dens legitimationsoplysninger, mens udbyderen kører hypervisoren og det fysiske netværk, og den opdeling betyder noget, når noget går i stykker klokken 2 om natten. Et offentligt endpoint scannes konstant, så hold administrationsporten lukket, tillad kun VPN-porten, og patch efter en plan. Sikkerhedsgrupper og udbyderens firewalls skal tillade den port, og nogle clouds dropper forwardet trafik, medmindre du justerer kilde- og destinationskontrol på instansen.
En lille instans dækker en håndfuld klienter, men kryptering er CPU-arbejde, og en burstable instans, der løber tør for kreditter, opfører sig ujævnt under vedvarende last. Se på den vej, du faktisk bruger, i stedet for databladet.
En beslutning, du kan skrive ned
Opgaven afgør placeringen, ikke etiketten på boksen. Skal du have en enhed på dit hjemme-LAN, er det billigste korrekte svar et endpoint derhjemme; en cloud-boks virker først, når du har bygget linket tilbage. Skal du have en anden offentlig udgang, er cloud svaret, og LAN-spørgsmålet opstår aldrig. At ville begge dele er legitimt, men det betyder to endpoints, to sæt nøgler og to dokumenterede ruter.
| 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 |
Bekræft fra klienten i rækkefølge: håndtryk, peer-adresse, en LAN-vært, derefter udgangs-IP'en. curl -s https://ifconfig.me viser, hvad internettet ser, og ip route get 192.168.1.20 viser, hvad endpointet tror. Når udgangstjekket består og NAS-tjekket hænger, har du allerede dit svar om placeringen; at justere AllowedIPs på klienten fremkalder ikke en rute. En delt linje som 10.8.0.0/24, 192.168.1.0/24 holder kun LAN-trafik inde i tunnelen, når den rute faktisk findes.