Heime-VPN-server mot skyserver: kva for ein når NAS-en din?
Tunnelen kjem opp, men heime-NAS-en held fram med å vere utilgjengeleg. Vel plasseringa til endepunktet etter ressursen du må nå, og kontroller deretter ruta.
Tunnelen kjem opp, klienten viser ein grøn prikk, og ssh 192.168.1.20 heng enno til tidsavbrotet. Eg opplevde nett dette etter å ha leigd ein liten skyinstans og lagt WireGuard på han: handtrykk i orden, DNS i orden, og NAS-en på skrivebordet mitt like utilgjengeleg som om han stod på månen. Det var ingenting gale med tunnelen. Endepunktet stod i eit nettverk utan rute til huset mitt. Plasseringa til endepunktet avgjer kva nettverk som er naboar, så vel han etter ressursen du først må nå, og samanlikn hosting etterpå.
Ein tunnel når berre nettverk endepunktet kan rute til
Ein VPN gir klienten din ei adresse inne i endepunktet sitt eige rutingsdomene. Når klienten sender ein pakke til 192.168.1.20, må endepunktet vite kvar han skal. Tabellen til ein sky-VM kjenner VPC-subnetta til leverandøren; om LAN-et ditt har han aldri høyrt. Tilkopla og nåbar er to ulike fakta, og det meste av forvirringa mellom heime og sky kjem av å ta det første som prov for det andre.
Éin kommando avgjer saka. På endepunktet ip route get 192.168.1.20 namngir anten eit LAN-grensesnitt eller peiker på standardruta. På ein heimemaskin er svaret LAN-sida. På ein skyinstans forlèt pakken mot internett og døyr. Å slå på net.ipv4.ip_forward=1 og leggje til ei MASQUERADE-regel endrar ikkje det, for det er ingenting å videresende til før noko på heimesida avsluttar ei lenkje inn i skyen.
Heimetilfellet har ei andre halvdel: returvegen. Pakkar som forlèt LAN-et gjennom tunellboksen blir NAT-a, eller LAN-et treng ei statisk rute tilbake til tunellsubnettet. Når berre éin retning verkar, sjekk sysctl net.ipv4.conf.all.rp_filter. Streng reverse-path-filtrering slepp svar som kjem inn på eit anna grensesnitt enn ruta føreser, og symptomet ser nøyaktig ut som ei brannmurregel.
Les symptomet før du rører konfigurasjonen
Tunnel blir ikkje oppretta: nøklar, endepunktadresse eller ein blokkert UDP-port. Tunnel oppe, men LAN-vertar døde: plassering og ruting. Tunnel oppe, men surfing død: videresending, NAT eller DNS. Det er tre lag og tre ulike sjekkar, og å skrive om ein konfigurasjon som alt var riktig kostar ein 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 |
Innkommande nåbarheit heimanfrå fortener sin eigen sjekk, fordi han avgjer om hosting heime i det heile er mogleg. Samanlikn WAN-adressa rutaren rapporterer med adressa ein ekstern vert ser. Viss ho ligg i 100.64.0.0/10, eller dei to ikkje stemmer, er du bak carrier-grade NAT og inga portvideresending vil nokon gong verke. Dei reelle alternativa er ein relay, ei skylenkje som ringjer utover heimanfrå, eller å flytte endepunktet.
Kva heimehosting gir deg, og kva det kostar
Heimen er den einaste plasseringa som ligg inne i LAN-et som standard, og det er heile grunnen til å setje ein server der. Einingar som berre svarar på det lokale segmentet, som skrivarar og NAS-adminsider som avviser ikkje-lokale subnett, verkar utan ekstra ruting. Du driv òg maskinen, rutaren og opplastingslinja sjølv.
Kostnadene er fysiske. Heimeopplasting er taket for alle klientar samtidig, så ein videosamtale og ein sikkerheitskopi konkurrerer om same røyret. Straum, diskslitasje, oppdateringar, ei dynamisk adresse som treng DDNS, ein rutar som må videresende UDP innover, og kanskje dobbel NAT landar alt på deg. Det folk hoppar over, er gjenoppretting: viss boksen døyr medan du er borte, døyr din einaste veg inn i huset med han. Ha ei ekstra eining med dei same nøklane, eller i det minste ein plan for fysisk tilgang.
Vil du ha LAN-tilgang utan boksen heime, bygg ei lenkje i staden for å late som. Skyendepunktet blir ein rutar: ein tunnel frå heimesida med AllowedIPs = 192.168.1.0/24 på sky-peer-en, pluss videresending og NAT på skyboksen. Videresendingsrettleiinga til strongSwan går gjennom returhalvdelen av det oppsettet, og det er der dei fleste av desse forsøka feilar. Heime-peer-en må no vere oppe for at noko skal verke, så du bytte ein avhengigheit mot ei anna og bør skrive det ned.
Kva eit skyendepunkt eigentleg er til for
Eit skyendepunkt endrar den offentlege utgangen din. Trafikken forlèt adresseområdet til leverandøren, og nettstader ser den adressa i staden for heimeadressa. Det er verdien, og det er òg grunnen til at ein sky-VPN ikkje gir deg NAS-en: du flytta utgangen, ikkje LAN-et.
Du køyrer framleis gjestsystemet, VPN-tenesta og legitimasjonen medan leverandøren køyrer hypervisoren og det fysiske nettet, og den delinga tel når noko ryker klokka 2 om natta. Eit offentleg endepunkt blir skanna kontinuerleg, så hald administrasjonsporten lukka, tillat berre VPN-porten, og oppdater etter ein plan. Tryggingsgrupper og brannmurar hos leverandøren må tillate den porten, og nokre skyer kastar videresendt trafikk med mindre du justerer kjelde- og målkontrollen på instansen.
Ein liten instans dekkjer ein handfull klientar, men kryptering er CPU-arbeid, og ein burstable instans som går tom for kredittar oppfører seg ujamt under vedvarande last. Sjå på vegen du faktisk brukar, ikkje databladet.
Ei avgjerd du kan skrive ned
Oppgåva avgjer plasseringa, ikkje etiketten på boksen. Treng du ei eining på heime-LAN-et, er det billegaste riktige svaret eit endepunkt heime; ein skyboks verkar først etter at du har bygd lenkja tilbake. Treng du ein annan offentleg utgang, er svaret skyen og LAN-spørsmålet oppstår aldri. Å ville begge er legitimt, men det betyr to endepunkt, 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 |
Stadfest frå klienten i rekkjefølgje: handtrykk, peer-adresse, ein LAN-vert, deretter utgangs-IP-en. curl -s https://ifconfig.me viser kva internett ser, og ip route get 192.168.1.20 viser kva endepunktet trur. Når utgangssjekken består og NAS-sjekken heng, har du alt svaret om plasseringa; å justere AllowedIPs på klienten tryllar ikkje fram ei rute. Ei delt linje som 10.8.0.0/24, 192.168.1.0/24 held LAN-trafikk inne i tunnelen berre når den ruta faktisk finst.