Servidor VPN domèstic contra servidor al núvol: quin arriba al teu NAS?
El túnel s’aixeca, però el NAS de casa continua inaccessible. Trieu la ubicació de l’extrem per l’element que heu de tocar i després comproveu la ruta.
El túnel s’aixeca, el client mostra un punt verd i ssh 192.168.1.20 encara penja fins que expira. Em va passar exactament això després de llogar una petita instància al núvol i posar-hi WireGuard: encaixada correcta, DNS correcte i el NAS del meu escriptori tan inaccessible com si fos a la lluna. El túnel no tenia cap defecte. L’extrem estava aparcat en una xarxa sense ruta cap a casa meva. La ubicació de l’extrem decideix quines xarxes són adjacents, així que trieu-la per l’element que heu de tocar primer i compareu l’allotjament després.
Un túnel només arriba a les xarxes que l’extrem pot encaminar
Una VPN dóna al vostre client una adreça dins del domini d’encaminament de l’extrem. Quan el client envia un paquet a 192.168.1.20, l’extrem ha de saber on va. La taula d’una VM al núvol coneix les subxarxes VPC del proveïdor; mai ha sentit a parlar de la vostra LAN. Connectat i accessible són dos fets diferents, i la major part de la confusió entre casa i núvol ve de prendre el primer com a prova del segon.
Una ordre ho resol. A l’extrem, ip route get 192.168.1.20 o bé nomena una interfície LAN o bé apunta a la ruta per defecte. En un equip de casa la resposta és la banda LAN. En una instància al núvol el paquet surt cap a internet i mor. Encendre net.ipv4.ip_forward=1 i afegir una regla MASQUERADE no ho canvia, perquè no hi ha res on reenviar fins que alguna cosa de la banda de casa acabi un enllaç cap al núvol.
El cas domèstic té una segona meitat: el camí de tornada. Els paquets que surten de la LAN per l’equip del túnel passen per NAT, o la LAN necessita una ruta estàtica de tornada a la subxarxa del túnel. Quan només funciona una direcció, comproveu sysctl net.ipv4.conf.all.rp_filter. El filtratge estricte del camí invers descarta les respostes que arriben per una interfície diferent de la que prediu la ruta, i el símptoma sembla exactament una regla de tallafoc.
Llegiu el símptoma abans de tocar la configuració
El túnel no s’estableix: claus, adreça de l’extrem o un port UDP bloquejat. El túnel puja però els equips de la LAN són morts: ubicació i encaminament. El túnel puja però la navegació és morta: reenviament, NAT o DNS. Són tres capes i tres comprovacions diferents, i reescriure una configuració que ja era correcta malgasta un vespre.
| 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 |
L’accessibilitat entrant de casa mereix una comprovació pròpia, perquè decideix si l’allotjament a casa és possible. Compareu l’adreça WAN que informa el router amb l’adreça que veu un equip extern. Si cau dins 100.64.0.0/10, o les dues no coincideixen, esteu darrere NAT de proveïdor i cap redirecció de port funcionarà mai. Les opcions reals són un relé, un enllaç al núvol que truca cap enfora des de casa, o moure l’extrem.
Què us compra l’allotjament a casa i què costa
Casa és l’única ubicació que per defecte és dins de la LAN, i aquesta és tota la raó de posar-hi un servidor. Els dispositius que només responen al segment local, com impressores i pàgines d’administració del NAS que rebutgen subxarxes no locals, funcionen sense encaminament extra. També opereu vosaltres la màquina, el router i l’enllaç.
Els costos són físics. La pujada de casa és el sostre per a tots els clients alhora, així que una videotrucada i una còpia de seguretat competeixen pel mateix tub. Electricitat, desgast del disc, pedaços, una adreça dinàmica que necessita DDNS, un router que ha de reenviar UDP cap a dins i possiblement NAT doble: tot cau sobre vosaltres. El que la gent omet és la recuperació: si l’equip mor mentre sou fora, el vostre únic camí a casa mor amb ell. Tingueu un segon dispositiu amb les mateixes claus, o almenys un pla d’accés físic.
Si voleu accés a la LAN sense l’equip a casa, construïu un enllaç en lloc de fer veure. L’extrem al núvol es converteix en router: un túnel des de la banda de casa amb AllowedIPs = 192.168.1.0/24 al peer del núvol, més reenviament i NAT a l’equip del núvol. La guia de reenviament de strongSwan recorre la meitat de tornada d’aquesta configuració, i és on fallen la majoria d’aquests intents. Ara el peer de casa ha d’estar aixecat perquè res funcioni, així que heu canviat una dependència per una altra i ho hauríeu d’anotar.
Per a què serveix de fet un extrem al núvol
Un extrem al núvol canvia la vostra sortida pública. El trànsit surt del rang d’adreces del proveïdor, i els llocs veuen aquesta adreça en lloc de la de casa. Aquest és el valor, i també és per què una VPN al núvol no us dóna el NAS: heu mogut la sortida, no la LAN.
Encara executeu el sistema convidat, el servei VPN i les seves credencials mentre el proveïdor executa l’hipervisor i la xarxa física, i aquesta divisió importa quan alguna cosa falla a les 2 de la matinada. Un extrem públic s’escaneja contínuament, així que manteniu el port de gestió tancat, permeta només el port VPN i pedaceu segons un calendari. Els grups de seguretat i els tallafocs del proveïdor han de permetre aquest port, i alguns núvols descarten el trànsit reenviat tret que ajusteu la comprovació d’origen i destinació a la instància.
Una instància petita cobreix un grapat de clients, però el xifratge és feina de CPU, i una instància burstable que esgota els crèdits es comporta de manera irregular sota càrrega sostinguda. Mireu el camí que feu servir de debò, no el full d’especificacions.
Una decisió que podeu anotar
La tasca decideix la ubicació, no l’etiqueta de l’equip. Si necessiteu un dispositiu a la LAN de casa, la resposta correcta més barata és un extrem a casa; un equip al núvol només funciona després de construir l’enllaç de tornada. Si necessiteu una sortida pública diferent, la resposta és el núvol i la qüestió de la LAN no apareix. Voler totes dues és legítim, però vol dir dos extrems, dos jocs de claus i dues rutes documentades.
| 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 |
Verifiqueu des del client en ordre: encaixada, adreça del peer, un equip de la LAN, després la IP de sortida. curl -s https://ifconfig.me mostra què veu internet, i ip route get 192.168.1.20 mostra què creu l’extrem. Quan la comprovació de sortida passa i la del NAS penja, ja teniu la resposta sobre la ubicació; ajustar AllowedIPs al client no farà aparèixer cap ruta. Una línia dividida com 10.8.0.0/24, 192.168.1.0/24 només manté el trànsit de la LAN dins del túnel quan aquesta ruta existeix de debò.