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

Din kontorbærbare kan ringe ind hjemmefra og stadig levere noget, kontoret har brug for, men kun når tre separate beslutninger falder på plads. Tunnelen er transport, den indre adresse er destinationen, og politikken afgør, hvem der må banke på. Behandler du en af dem som hele svaret, får du den velkendte klage: værten svarer på ping, men applikationen opretter aldrig forbindelse. Rollerne er ikke de samme, og forskellen er præcis der, hvor designarbejdet ligger.

Indkaldsretningen siger intet om tjenesteretningen

Når en klient starter en tunnel, åbner den en vej, som begge retninger kan bruge, når den først findes. Om en ny forbindelse må komme ind fra hubben mod den klient, er et spørgsmål om gatewaypolitik, ikke en egenskab ved den, der ringede ind. På en routed OpenVPN-hub har serveren for eksempel brug for en rute til klientens indre adresse og videresendelse, der tillader peer-forholdet.

Forestil dig et lagerstyringssystem, der poller en agent på roamingbærbare, eller en udvikler, der har brug for et test-API fra en arbejdsstation derhjemme. Begge vil have kontorsiden til at starte samtalen, hvilket er det modsatte af det sædvanlige klient-til-server-mønster.

Hostede fjernadgangsprodukter varierer her, og variationen er ikke en fejl. Nogle administrerede VPN-tjenester blokerer bevidst uopfordrede forbindelser mod tilsluttede klienter, fordi deres model er klient-til-ressource, ikke ressource-til-klient. Læs produktets dokumenterede arkitektur, før du lover en kollega, at deres bærbare kan fungere som server.

Følg returvejen, før du åbner en port

Vejen har tre dele: en rute på gatewayen, der peger på klientens indre adresse, en politik der tillader den specifikke kalder, og en lyttende tjeneste på målet. Hver del fejler forskelligt, og derfor siger «VPN'et er oppe» næsten intet.

Den gode nyhed er, at den indre vej ikke kræver portforwarding på klientens hjemmerouter. Det er hele pointen med at udgive tjenesten på tunneladressen i stedet for på hjemmets WAN-adresse, hvor eksponeringen og NAT-reglerne ville være helt anderledes. En hjemmerouter kan også nægte at hairpinne en forbindelse, der kommer fra kontoret, så WAN-ruten fejler af grunde, der intet har med din VPN at gøre. At holde trafikken inde i tunnelen undgår begge problemer på én gang.

Kontroller også målsiden. En tjeneste, der kun er bundet til 127.0.0.1, kan ikke acceptere en forbindelse, der ankommer på tunnelinterfacet, uanset hvor korrekte gatewayens ruter er. En værtsfirewallregel, der kun tillader porten fra det lokale undernet, vil også droppe kontortrafik, og den regel er uafhængig af VPN-politikken ovenover.

Navne og adresser er designbeslutninger

En adresse inde i tunnelen er ikke automatisk et navn. En privat DNS-post, du kontrollerer, er klarere end at håbe på, at en opdagelsesprotokol krydser tunnelen, fordi link-local multicast-navneopløsning bliver på det lokale segment og ikke bliver DNS på tværs af undernet.

Adressestabilitet betyder lige så meget. Hvis VPN-klienter trækker fra en pulje med korte leases, ændrer den bærbares indre adresse sig mellem sessioner, og hvert bogmærke, firewallomfang og overvågningscheck bygget på den går stille i stykker. Brug en reservation eller en dokumenteret dynamisk opdateringsvej.

Aftal navnet med den, der ejer VPN-identiteten, så posten, adressetildelingen og adgangspolitikken ændres sammen i stedet for i tre separate sager.

Test tjenesten, ikke medlemskabet

Bekræft fra målet, hvad der lytter, og på hvilken adresse, og bekræft derefter gatewayens syn på returvejen:

$ 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 fra kontorsiden med en rigtig anmodning i stedet for et ekko. Et vellykket curl mod tjenesten beviser ruten, politikken og lytteren på én gang, mens et vellykket ping kun beviser, at ICMP er tilladt. Hvis anmodningen fejler, gå baglæns gennem de tre dele i stedet for at udvide firewallen og håbe.

Tilgængelighed hører til i samme samtale. En bærbar sover, roamer mellem netværk og afbryder ved arbejdsdagens slutning. En tjeneste, der skal svare på ethvert tidspunkt, hører på en altid tændt vært, mens en best-effort-tjeneste kan blive på klienten med den begrænsning skrevet ned.

Udgiv ressourcen bevidst — med et navn, en liste over tilladte kaldere og en ejer — og fjernenheden bliver en understøttet tjeneste i stedet for en tilfældig server.