Die tonnel kom op, die kliënt wys ’n groen kol, en ssh 192.168.1.20 hang steeds tot dit uiteindelik ’n tydsverloop gee. Ek het dit presies beleef nadat ek ’n klein wolkinstans gehuur en WireGuard daarop gesit het: handskud in orde, DNS in orde, en die NAS op my lessenaar so onbereikbaar asof dit op die maan was. Niks was verkeerd met die tonnel nie. Die eindpunt was in ’n netwerk wat geen roete na my huis het nie. Die ligging van die eindpunt bepaal watter netwerke aangrensend is; kies dit dus volgens die hulpbron wat jy eerste moet bereik en vergelyk hosting tweede.

’n Tonnel bereik net netwerke wat die eindpunt kan roete

’n VPN gee jou kliënt ’n adres binne die eindpunt se eie roetendomein. Wanneer die kliënt ’n pakket na 192.168.1.20 stuur, moet die eindpunt weet waar dit heen gaan. ’n Wolk-VM se tabel ken die verskaffer se VPC-subnette; dit het nog nooit van jou LAN gehoor nie. Verbind en bereikbaar is twee verskillende feite, en die meeste verwarring tussen tuis en wolk kom daaruit dat die eerste as bewys van die tweede geneem word.

Een opdrag beslis dit. Op die eindpunt, ip route get 192.168.1.20 noem óf ’n LAN-koppelvlak óf wys na die verstekroete. Op ’n tuisboks is die antwoord die LAN-kant. Op ’n wolkinstans verlaat die pakket na die internet en sterf. Aanskakel van net.ipv4.ip_forward=1 en die toevoeging van ’n MASQUERADE-reël verander dit nie, want daar is niks om na aan te stuur totdat iets op die tuiskant ’n koppeling na die wolk beëindig nie.

Die tuisgeval het ’n tweede helfte: die terugroete. Pakkette wat die LAN deur die tonnelboks verlaat, word NAT-tol; of die LAN benodig ’n statiese roete terug na die tonnel-subnet. Wanneer net een rigting werk, kontroleer sysctl net.ipv4.conf.all.rp_filter. Streng terugroete-filtering verwerp antwoorde wat op ’n ander koppelvlak aankom as wat die roete voorspel, en die simptoom lyk presies soos ’n firewall-reël.

Lees die simptoom voordat jy aan die konfigurasie raak

Tonnel wat nie opkom nie: sleutels, eindpuntadres of ’n geblokkeerde UDP-poort. Tonnel op maar LAN-gashere dood: plasing en roetetoepassing. Tonnel op maar blaai dood: aanstuur, NAT of DNS. Dit is drie lae, drie verskillende kontrole, en ’n konfigurasie herskryf wat reeds korrek was, vermors ’n aand.

SymptomFirst suspectCheck
Handshake fails, no transferKeys, endpoint port, UDP blockedwg show, then the port from outside
Peer pings, LAN host times outNo route to the LANip route get on the endpoint
Tunnel up, name resolution failsDNS options in the peer configResolve a name from the client
Large transfers reset the connectionMTULower the tunnel MTU and retry

Tuis-inwaartse bereikbaarheid verdien sy eie kontrole, want dit bepaal of tuis-hosting hoegenaamd moontlik is. Vergelyk die WAN-adres wat jou router rapporteer met die adres wat ’n eksterne gasheer sien. As dit in 100.64.0.0/10 val, of die twee stem nie ooreen nie, is jy agter carrier-grade NAT en geen poortaanstuur sal ooit werk nie. Die werklike opsies is ’n aflos, ’n wolkkoppeling wat van die tuiskant uit inbel, of die verskuiwing van die eindpunt.

Wat tuis-hosting jou koop, en wat dit kos

Tuis is die enigste plasing wat standaard binne die LAN sit, en dit is die hele rede om ’n bediener daar te plaas. Toestelle wat net op die plaaslike segment antwoord, soos printers en NAS-bestuursblaaie wat nie-plaaslike subnette verwerp, werk sonder ekstra roetetoepassing. Jy bestuur ook self die masjien, die router en die opstroom.

