Kan een rondzwervende VPN-client een dienst voor het kantoor hosten?

Je kantoorlaptop kan van huis uit inbellen en toch iets leveren wat het kantoor nodig heeft, maar alleen wanneer drie afzonderlijke beslissingen samenvallen. De tunnel is transport, het interne adres is de bestemming, en beleid bepaalt wie mag kloppen. Als je een van die drie als het hele antwoord behandelt, krijg je de bekende klacht: de host antwoordt op pings maar de applicatie maakt nooit verbinding. De rollen zijn niet hetzelfde, en het verschil zit precies daar waar het ontwerpwerk ligt.

De inbelrichting zegt niets over de dienstrichting

Wanneer een client een tunnel start, opent hij een pad dat beide richtingen kunnen gebruiken zodra het bestaat. Of een nieuwe verbinding van de hub naar die client mag binnenkomen, is een kwestie van gatewaybeleid, niet een eigenschap van wie heeft ingebeld. Op een gerouteerde OpenVPN-hub heeft de server bijvoorbeeld een route naar het interne adres van de client nodig en doorsturing die de peer-relatie toestaat.

Stel je een voorraadsysteem voor dat een agent op rondzwervende laptops pollt, of een ontwikkelaar die een test-API nodig heeft vanaf een werkstation thuis. Beide willen dat de kantoorzijde het gesprek begint, wat het omgekeerde is van het gebruikelijke client-naar-server-patroon.

Gehoste remote-accessproducten verschillen hierin, en die variatie is geen bug. Sommige beheerde VPN-diensten blokkeren bewust ongevraagde verbindingen naar verbonden clients, omdat hun model client-naar-bron is, niet bron-naar-client. Lees de gedocumenteerde architectuur van het product voordat je een collega belooft dat zijn laptop als server kan dienen.

Volg het retourpad voordat je een poort opent

Het pad heeft drie delen: een route op de gateway die naar het interne adres van de client wijst, beleid dat de specifieke aanroeper toestaat, en een luisterende dienst op het doel. Elk deel faalt anders, daarom zegt «de VPN staat aan» bijna niets.

Het goede nieuws is dat het interne pad geen port forwarding op de thuisrouter van de client nodig heeft. Dat is precies het punt van de dienst publiceren op het tunneladres in plaats van op het thuis-WAN-adres, waar de blootstelling en de NAT-regels heel anders zouden zijn. Een thuisrouter kan ook weigeren een verbinding van kantoor te hairpinnen, waardoor de WAN-route faalt om redenen die niets met je VPN te maken hebben. Het verkeer binnen de tunnel houden vermijdt beide problemen tegelijk.

Controleer ook de doelserver. Een dienst die alleen aan 127.0.0.1 is gebonden, kan geen verbinding accepteren die op de tunnelinterface binnenkomt, hoe correct de routes van de gateway ook zijn. Een host-firewallregel die de poort alleen vanaf het lokale subnet toestaat, gooit ook kantoorverkeer weg, en die regel staat los van het VPN-beleid erboven.

Namen en adressen zijn ontwerpbeslissingen

Een adres binnen de tunnel is niet automatisch een naam. Een privé-DNS-record dat je beheert is duidelijker dan hopen dat een detectieprotocol de tunnel oversteekt, omdat link-local multicast-naamresolutie op het lokale segment blijft en geen DNS tussen subnetten wordt.

Adresstabiliteit is even belangrijk. Als VPN-clients uit een pool met korte leases putten, verandert het interne adres van de laptop tussen sessies en elk bladwijzer, firewallbereik en monitoringcontrole die daarop is gebouwd, breekt stil. Gebruik een reservering of een gedocumenteerd dynamisch updatepad.

Stem de naam af met wie de VPN-identiteit bezit, zodat het record, de adrestoewijzing en het toegangsbeleid samen veranderen in plaats van in drie aparte tickets.

Test de dienst, niet het lidmaatschap

Bevestig vanaf het doel wat er luistert en op welk adres, bevestig daarna de kijk van de gateway op het retourpad:

$ 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

Test nu vanaf de kantoorzijde met een echt verzoek in plaats van een echo. Een geslaagde curl tegen de dienst bewijst de route, het beleid en de luisteraar tegelijk, terwijl een geslaagde ping alleen bewijst dat ICMP is toegestaan. Als het verzoek faalt, werk dan achteruit door de drie delen in plaats van de firewall te verbreden en te hopen.

Beschikbaarheid hoort in hetzelfde gesprek. Een laptop slaapt, zwerft tussen netwerken en verbreekt aan het eind van de dag. Een dienst die op elk uur moet antwoorden, hoort op een altijd aanstaande host, terwijl een best-effortdienst bij de client kan blijven met die beperking opgeschreven.

Publiceer de bron bewust, met een naam, een lijst toegestane bellers en een eigenaar, en het externe apparaat wordt een ondersteunde dienst in plaats van een toevallige server.