Hemma-VPN-server kontra molnserver: vilken når din NAS?
Tunneln kommer upp, men hemma-NAS:en förblir onåbar. Välj slutpunktens placering efter resursen du måste nå, och kontrollera sedan rutten.
Tunneln kommer upp, klienten visar en grön prick, och ssh 192.168.1.20 hänger fortfarande tills tidsgränsen slår till. Jag råkade ut för exakt detta efter att ha hyrt en liten molninstans och lagt WireGuard på den: handskakning okej, DNS okej, och NAS:en på mitt skrivbord lika onåbar som om den stod på månen. Det var inget fel på tunneln. Slutpunkten stod i ett nätverk utan rutt till mitt hus. Slutpunktens placering avgör vilka nätverk som ligger intill, så välj den efter resursen du först måste nå och jämför hosting efteråt.
En tunnel når bara nätverk som slutpunkten kan routa till
En VPN ger klienten en adress inom slutpunktens eget routingdomän. När klienten skickar ett paket till 192.168.1.20 måste slutpunkten veta vart det tar vägen. En moln-VM:s tabell känner till leverantörens VPC-subnät; om ditt LAN har den aldrig hört talas om. Ansluten och nåbar är två olika fakta, och det mesta av förvirringen mellan hem och moln kommer av att ta det första som bevis för det andra.
Ett kommando avgör saken. På slutpunkten ip route get 192.168.1.20 namnger antingen ett LAN-gränssnitt eller pekar på standardrutten. På en hemmamaskin är svaret LAN-sidan. På en molninstans lämnar paketet mot internet och dör. Att slå på net.ipv4.ip_forward=1 och lägga till en MASQUERADE-regel ändrar inte det, för det finns inget att vidarebefordra till förrän något på hemsidan avslutar en länk in i molnet.
Hemfallet har en andra halva: returvägen. Paket som lämnar LAN:et genom tunnelboxen får NAT, eller så behöver LAN:et en statisk rutt tillbaka till tunnelns subnät. När bara en riktning fungerar, kontrollera sysctl net.ipv4.conf.all.rp_filter. Strikta reverse-path-filter släpper svar som anländer på ett annat gränssnitt än rutten förutser, och symptomet ser precis ut som en brandväggsregel.
Läs symptomet innan du rör konfigurationen
Tunnel upprättas inte: nycklar, slutpunktsadress eller en blockerad UDP-port. Tunnel uppe men LAN-värdar döda: placering och routing. Tunnel uppe men surfning död: vidarebefordran, NAT eller DNS. Det är tre lager och tre olika kontroller, och att skriva om en konfiguration som redan var rätt kostar en kväll.
| 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 |
Inkommande nåbarhet hemifrån förtjänar en egen kontroll, eftersom den avgör om hosting hemma alls är möjligt. Jämför WAN-adressen som routern rapporterar med adressen en extern värd ser. Om den hamnar i 100.64.0.0/10, eller de två inte stämmer, sitter du bakom carrier-grade NAT och ingen portvidarebefordran kommer någonsin att fungera. De verkliga alternativen är en relay, en molnlänk som ringer utåt hemifrån, eller att flytta slutpunkten.
Vad hosting hemma ger och vad det kostar
Hemmet är den enda placeringen som ligger inne i LAN:et som standard, och det är hela skälet att sätta en server där. Enheter som bara svarar på det lokala segmentet, som skrivare och NAS-adminsidor som avvisar icke-lokala subnät, fungerar utan extra routing. Du sköter också maskinen, routern och upplänken själv.
Kostnaderna är fysiska. Hemmauppladdningen är taket för alla klienter samtidigt, så ett videosamtal och en säkerhetskopia konkurrerar om samma rör. Ström, diskslitage, uppdateringar, en dynamisk adress som behöver DDNS, en router som måste vidarebefordra UDP inåt, och möjligen dubbel NAT landar allt på dig. Det folk hoppar över är återställning: om boxen dör medan du är borta dör din enda väg in i huset med den. Håll en andra enhet med samma nycklar, eller åtminstone en plan för fysisk åtkomst.
Vill du ha LAN-åtkomst utan boxen hemma, bygg en länk i stället för att låtsas. Molnslutpunkten blir en router: en tunnel från hemsidan med AllowedIPs = 192.168.1.0/24 på molnpeeren, plus vidarebefordran och NAT på molnboxen. strongSwans guide för vidarebefordran går igenom returhalvan av den uppsättningen, och det är där de flesta av dessa försök misslyckas. Hempeeren måste nu vara uppe för att något ska fungera, så du bytte ett beroende mot ett annat och borde skriva ner det.
Vad en molnslutpunkt egentligen är till för
En molnslutpunkt ändrar din offentliga utgång. Trafiken lämnar leverantörens adressområde, och webbplatser ser den adressen i stället för din hemadress. Det är värdet, och det är också därför en moln-VPN inte ger dig NAS:en: du flyttade utgången, inte LAN:et.
Du kör fortfarande gästsystemet, VPN-tjänsten och dess uppgifter medan leverantören kör hypervisorn och det fysiska nätet, och den uppdelningen spelar roll när något går sönder klockan 2 på natten. En offentlig slutpunkt skannas ständigt, så håll administrationsporten stängd, tillåt bara VPN-porten och uppdatera enligt ett schema. Säkerhetsgrupper och leverantörens brandväggar måste tillåta den porten, och vissa moln kastar vidarebefordrad trafik om du inte justerar käll- och målkontrollen på instansen.
En liten instans täcker en handfull klienter, men kryptering är CPU-arbete, och en burstable-instans som tar slut på krediter beter sig ojämnt under varaktig last. Titta på vägen du faktiskt använder, inte på databladet.
Ett beslut du kan skriva ner
Uppgiften avgör placeringen, inte etiketten på boxen. Behöver du en enhet på ditt hemma-LAN är det billigaste korrekta svaret en slutpunkt hemma; en molnbox fungerar först efter att du byggt länken tillbaka. Behöver du en annan offentlig utgång är svaret molnet och LAN-frågan uppstår aldrig. Att vilja ha båda är legitimt, men det betyder två slutpunkter, två nyckeluppsättningar och två dokumenterade rutter.
| 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 |
Verifiera från klienten i ordning: handskakning, peer-adress, en LAN-värd, sedan utgångs-IP:n. curl -s https://ifconfig.me visar vad internet ser, och ip route get 192.168.1.20 visar vad slutpunkten tror. När utgångskontrollen går igenom och NAS-kontrollen hänger har du redan svaret om placeringen; att justera AllowedIPs på klienten trollar inte fram en rutt. En delad rad som 10.8.0.0/24, 192.168.1.0/24 håller LAN-trafik inne i tunneln bara när den rutten faktiskt finns.