Hjemme-VPN-server mot skyserver: hvilken når NAS-en din?
Tunnelen kommer opp, men hjemme-NAS-en forblir uoppnåelig. Velg endepunktets plassering etter ressursen du må nå, og kontroller deretter ruten.
Tunnelen kommer opp, klienten viser en grønn prikk, og ssh 192.168.1.20 henger fortsatt til tidsavbruddet. Jeg opplevde akkurat dette etter å ha leid en liten skyinstans og lagt WireGuard på den: håndtrykk i orden, DNS i orden, og NAS-en på skrivebordet mitt like uoppnåelig som om den sto på månen. Det var ingenting galt med tunnelen. Endepunktet sto i et nettverk uten rute til huset mitt. Endepunktets plassering avgjør hvilke nettverk som er naboer, så velg den etter ressursen du først må nå, og sammenlign hosting etterpå.
En tunnel når bare nettverk endepunktet kan rute til
En VPN gir klienten din en adresse inne i endepunktets eget rutingsdomene. Når klienten sender en pakke til 192.168.1.20, må endepunktet vite hvor den skal. Tabellen til en sky-VM kjenner leverandørens VPC-subnett; om LAN-et ditt har den aldri hørt. Tilkoblet og nåbar er to forskjellige fakta, og det meste av forvirringen mellom hjem og sky kommer av å ta det første som bevis for det andre.
Én kommando avgjør saken. På endepunktet ip route get 192.168.1.20 navngir enten et LAN-grensesnitt eller peker på standardruten. På en hjemmemaskin er svaret LAN-siden. På en skyinstans forlater pakken mot internett og dør. Å slå på net.ipv4.ip_forward=1 og legge til en MASQUERADE-regel endrer ikke det, for det er ingenting å videresende til før noe på hjemmesiden avslutter en lenke inn i skyen.
Hjemmetilfellet har en andre halvdel: returveien. Pakker som forlater LAN-et gjennom tunellboksen blir NAT-et, eller LAN-et trenger en statisk rute tilbake til tunellsubnettet. Når bare én retning virker, sjekk sysctl net.ipv4.conf.all.rp_filter. Streng reverse-path-filtrering slipper svar som ankommer på et annet grensesnitt enn ruten forutsier, og symptomet ser nøyaktig ut som en brannmurregel.
Les symptomet før du rører konfigurasjonen
Tunnel opprettes ikke: nøkler, endepunktadresse eller en blokkert UDP-port. Tunnel oppe, men LAN-verter døde: plassering og ruting. Tunnel oppe, men surfing død: videresending, NAT eller DNS. Det er tre lag og tre forskjellige sjekker, og å skrive om en konfigurasjon som allerede var riktig koster en kveld.
| 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 |
Innkommende nåbarhet hjemmefra fortjener sin egen sjekk, fordi den avgjør om hosting hjemme i det hele tatt er mulig. Sammenlign WAN-adressen ruteren rapporterer med adressen en ekstern vert ser. Hvis den ligger i 100.64.0.0/10, eller de to ikke stemmer, er du bak carrier-grade NAT og ingen portvideresending vil noen gang virke. De reelle alternativene er en relay, en skylenke som ringer utover hjemmefra, eller å flytte endepunktet.
Hva hjemmehosting gir deg, og hva det koster
Hjemmet er den eneste plasseringen som ligger inne i LAN-et som standard, og det er hele grunnen til å sette en server der. Enheter som bare svarer på det lokale segmentet, som skrivere og NAS-adminsider som avviser ikke-lokale subnett, virker uten ekstra ruting. Du driver også maskinen, ruteren og opplastingslinjen selv.
Kostnadene er fysiske. Hjemmeopplasting er taket for alle klienter samtidig, så en videosamtale og en sikkerhetskopi konkurrerer om samme rør. Strøm, diskslitasje, oppdateringer, en dynamisk adresse som trenger DDNS, en ruter som må videresende UDP innover, og muligens dobbel NAT lander alt på deg. Det folk hopper over, er gjenoppretting: hvis boksen dør mens du er borte, dør din eneste vei inn i huset med den. Ha en ekstra enhet med de samme nøklene, eller i det minste en plan for fysisk tilgang.
Hvis du vil ha LAN-tilgang uten boksen hjemme, bygg en lenke i stedet for å late som. Skyendepunktet blir en ruter: en tunnel fra hjemmesiden med AllowedIPs = 192.168.1.0/24 på sky-peer-en, pluss videresending og NAT på skyboksen. Videresendingsveiledningen til strongSwan går gjennom returhalvdelen av den oppsettet, og det er der de fleste av disse forsøkene feiler. Hjemme-peer-en må nå være oppe for at noe skal virke, så du byttet en avhengighet mot en annen og bør skrive det ned.
Hva et skyendepunkt egentlig er for
Et skyendepunkt endrer den offentlige utgangen din. Trafikken forlater leverandørens adresseområde, og nettsteder ser den adressen i stedet for hjemadressen. Det er verdien, og det er også grunnen til at en sky-VPN ikke gir deg NAS-en: du flyttet utgangen, ikke LAN-et.
Du kjører fortsatt gjestsystemet, VPN-tjenesten og legitimasjonen mens leverandøren kjører hypervisoren og det fysiske nettet, og den delingen betyr noe når noe ryker klokken 2 om natten. Et offentlig endepunkt skannes kontinuerlig, så hold administrasjonsporten lukket, tillat bare VPN-porten, og oppdater etter en plan. Sikkerhetsgrupper og leverandørens brannmurer må tillate den porten, og noen skyer dropper videresendt trafikk med mindre du justerer kilde- og destinasjonskontrollen på instansen.
En liten instans dekker en håndfull klienter, men kryptering er CPU-arbeid, og en burstable instans som går tom for kreditter oppfører seg ujevnt under vedvarende last. Se på veien du faktisk bruker, ikke databladet.
En beslutning du kan skrive ned
Oppgaven avgjør plasseringen, ikke etiketten på boksen. Trenger du en enhet på hjemme-LAN-et, er det billigste riktige svaret et endepunkt hjemme; en skyboks virker først etter at du har bygget lenken tilbake. Trenger du en annen offentlig utgang, er svaret skyen og LAN-spørsmålet oppstår aldri. Å ville begge er legitimt, men det betyr to endepunkter, to nøkkelsett og to dokumenterte 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 |
Verifiser fra klienten i rekkefølge: håndtrykk, peer-adresse, en LAN-vert, deretter utgangs-IP-en. curl -s https://ifconfig.me viser hva internett ser, og ip route get 192.168.1.20 viser hva endepunktet tror. Når utgangssjekken består og NAS-sjekken henger, har du allerede svaret om plasseringen; å justere AllowedIPs på klienten tryller ikke fram en rute. En delt linje som 10.8.0.0/24, 192.168.1.0/24 holder LAN-trafikk inne i tunnelen bare når den ruten faktisk finnes.