Die koste is fisies. Tuis-oplaai is die plafon vir elke kliënt gelyk, so ’n videogesprek en ’n rugsteun ding meeding vir dieselfde buis. Krag, skyfverbrak, pleister, ’n dinamiese adres wat DDNS nodig het, ’n router wat UDP inwaarts moet aanstuur, en moontlik dubbele NAT val alles op jou. Die een wat mense mis, is herstel: as die boks sterf terwyl jy weg is, sterf jou enigste pad in die huis saam. Hou ’n tweede toestel met dieselfde sleutels, of ten minste ’n plan vir fisiese toegang.

As jy LAN-toegang wil hê sonder die boks by die huis, bou ’n koppeling eerder as om te voorgee. Die wolk-eindpunt word ’n router: ’n tonnel van die tuiskant met AllowedIPs = 192.168.1.0/24 op die wolk-ewenoot, plus aanstuur en NAT op die wolkboks. strongSwan se aanstuur-gids loop deur die terugroete-helfte van daardie opstel, en dis waar die meeste van hierdie pogings misluk. Die tuis-ewenoot moet nou op wees vir enigiets om te werk, so jy het een afhanklikheid vir ’n ander verhandel en moet dit opskryf.

Waarvoor ’n wolk-eindpunt eintlik is

’n Wolk-eindpunt verander jou openbare uitgang. Verkeer verlaat die verskaffer se adresreeks, en werwe sien daardie adres eerder as jou tuisadres. Dit is die waarde, en dit is ook waarom ’n wolk-VPN nie die NAS vir jou gee nie: jy het die uitgang verskuif, nie die LAN nie.

Jy bestuur steeds die gasstelsel, die VPN-diens en sy geloofsbriewe terwyl die verskaffer die hipervisor en die fisiese netwerk bestuur, en die verdeling maak saak wanneer iets om 2 uur in die oggend breek. ’n Openbare eindpunt word voortdurend geskandeer, so hou die bestuursport toe, laat net die VPN-poort toe, en pleister volgens ’n skedule. Sekuriteitsgroepe en verskaffer-firewalls moet daardie poort toelaat, en sommige wolke laat aangestuurde verkeer val tens jy nie bron- en bestemmingskontrole op die instans aanpas nie.

’n Klein instans dek ’n handvol kliënte, maar enkripsie is CPU-werk, en ’n burstable instans wat krediete opgebruik, gedra hom ongelyk onder volgehoue las. Kyk na die pad wat jy werklik gebruik eerder as die spesifikasieblad.

’n Besluit wat jy kan opskryf

Die taak bepaal die plasing, nie die etiket op die boks nie. As jy ’n toestel op jou tuis-LAN nodig het, is die goedkoopste korrekte antwoord ’n eindpunt by die huis; ’n wolkboks werk net nadat jy die koppeling terug gebou het. As jy ’n ander openbare uitgang nodig het, is wolk die antwoord en die LAN-vraag kom nooit op nie. Om albei te wil hê is wettig, maar dit beteken twee eindpunte, twee stelle sleutels en twee gedokumenteerde roetes.

What you needEndpoint locationWhat else must exist
Reach a NAS or printer on the home LANA box on that LANPort forward or relay, DDNS, recovery plan
Browse from an exit unrelated to homeCloud instanceFirewall and egress rules, patching
Both, reliablyTwo endpoints, or cloud plus a link homeSeparate keys, routes, documented failure modes

Verifieer van die kliënt in volgorde: handskud, eweknie-adres, ’n LAN-gasheer, dan die uitgangs-IP. curl -s https://ifconfig.me wys wat die internet sien, en ip route get 192.168.1.20 wys wat die eindpunt glo. Wanneer die uitgangskontrole slaag en die NAS-kontrole hang, het jy reeds jou antwoord oor die plasing; die aanpassing van AllowedIPs op die kliënt sal nie ’n roete toor nie. ’n Gesplete reël soos 10.8.0.0/24, 192.168.1.0/24 hou LAN-verkeer net binne die tonnel sodra daardie roete werklik bestaan.

Verwante artikels