Thús-VPN-tsjinner fersus wolktsjinner: hokker berikt dyn NAS?
De tunnel komt op, mar de thús-NAS bliuwt ûnberikber. Kies de lokaasje fan it einpunt op basis fan de boarne dy'tst berikke moatst, en kontrolearje dan de rûte.
De tunnel komt op, de klient toant in grien punt, en ssh 192.168.1.20 hinget noch oant de tiid ferrint. Dat oerkaam my krekt doe't ik in lytse wolkynstânsje hierde en WireGuard dêrop sette: handshake goed, DNS goed, en de NAS op myn buro like ûnberikber as op 'e moanne. Der wie neat mis mei de tunnel. It einpunt stie yn in netwurk sûnder rûte nei myn hûs. De lokaasje fan it einpunt beslút hokker netwurken neistlizzend binne, kies it dus op basis fan de boarne dy'tst earst berikke moatst en fergelykje hosting dêrnei.
In tunnel berikt allinnich netwurken dy't it einpunt routsje kin
In VPN jout dyn klient in adres binnen it eigen routingdomein fan it einpunt. As de klient in pakket nei 192.168.1.20 stjoert, moat it einpunt witte wêr't dat hinne giet. De tabel fan in wolk-VM ken de VPC-subnetten fan 'e provider; fan dyn LAN hat er nea heard. Ferbûn en berikber binne twa ferskillende feiten, en de measte betizing tusken thús en wolk komt troch it earste as bewiis foar it twadde te nimmen.
Ien opdracht besljochtet it. Op it einpunt, ip route get 192.168.1.20 neamt óf in LAN-ynterface óf wiist nei de standertrûte. Op in thúsboks is it antwurd de LAN-kant. Op in wolkynstânsje giet it pakket nei it ynternet en stjert. Oansette fan net.ipv4.ip_forward=1 en it tafoegjen fan in MASQUERADE-regel feroaret dat net, want der is neat om nei troch te stjoeren oant eat oan 'e thúskant in link nei de wolk beëiniget.
It thúsgefal hat in twadde helte: de weromrûte. Pakketten dy't it LAN troch de tunnelboks ferlitte, wurde NAT; of it LAN hat in statyske rûte werom nei it tunnelsubnet nedich. As mar ien rjochting wurket, kontrolearje sysctl net.ipv4.conf.all.rp_filter. Strange weromrûtefiltering smyt antwurden fuort dy't op in oar ynterface oankomme as de rûte foarseit, en it symptoom liket krekt op in firewallregel.
Lês it symptoom ear'tst de konfiguraasje oanrekest
Tunnel komt net op: kaaien, einpuntadres of in blokkearre UDP-poarte. Tunnel op mar LAN-hosts dea: pleatsing en routing. Tunnel op mar browsen dea: trochstjoere, NAT of DNS. Dat binne trije lagen en trije ferskillende kontrôles, en in al korrekte konfiguraasje oerskriuwe kostet in jûn.
| 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 |
Ynkommende berikberens fan thús fertsjinnet in eigen kontrôle, want it beslút oft hosting thús oait mooglik is. Fergelykje it WAN-adres dat dyn router rapportearret mei it adres dat in eksterne host sjocht. As it yn 100.64.0.0/10 falt, of de twa binne it net iens, sitst efter carrier-grade NAT en gjin poartetrochstjoering sil ea wurkje. De echte opsjes binne in relais, in wolklink dy't fan thús út nei bûten skillet, of it ferpleatsen fan it einpunt.
Wat hosting thús dy jout, en wat it kostet
Thús is de iennige pleatsing dy't standert binnen it LAN sit, en dat is de hiele reden om dêr in tsjinner te setten. Apparaten dy't allinnich op it lokale segmint antwurdzje, lykas printers en NAS-behearsiden dy't net-lokale subnetten wegerje, wurkje sûnder ekstra routing. Do bestjoerst ek sels de masine, de router en de uplink.
De kosten binne fysyk. Thús-upload is it plafond foar alle klienten tagelyk, dus in fideo-oprop en in backup konkurrearje om deselde piip. Stroom, skivefersliten, patches, in dynamysk adres dat DDNS nedich hat, in router dy't UDP nei binnen trochstjoere moat, en mooglik dûbele NAT falle allegear op dy. Wat minsken oerslaan is werstel: as de boks stjert wylstst fuort bist, stjert dyn iennige paad nei hûs mei. Hâld in twadde apparaat mei deselde kaaien, of teminsten in plan foar fysike tagong.
As je LAN-tagong wolle sûnder de boks thús, bou in link ynstee fan te dwaan as. It wolk-einpunt wurdt in router: in tunnel fan 'e thúskant mei AllowedIPs = 192.168.1.0/24 op 'e wolk-peer, plus trochstjoere en NAT op 'e wolkboks. De trochstjoergids fan strongSwan rint de weromhelte fan dy opset troch, en dêr mislearje de measte fan dizze besykens. De thús-peer moat no omheech wêze om eat wurkje te litten, dus do hast ien ôfhinklikens foar in oare ruile en moatst dat opskriuwe.
Dêr't in wolk-einpunt eins foar is
In wolk-einpunt feroaret dyn iepenbiere útgong. Ferkear ferlit it adresberik fan 'e provider, en siden sjogge dat adres ynstee fan dyn thúsadres. Dat is de wearde, en dêrom jout in wolk-VPN dy net de NAS: do hast de útgong ferpleatst, net it LAN.
Do draaist noch it gastsysteem, de VPN-tsjinst en har credits, wylst de provider de hypervisor en it fysike netwurk draait, en dy splitsing is wichtich as der om 2 oere nachts eat stikken giet. In iepenbier einpunt wurdt hieltyd skanne, hâld de behearspoarte dus ticht, stean allinnich de VPN-poarte ta en patch neffens in skema. Feiligensgroepen en firewalls fan 'e provider moatte dy poarte tastean, en guon wolken smite trochstjoerd ferkear fuort oantst de boarne- en bestimmingskontrôle op 'e ynstânsje oanpast.
In lytse ynstânsje dekt in hantsjefol klanten, mar fersifering is CPU-wurk, en in burstable ynstânsje dy't troch har krediten hinne is, hâldt him ûngelyk ûnder oanhâldende lêst. Sjoch nei it paad datst echt brûkst, net it spesifikaasjeblêd.
In beslút datst opskriuwe kinst
De taak beslút de pleatsing, net it label op 'e boks. Asst in apparaat op dyn thús-LAN nedich hast, is it goedkeapste goede antwurd in einpunt thús; in wolkboks wurket pas nei'tst de link werom boud hast. Asst in oare iepenbiere útgong nedich hast, is wolk it antwurd en de LAN-fraach komt nea op. Beide wolle is legit, mar it betsjut twa einpunten, twa sets kaaien en twa dokumintearre rûtes.
| 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 |
Kontrolearje fan 'e klient yn folchoarder: handshake, peer-adres, in LAN-host, dan de útgongs-IP. curl -s https://ifconfig.me lit sjen wat it ynternet sjocht, en ip route get 192.168.1.20 lit sjen wat it einpunt tinkt. As de útgongskontrôle slagget en de NAS-kontrôle hinget, hast dyn antwurd oer pleatsing al; AllowedIPs op 'e klient oanpasse sil gjin rûte towerje. In splitst rigel lykas 10.8.0.0/24, 192.168.1.0/24 hâldt LAN-ferkear allinnich yn 'e tunnel as dy rûte echt bestiet.