Pode un cliente VPN itinerante aloxar un servizo para a oficina?

O portátil da oficina pode conectarse desde casa e aínda así ofrecer algo que a oficina necesita, pero só cando coinciden tres decisións separadas. O túnel é transporte, o enderezo interno é o destino e a política decide quen pode chamar. Tratar calquera delas como a resposta completa produce a queixa coñecida: o host responde aos pings pero a aplicación nunca se conecta. Os papeis non son iguais, e a diferenza está exactamente onde vive o traballo de deseño.

A dirección da conexión non di nada sobre a dirección do servizo

Cando un cliente inicia un túnel, abre un camiño que ambas as direccións poden usar unha vez que existe. Se unha conexión nova pode entrar desde o concentrador cara a ese cliente é unha cuestión de política da pasarela, non unha propiedade de quen se conectou. Nun concentrador OpenVPN encamiñado, por exemplo, o servidor necesita unha ruta cara ao enderezo interno do cliente e un reenvío que permita a relación entre pares.

Imaxina un sistema de inventario que consulta un axente en portátiles itinerantes, ou un desenvolvedor que necesita unha API de proba desde unha estación de traballo na casa. Ambos queren que o lado da oficina inicie a conversa, que é o contrario do patrón habitual cliente-servidor.

Os produtos de acceso remoto aloxados varían neste punto, e a variación non é un erro. Algunhas VPN de servizo xestionado bloquean deliberadamente as conexións non solicitadas cara aos clientes conectados porque o seu modelo é cliente-a-recurso, non recurso-a-cliente. Le a arquitectura documentada do produto antes de prometer a un colega que o seu portátil pode actuar como servidor.

Segue o camiño de volta antes de abrir un porto

O camiño ten tres partes: unha ruta na pasarela que apunta ao enderezo interno do cliente, unha política que permite o solicitante concreto e un servizo que escoita no obxectivo. Cada parte falla de forma distinta, por iso «a VPN está activa» case non di nada.

A boa nova é que o camiño interno non necesita unha redirección de porto no router da casa do cliente. Ese é o sentido de publicar o servizo no enderezo do túnel en lugar do enderezo WAN da casa, onde a exposición e as regras NAT serían completamente distintas. Un router doméstico tamén pode negarse a facer hairpin dunha conexión que chega da oficina, así que a ruta WAN falla por motivos alleos á túa VPN. Manter o tráfico dentro do túnel evita os dous problemas á vez.

Comproba tamén o lado do obxectivo. Un servizo ligado só a 127.0.0.1 non pode aceptar unha conexión que chegue pola interface do túnel, por correctas que sexan as rutas da pasarela. Unha regra de devasas do host que permita o porto só desde a subrede local tamén descartará o tráfico da oficina, e esa regra é independente da política VPN que hai por riba.

Os nomes e os enderezos son decisións de deseño

Un enderezo dentro do túnel non é automaticamente un nome. Un rexistro DNS privado que controlas é máis claro que esperar que un protocolo de descuberta cruce o túnel, porque a resolución de nomes por multicast de enlace local queda no segmento local e non se converte en DNS entre subredes.

A estabilidade do enderezo importa igual. Se os clientes VPN toman enderezos dun grupo con concesións curtas, o enderezo interno do portátil cambia entre sesións e cada marcador, ámbito de devasas e comprobación de monitorización construídos sobre el rompen en silencio. Usa unha reserva ou un camiño documentado de actualización dinámica.

Acorda o nome con quen posúe a identidade VPN, para que o rexistro, a asignación de enderezo e a política de acceso cambien xuntos en lugar de en tres tíckets separados.

Proba o servizo, non a pertenza

Desde o obxectivo, confirma que escoita e en que enderezo, e despois confirma a visión da pasarela do camiño de volta:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Agora proba desde o lado da oficina cunha petición real en lugar dun eco. Un curl correcto contra o servizo demostra a ruta, a política e o oínte á vez, mentres que un ping correcto só demostra que se permite ICMP. Se a petición falla, retrocede polas tres partes en lugar de ampliar as devasas e esperar.

A dispoñibilidade pertence á mesma conversa. Un portátil dorme, itinerante entre redes e desconéctase ao final do día. Un servizo que debe responder a calquera hora pertence a un host sempre acendido, mentres que un servizo de mellor esforzo pode quedar no cliente con esa limitación escrita.

Publica o recurso deliberadamente, cun nome, unha lista de solicitantes permitidos e un propietario, e o dispositivo remoto convértese nun servizo compatíbel en lugar dun servidor accidental.