Kan ’n rondswerwende VPN-kliënt ’n diens vir die kantoor huisves?
’n Rondswerwende kliënt kan kantoorstelsels bedien slegs wanneer die poort na hom roeteer, die gasheerbeleid dit toelaat en die toestel lank genoeg bereikbaar bly.
Jou kantoorlaptop kan van die huis af inbel en steeds iets lewer wat die kantoor nodig het, maar slegs wanneer drie afsonderlike besluite in lyn kom. Die tonnel is vervoer, die binne-adres is die bestemming, en beleid besluit wie mag klop. Om enigeen daarvan as die hele antwoord te behandel, lewer die bekende klag dat die gasheer pings beantwoord maar die toepassing nooit verbind nie. Die rolle is nie dieselfde nie, en die verskil is juis waar die ontwerpwerk lê.
Die inbelrigting sê niks oor die diensrigting
Wanneer ’n kliënt ’n tonnel begin, open dit ’n pad wat beide rigtings kan gebruik sodra dit bestaan. Of ’n nuwe verbinding van die hub na daardie kliënt mag inkom, is ’n poortbeleidvraag, nie ’n eienskap van wie ingebel het nie. Op ’n OpenVPN-hub met roetering het die bediener byvoorbeeld ’n roete na die kliënt se binne-adres nodig en stuurwerk wat die eweknie-verhouding toelaat.
Stel jou ’n voorraadstelsel voor wat ’n agent op rondswerwende skootrekenaars peil, of ’n ontwikkelaar wat ’n toets-API vanaf ’n werkstasie by die huis nodig het. Albei wil hê die kantoor se kant moet die gesprek begin, wat die omgekeerde van die gewone kliënt-na-bediener-patroon is.
Gehuisvesde afstandtoegang-produkte verskil hier, en die verskil is nie ’n fout nie. Sommige bestuurde diens-VPN's blokkeer doelbewus onopgevraagde verbindings na gekoppelde kliënte, want hul model is kliënt-na-bron, nie bron-na-kliënt nie. Lees die produk se gedokumenteerde argitektuur voordat jy ’n kollega belowe dat hul skootrekenaar as bediener kan dien.
Volg die antwoordpad voordat jy ’n poort oopmaak
Die pad het drie dele: ’n roete op die poort wat na die kliënt se binne-adres wys, beleid wat die spesifieke oproeper toelaat, en ’n luisterdiens op die teiken. Elke deel faal anders, en daarom sê “die VPN is op” byna niks.
Die goeie nuus is dat die binne-pad nie ’n poortaanstuur op die kliënt se tuisroeteerder nodig het nie. Dit is die punt daarvan om die diens op die tonneladres te publiseer eerder as op die tuis-WAN-adres, waar die blootstelling en die NAT-reëls heeltemal anders sou wees. ’n Tuisroeteerder kan ook weier om ’n verbinding wat van die kantoor kom, te hairpin, so die WAN-roete faal om redes wat niks met jou VPN te doen het nie. Om die verkeer binne die tonnel te hou, vermy albei probleme gelyktydig.
Kyk ook na die teikenkant. ’n Diens wat net aan 127.0.0.1 gebind is, kan nie ’n verbinding aanvaar wat op die tonnelkoppelvlak aankom nie, maak nie saak hoe korrek die poort se roetes is nie. ’n gasheervuurmuurreël wat die poort net vanaf die plaaslike subnet toelaat, sal ook kantoorverkeer laat val, en daardie reël is onafhanklik van die VPN-beleid daarbo.
Name en adresse is ontwerpbesluite
’n Adres binne die tonnel is nie outomaties ’n naam nie. ’n Privaat DNS-rekord wat jy beheer, is duideliker as om te hoop dat ’n ontdekkingsprotokol die tonnel oorsteek, want skakel-plaaslike multicast-naambepaling bly op die plaaslike segment en word nie subnet-oorkoepelende DNS nie.
Adresstabiliteit maak net soveel saak. As VPN-kliënte uit ’n poel met kort huurtermyn trek, verander die skootrekenaar se binne-adres tussen sessies en elke boekmerk, vuurmuur-bestek en moniteringstoets wat daarop gebou is, breek stil-stil. Gebruik ’n reservering of ’n gedokumenteerde dinamiese opdateringsroete.
Maak die naam met wie ook al die VPN-identiteit besit, ooreen, sodat die rekord, die adrestoewysing en die toegangsbeleid saam verander eerder as in drie afsonderlike kaartjies.
Toets die diens, nie die lidmaatskap nie
Vanaf die teiken, bevestig wat luister en op watter adres, bevestig dan die poort se siening van die terugpad:
$ 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
Toets nou van die kantoor se kant met ’n werklike versoek eerder as ’n eggo. ’n Geslaagde curl teen die diens bewys die roete, die beleid en die luisteraar tegelyk, terwyl ’n suksesvolle ping net bewys dat ICMP toegelaat word. As die versoek misluk, werk terug deur die drie dele in plaas daarvan om die vuurmuur te verbreed en te hoop.
Beskikbaarheid hoort in dieselfde gesprek. ’n Skootrekenaar slaap, swerf tussen netwerke en ontkoppel aan die einde van die dag. ’n Diens wat enige uur moet antwoord, hoort op ’n altyd-aan gasheer, terwyl ’n diens wat beste-poging is, op die kliënt kan bly met daardie beperking neergeskryf.
Publiseer die bron doelbewus, met ’n naam, ’n lys van toegelate oproepers en ’n eienaar, en die afstandtoestel word ’n ondersteunde diens eerder as ’n toevallige bediener.