Kan en roaming VPN-klient være vert for en tjeneste for kontoret?

Kontorbærbaren din kan ringe inn hjemmefra og likevel levere noe kontoret trenger, men bare når tre separate beslutninger klaffer. Tunnelen er transport, den indre adressen er målet, og policyen avgjør hvem som får banke på. Behandler du én av dem som hele svaret, får du den kjente klagen: verten svarer på ping, men applikasjonen kobler aldri til. Rollene er ikke de samme, og forskjellen er nøyaktig der designarbeidet ligger.

Innringingsretningen sier ingenting om tjenesteretningen

Når en klient starter en tunnel, åpner den en vei som begge retninger kan bruke når den først finnes. Om en ny tilkobling kan komme inn fra huben mot den klienten, er et spørsmål om gatewaypolicy, ikke en egenskap ved den som ringte inn. På en rutet OpenVPN-hub trenger serveren for eksempel en rute til klientens indre adresse og videresending som tillater peer-forholdet.

Se for deg et lagerstyringssystem som poller en agent på roamingbærbare, eller en utvikler som trenger et test-API fra en arbeidsstasjon hjemme. Begge vil at kontorsiden skal starte samtalen, som er det motsatte av det vanlige klient-til-server-mønsteret.

Hostede fjernaksessprodukter varierer her, og variasjonen er ikke en feil. Noen administrerte VPN-tjenester blokkerer bevisst uoppfordrede tilkoblinger mot tilkoblede klienter fordi modellen deres er klient-til-ressurs, ikke ressurs-til-klient. Les produktets dokumenterte arkitektur før du lover en kollega at bærbaren kan fungere som server.

Følg returveien før du åpner en port

Veien har tre deler: en rute på gatewayen som peker på klientens indre adresse, en policy som tillater den konkrete anroperen, og en lyttende tjeneste på målet. Hver del feiler forskjellig, derfor sier «VPN-et er oppe» nesten ingenting.

Den gode nyheten er at den indre veien ikke trenger port forwarding på klientens hjemmeruter. Det er poenget med å publisere tjenesten på tunneladressen i stedet for hjemmets WAN-adresse, der eksponeringen og NAT-reglene ville vært helt annerledes. En hjemmeruter kan også nekte å hairpinne en tilkobling som kommer fra kontoret, så WAN-ruten feiler av grunner som ikke har noe med VPN-et ditt å gjøre. Å holde trafikken inne i tunnelen unngår begge problemene på en gang.

Sjekk målsiden også. En tjeneste som bare er bundet til 127.0.0.1 kan ikke ta imot en tilkobling som ankommer på tunellgrensesnittet, uansett hvor riktige rutene på gatewayen er. En vertbrannmurregel som bare tillater porten fra det lokale subnettet vil også droppe kontortrafikk, og den regelen er uavhengig av VPN-policyen over den.

Navn og adresser er designbeslutninger

En adresse inne i tunnelen er ikke automatisk et navn. En privat DNS-post du kontrollerer er klarere enn å håpe at en oppdagelsesprotokoll krysser tunnelen, fordi link-local multicast-navneoppslag blir på det lokale segmentet og ikke blir DNS på tvers av subnett.

Adressestabilitet betyr like mye. Hvis VPN-klienter trekker fra en pool med korte leases, endres bærbarens indre adresse mellom økter, og hvert bokmerke, brannmur-område og overvåkingssjekk bygget på den brytes stille. Bruk en reservasjon eller en dokumentert dynamisk oppdateringsvei.

Avtal navnet med den som eier VPN-identiteten, slik at posten, adressetildelingen og tilgangspolicyen endres sammen i stedet for i tre separate saker.

Test tjenesten, ikke medlemskapet

Bekreft fra målet hva som lytter og på hvilken adresse, og bekreft deretter gatewayens syn på returveien:

$ 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 nå fra kontorsiden med en ekte forespørsel i stedet for et ekko. En vellykket curl mot tjenesten beviser ruten, policyen og lytteren på en gang, mens en vellykket ping bare beviser at ICMP er tillatt. Hvis forespørselen feiler, gå baklengs gjennom de tre delene i stedet for å utvide brannmuren og håpe.

Tilgjengelighet hører hjemme i samme samtale. En bærbar sover, roamer mellom nettverk og kobler fra ved dagens slutt. En tjeneste som må svare til enhver time hører hjemme på en alltid påslått vert, mens en best-effort-tjeneste kan bli på klienten med den begrensningen skrevet ned.

Publiser ressursen med vilje, med et navn, en liste over tillatte anrop og en eier, og fjernenheten blir en støttet tjeneste i stedet for en tilfeldig server.