Servidor VPN doméstico fronte a servidor na nube: cal chega ao teu NAS?
O túnel levanta, pero o NAS da casa segue inaccesible. Escolle a localización do extremo polo recurso que debes tocar e despois comproba a ruta.
O túnel levanta, o cliente mostra un punto verde e ssh 192.168.1.20 segue colgado ata esgotar o tempo. Pasoume exactamente iso tras alugar unha instancia pequena na nube e poñer WireGuard nela: handshake correcto, DNS correcto e o NAS do meu escritorio tan inaccesible coma se estivese na lúa. O túnel non tiña nada malo. O extremo estaba aparcado nunha rede sen ruta cara á miña casa. A localización do extremo decide que redes son adxacentes, así que escóllea polo recurso que debes tocar primeiro e compara o aloxamento despois.
Un túnel só chega ás redes que o extremo pode encamiñar
Unha VPN dálle ao teu cliente un enderezo dentro do dominio de encamiñamento do propio extremo. Cando o cliente envía un paquete a 192.168.1.20, o extremo ten que saber a onde vai. A táboa dunha VM na nube coñece as subredes VPC do provedor; nunca oíu falar da túa LAN. Conectado e accesible son dous feitos distintos, e case toda a confusión entre casa e nube vén de tomar o primeiro como proba do segundo.
Un comando resólveo. No extremo, ip route get 192.168.1.20 ou nomea unha interface LAN ou apunta á ruta por defecto. Nun equipo de casa a resposta é o lado LAN. Nunha instancia na nube o paquete sae cara a internet e morre. Activar net.ipv4.ip_forward=1 e engadir unha regra MASQUERADE non o cambia, porque non hai nada a onde reenviar ata que algo do lado da casa remate unha ligazón cara á nube.
O caso doméstico ten unha segunda metade: o camiño de volta. Os paquetes que saen da LAN polo equipo do túnel pasan por NAT, ou a LAN necesita unha ruta estática de volta á subrede do túnel. Cando só funciona unha dirección, comproba sysctl net.ipv4.conf.all.rp_filter. O filtrado estrito de ruta inversa descarta as respostas que chegan por unha interface distinta da que predí a ruta, e o síntoma parece exactamente unha regra de cortafuegos.
Le o síntoma antes de tocar a configuración
O túnel non se establece: chaves, enderezo do extremo ou un porto UDP bloqueado. Túnel arriba pero equipos da LAN mortos: localización e encamiñamento. Túnel arriba pero navegación morta: reenvío, NAT ou DNS. Son tres capas e tres comprobacións distintas, e reescribir unha configuración que xa era correcta desperdicia unha noite.
| 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 |
A accesibilidade entrante da casa merece a súa propia comprobación, porque decide se o aloxamento na casa é posible. Compara o enderezo WAN que informa o teu router co que ve un equipo externo. Se cae en 100.64.0.0/10, ou os dous non coinciden, estás detrás de NAT de operador e ningunha redirección de porto funcionará nunca. As opcións reais son un relé, unha ligazón na nube que marca cara a fóra desde casa, ou mover o extremo.
Que che compra o aloxamento na casa e que custa
Casa é a única localización que está dentro da LAN por defecto, e esa é toda a razón para poñer alí un servidor. Os dispositivos que só responden no segmento local, como impresoras e páxinas de administración do NAS que rexeitan subredes non locais, funcionan sen encamiñamento extra. Tamén operas ti mesmo a máquina, o router e a ligazón.
Os custos son físicos. A subida da casa é o teito para todos os clientes á vez, así que unha videollamada e unha copia de seguridade compiten pola mesma tubaxe. Electricidade, desgaste do disco, parches, un enderezo dinámico que necesita DDNS, un router que debe reenviar UDP cara a dentro e posiblemente NAT dobre: todo cae sobre ti. O que a xente omite é a recuperación: se o equipo morre mentres estás fóra, a túa única vía á casa tamén morre. Ten un segundo dispositivo coas mesmas chaves, ou polo menos un plan de acceso físico.
Se queres acceso á LAN sen o equipo na casa, constrúe unha ligazón en lugar de finxir. O extremo na nube convértese nun router: un túnel desde o lado da casa con AllowedIPs = 192.168.1.0/24 no peer da nube, máis reenvío e NAT no equipo da nube. A guía de reenvío de strongSwan percorre a metade de volta desa configuración, e aí fallan a maioría destes intentos. Agora o peer da casa ten que estar arriba para que algo funcione, así que trocaches unha dependencia por outra e deberías anotalo.
Para que serve realmente un extremo na nube
Un extremo na nube cambia a túa saída pública. O tráfico sae do rango de enderezos do provedor, e os sitios ven ese enderezo en lugar do da casa. Ese é o valor, e tamén é por iso que unha VPN na nube non che dá o NAS: moviches a saída, non a LAN.
Segues executando o sistema convidado, o servizo VPN e as súas credenciais mentres o provedor executa o hipervisor e a rede física, e esa división importa cando algo falla ás 2 da madrugada. Un extremo público escanéase de forma continua, así que mantén pechado o porto de xestión, permite só o porto VPN e aplica parches segundo un calendario. Os grupos de seguridade e os cortafuegos do provedor deben permitir ese porto, e algunhas nubes descartan o tráfico reenviado salvo que axustes a comprobación de orixe e destino na instancia.
Unha instancia pequena cobre un puñado de clientes, pero o cifrado é traballo de CPU, e unha instancia burstable que esgota os créditos compórtase de forma irregular baixo carga sostida. Mira o camiño que usas de verdade, non a folla de especificacións.
Unha decisión que podes escribir
A tarefa decide a localización, non a etiqueta do equipo. Se necesitas un dispositivo na túa LAN de casa, a resposta correcta máis barata é un extremo na casa; un equipo na nube só funciona despois de construír a ligazón de volta. Se necesitas outra saída pública, a resposta é a nube e a cuestión da LAN nunca aparece. Querer ambas é lexítimo, pero significa dous extremos, dous xogos de chaves e dúas rutas documentadas.
| 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 |
Verifica desde o cliente en orde: handshake, enderezo do peer, un equipo da LAN e despois a IP de saída. curl -s https://ifconfig.me mostra o que ve internet, e ip route get 192.168.1.20 mostra o que cre o extremo. Cando a comprobación de saída pasa e a do NAS colga, xa tes a túa resposta sobre a localización; axustar AllowedIPs no cliente non fará aparecer unha ruta. Unha liña dividida como 10.8.0.0/24, 192.168.1.0/24 só mantén o tráfico da LAN dentro do túnel cando esa ruta existe de verdade.