Kan ein roaming VPN-klient vera vert for ei teneste for kontoret?

Kontorberbare din kan ringje inn heimanfrå og likevel levere noko kontoret treng, men berre når tre separate avgjerder klaffar. Tunnelen er transport, den indre adressa er målet, og policyen avgjer kven som får banke på. Behandlar du éin av dei som heile svaret, får du den kjende klaga: verten svarar på ping, men applikasjonen koplar aldri til. Rollene er ikkje dei same, og skilnaden er nett der designarbeidet ligg.

Innringingsretninga seier ingenting om tenesteretninga

Når ein klient startar ein tunnel, opnar han ein veg som begge retningar kan bruke når han først finst. Om ei ny tilkopling kan kome inn frå huben mot den klienten, er eit spørsmål om gatewaypolicy, ikkje ein eigenskap ved den som ringde inn. På ein ruta OpenVPN-hub treng tenaren til dømes ei rute til den indre adressa til klienten og vidaresending som tillèt peer-tilhøvet.

Sjå føre deg eit lagersystem som pollar ein agent på roamingberbare, eller ein utviklar som treng eit test-API frå ein arbeidsstasjon heime. Begge vil at kontorsida skal starte samtalen, som er det motsette av det vanlege klient-til-tenar-mønsteret.

Hosta fjernaksesprodukt varierer her, og variasjonen er ikkje ein feil. Nokre styrte VPN-tenester blokkerer med vilje uoppfordra tilkoplingar mot tilkopla klientar fordi modellen deira er klient-til-ressurs, ikkje ressurs-til-klient. Les den dokumenterte arkitekturen til produktet før du lovar ein kollega at berbaren hans kan fungere som tenar.

Fylg returvegen før du opnar ein port

Vegen har tre delar: ei rute på gatewayen som peikar på den indre adressa til klienten, ein policy som tillèt den konkrete kallaren, og ei lyttande teneste på målet. Kvar del sviktar ulikt, difor seier «VPN-et er oppe» nesten ingenting.

Den gode nyheita er at den indre vegen ikkje treng port forwarding på heimerutaren til klienten. Det er nettopp poenget med å publisere tenesta på tunneladressa i staden for på heime-WAN-adressa, der eksponeringa og NAT-reglane ville vore heilt annleis. Ein heimerutar kan også nekte å hairpinne ei tilkopling som kjem frå kontoret, så WAN-ruta sviktar av grunnar som ikkje har noko med VPN-et ditt å gjere. Å halde trafikken inne i tunnelen unngår begge problema på ein gong.

Sjekk målsida også. Ei teneste som berre er bunden til 127.0.0.1 kan ikkje ta imot ei tilkopling som kjem på tunellgrensesnittet, uansett kor riktige rutene på gatewayen er. Ein vertbrannmurregel som berre tillèt porten frå det lokale subnettet vil også droppe kontortrafikk, og den regelen er uavhengig av VPN-policyen over han.

Namn og adresser er designavgjerder

Ei adresse inne i tunnelen er ikkje automatisk eit namn. Ein privat DNS-post du kontrollerer er klårare enn å håpe at ein oppdagingsprotokoll kryssar tunnelen, fordi link-local multicast-namneoppslag blir på det lokale segmentet og blir ikkje DNS på tvers av subnett.

Adressestabilitet tyder like mykje. Viss VPN-klientar trekkjer frå ein pool med korte leiger, endrar den indre adressa til berbaren seg mellom økter, og kvart bokmerke, brannmur-område og overvakingssjekk bygd på ho blir broten i det stille. Bruk ein reservasjon eller ein dokumentert dynamisk oppdateringsveg.

Avtal namnet med den som eig VPN-identiteten, slik at posten, adressetildelinga og tilgangspolicyen endrar seg saman i staden for i tre separate saker.

Test tenesta, ikkje medlemskapen

Stadfest frå målet kva som lyttar og på kva adresse, stadfest deretter synet til gatewayen på returvegen:

$ 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 no frå kontorsida med ein ekte førespurnad i staden for eit ekko. Ein vellukka curl mot tenesta provar ruta, policyen og lyttaren på ein gong, medan ein vellukka ping berre provar at ICMP er tillate. Viss førespurnaden sviktar, gå baklengs gjennom dei tre delane i staden for å utvide brannmuren og håpe.

Tilgjengelegheit høyrer heime i same samtale. Ein berbar søv, roam på tvers av nettverk og koplar frå ved dagens slutt. Ei teneste som må svare til kva time som helst høyrer heime på ein alltid påslått vert, medan ei best-effort-teneste kan bli på klienten med den avgrensinga skriven ned.

Publiser ressursen med vilje, med eit namn, ei liste over tillatne kall og ein eigar, og fjernininga blir ei støtta teneste i staden for ein tilfeldig tenar.