Pot un client VPN itinerant allotjar un servei per a l'oficina?

El portàtil de l'oficina es pot connectar des de casa i encara oferir alguna cosa que l'oficina necessita, però només quan coincideixen tres decisions separades. El túnel és transport, l'adreça interna és la destinació i la política decideix qui pot trucar. Si tractes qualsevol d'aquestes com la resposta sencera, obtens la queixa coneguda: l'amfitrió respon als pings però l'aplicació no es connecta mai. Els papers no són els mateixos, i la diferència és exactament on viu la feina de disseny.

La direcció de la connexió no diu res sobre la direcció del servei

Quan un client inicia un túnel, obre un camí que totes dues direccions poden utilitzar un cop existeix. Si una connexió nova pot entrar des del concentrador cap a aquest client és una qüestió de política de la passarel·la, no una propietat de qui s'ha connectat. En un concentrador OpenVPN encaminat, per exemple, el servidor necessita una ruta cap a l'adreça interna del client i un reenviament que permeti la relació d'igual a igual.

Imagina un sistema d'inventari que consulta un agent en portàtils itinerants, o un desenvolupador que necessita una API de prova des d'una estació de treball a casa. Tots dos volen que el costat de l'oficina iniciï la conversa, que és el revés del patró habitual client-a-servidor.

Els productes d'accés remot allotjats varien en aquest punt, i la variació no és un error. Alguns VPN de servei gestionat bloquegen deliberadament les connexions no sol·licitades cap als clients connectats perquè el seu model és client-a-recurs, no recurs-a-client. Llegeix l'arquitectura documentada del producte abans de prometre a un company que el seu portàtil pot fer de servidor.

Segueix el camí de resposta abans d'obrir un port

El camí té tres parts: una ruta a la passarel·la que apunta a l'adreça interna del client, una política que permet el sol·licitant concret i un servei que escolta a l'objectiu. Cada part falla de manera diferent, i per això «la VPN està activa» gairebé no diu res.

La bona notícia és que el camí intern no necessita una redirecció de port al router de casa del client. Aquest és el sentit de publicar el servei a l'adreça del túnel en lloc de l'adreça WAN de casa, on l'exposició i les regles NAT serien completament diferents. Un router domèstic també pot negar-se a fer hairpin d'una connexió que arriba de l'oficina, així que la ruta WAN falla per motius aliens a la teva VPN. Mantenir el trànsit dins del túnel evita tots dos problemes alhora.

Comprova també el costat de l'objectiu. Un servei lligat només a 127.0.0.1 no pot acceptar una connexió que arribi per la interfície del túnel, per correctes que siguin les rutes de la passarel·la. Una regla de tallafoc de l'amfitrió que permeti el port només des de la subxarxa local també descartarà el trànsit de l'oficina, i aquesta regla és independent de la política VPN que hi ha a sobre.

Els noms i les adreces són decisions de disseny

Una adreça dins del túnel no és automàticament un nom. Un registre DNS privat que controles és més clar que esperar que un protocol de descobriment travessi el túnel, perquè la resolució de noms per multicast d'enllaç local es queda al segment local i no es converteix en DNS entre subxarxes.

L'estabilitat de l'adreça importa igualment. Si els clients VPN treuen adreces d'un pool amb concessions curtes, l'adreça interna del portàtil canvia entre sessions i cada marcador, abast de tallafoc i comprovació de monitoratge construïts sobre ella es trenquen en silenci. Fes servir una reserva o un camí documentat d'actualització dinàmica.

Acorda el nom amb qui posseeix la identitat VPN, perquè el registre, l'assignació d'adreça i la política d'accés canviïn junts en lloc de en tres tiquets separats.

Prova el servei, no la pertinença

Des de l'objectiu, confirma què escolta i en quina adreça, i després confirma la visió de la passarel·la del camí de tornada:

$ 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

Ara prova des del costat de l'oficina amb una petició real en lloc d'un eco. Un curl correcte contra el servei demostra la ruta, la política i l'oient alhora, mentre que un ping correcte només demostra que l'ICMP està permès. Si la petició falla, retrocedeix per les tres parts en lloc d'ampliar el tallafoc i esperar.

La disponibilitat pertany a la mateixa conversa. Un portàtil dorm, itinerant entre xarxes i es desconnecta al final del dia. Un servei que ha de respondre a qualsevol hora pertany a un amfitrió sempre encès, mentre que un servei de millor esforç pot quedar-se al client amb aquesta limitació escrita.

Publica el recurs deliberadament — amb un nom, una llista de sol·licitants permesos i un propietari — i el dispositiu remot es converteix en un servei suportat en lloc d'un servidor accidental.