Kin in roaming VPN-klant in tsjinst foar it kantoar hoste?
In roaming-klant kin kantoarsystemen allinnich tsjinje as de gateway nei him rûtelet, it hostbelied it tasteat en it apparaat lang genôch berikber bliuwt.
Jo kantoarlaptop kin fan hûs ôf ynbelje en dochs eat leverje dat it kantoar nedich hat, mar allinnich as trije aparte besluten byinoar komme. De tunnel is ferfier, it binnenadres is de bestimming, en belied beslút wa't oanbelle mei. As jo ien fan dy as it hiele antwurd behannelje, kriget jo de bekende klacht dat de host ping beantwurdet mar de applikaasje nea ferbynt. De rollen binne net itselde, en it ferskil is krekt dêr't it ûntwurkwurk leit.
De ynbelrje-rjochting seit neat oer de tsjinstrjochting
As in klant in tunnel begjint, iepenet er in paad dat beide rjochtingen brûke kinne sadree't it bestiet. Oft in nije ferbining fan 'e hub nei dy klant ynkomme mei, is in fraach fan gatewaybelied, net in eigenskip fan wa't ynbelle hat. Op in routed OpenVPN-hub hat de server bygelyks in rûte nei it binnenadres fan 'e klant nedich en trochstjoering dy't de peer-relaasje tastiet.
Stel jo in foarriedsysteem foar dat in agent op roaming-laptops ûndersiket, of in ûntwikkelder dy't in test-API fan in wurkstasjon thús nedich hat. Beide wolle dat de kantoarkant it petear begjint, wat it tsjinstelde is fan it gewoane klant-nei-server-patroan.
Hosted remote-access-produkten ferskille hjir, en it ferskil is gjin bug. Guon behearder VPN-tsjinsten blokkearje bewust net-frege ferbiningen nei ferbûne klanten, om't har model klant-nei-boarne is, net boarne-nei-klant. Lês de dokumintearre arsjitektuer fan it produkt foardat jo in kollega ûnthjitst dat syn laptop as server tsjinje kin.
Folgje it werompaad foardat jo in poarte iepenje
It paad hat trije dielen: in rûte op 'e gateway dy't nei it binnenadres fan 'e klant wiist, belied dat de spesifike beller tastiet, en in harkjende tsjinst op it doel. Elk diel falt oars út, dêrom seit «de VPN is omheech» hast neat.
It goede nijs is dat it binnenpaad gjin port-forwarding op 'e thúsrouter fan 'e klant nedich hat. Dat is it punt fan it publisearjen fan 'e tsjinst op it tunneladres ynstee fan op it thús-WAN-adres, dêr't de bleatstelling en de NAT-regels hiel oars wêze soene. In thúsrouter kin ek wegerje om in ferbining fan it kantoar te hairpinnen, sadat de WAN-rûte falt om redenen sûnder ferbân mei jo VPN. It ferkear binnen de tunnel hâlde foarkomt beide problemen tagelyk.
Kontrolearje ek de doelkant. In tsjinst dy't allinnich oan 127.0.0.1 bûn is, kin gjin ferbining akseptearje dy't op 'e tunnelinterface oankomt, hoewol't de rûtes fan 'e gateway mar kloppe. In host-firewallregel dy't de poarte allinnich fan it lokale subnet tasteit, sil kantoarferkear ek weilitte, en dy regel is ûnôfhinklik fan it VPN-belied derboppe.
Nammen en adressen binne ûntwerpbesluten
In adres binnen de tunnel is net automatysk in namme. In privee DNS-record dat jo beheare is dúdliker as hoopje dat in ûntdekkingsprotokol de tunnel oerstekt, om't link-local multicast-nammebepaling op it lokale segmint bliuwt en gjin DNS tusken subnetten wurdt.
Adresstabiliteit is like wichtich. As VPN-klanten út in poel mei koarte leases helje, feroaret it binnenadres fan 'e laptop tusken sesjes en elk blêdwizer, firewall-berik en monitoringkontrôle dat dêrop boud is, brekt stil. Brûk in reservearring of in dokumintearre dynamyske bywurkpaad.
Bepraat de namme mei wa't de VPN-identiteit hat, sadat it record, de adrestawizing en it tagongsbelied byinoar feroarje ynstee fan yn trije aparte kaarten.
Test de tsjinst, net it lidmaatskip
Befêstigje fan it doel ôf wat harket en op hokker adres, befêstigje dan it byld fan 'e gateway fan it werompaad:
$ 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 fan 'e kantoarkant mei in echt fersyk ynstee fan in echo. In suksesfolle curl tsjin de tsjinst bewissiget de rûte, it belied en de harker tagelyk, wylst in suksesfolle ping allinnich bewissiget dat ICMP tastien is. As it fersyk mislearret, wurkje dan efterstfoar troch de trije dielen ynstee fan 'e firewall te ferbreedzjen en te hoopjen.
Beskikberens heart by itselde petear. In laptop sliept, roamet tusken netwurken en ferbrekt oan 'e ein fan 'e dei. In tsjinst dy't op elk oere antwurdzje moat, heart op in altyd-oan host, wylst in best-effort-tsjinst op 'e klant bliuwe kin mei dy beheining opskreaun.
Publisearje de boarne bewust, mei in namme, in list fan tastiene bellers en in eigner, en it ôfstâne apparaat wurdt in stipe tsjinst ynstee fan in tafallige server.