Bizilagun VPN bezero ibiltariak bulegorako zerbitzu bat ostatatu dezake?

Bezero ibiltariak bulegoko sistemak zerbitzatu ditzake atebideak harengana bideratzen duenean, ostalariaren politikak hori baimentzen duenean eta gailuak nahikoa denboraz irisgarri jarraitzen duenean soilik.

Zure bulegoko eramangarriak etxetik konekta dezake eta bulegoak behar duen zerbait eman dezake, baina hiru erabaki independente bat datozenean bakarrik. Tunela garraioa da, barne helbidea helmuga da, eta politikak erabakitzen du nork joka dezakeen. Horietako edozein erantzun oso gisa tratatzeak kexa ezaguna sortzen du: ostalariek ping-ari erantzuten dio baina aplikazioak ez du inoiz konektatzen. Rolak ez dira berdinak, eta aldea diseinu-lana dagoen tokian dago hain zuzen.

Sarrerako norabideak ez du zerbitzuaren norabideaz ezer esaten

Bezero batek tunel bat hasten duenean, bide bat irekitzen du, existitzen denean bi norabideek erabil dezaketena. Konexio berri batek hubetik bezero horren aldera sar daitekeen ala ez atebidearen politikaren kontua da, ez konektatu denaren ezaugarria. Bideratutako OpenVPN hub batean, adibidez, zerbitzariak bezeroaren barne helbiderako bidea behar du eta peer harremana baimentzen duen birbidalketa.

Imajinatu eramangarri ibiltarietako agente bat galdetzen duen inbentario-sistema bat, edo etxeko lan-estazio batetik probako API bat behar duen garatzaile bat. Biek bulegoaren aldea elkarrizketa hasteko nahi dute, ohiko bezero-tik-zerbitzarira ereduaren alderantzizkoa dena.

Ostatatutako urruneko sarbideko produktuek hemen aldatzen dute, eta aldaketa ez da akatsa. Kudeatutako VPN batzuek berariaz blokeatzen dituzte bezero konektatuetarantz eskatutako ez diren konexioak, haien eredua bezero-tik-baliabidera delako, ez baliabidetik bezerora. Irakurri produktuaren dokumentatutako arkitektura lankide bati bere eramangarriak zerbitzari gisa joka dezakeela agindu aurretik.

Jarraitu erantzun-bidea portua ireki aurretik

Bideak hiru zati ditu: atebidean bezeroaren barne helbidera seinalatzen duen bide bat, dei egile zehatza baimentzen duen politika bat, eta helburuan entzuten duen zerbitzu bat. Zati bakoitzak modu desberdinean huts egiten du, horregatik «VPN-a martxan dago» esaldiak ia ezer ez du esaten.

Albiste ona da barne bideak ez duela bezeroaren etxeko routerrean portu-birbidalketarik behar. Hori da zerbitzua tunelaren helbidean argitaratzearen zentzua, etxeko WAN helbidean egin beharrean, non esposizioa eta NAT arauak erabat desberdinak liratekeen. Etxeko routerrak bulegotik datorren konexio bat hairpin egiteari uko egin diezaioke, beraz WAN bideak huts egiten du zure VPN-arekin zerikusirik ez duten arrazoiengatik. Trafikoa tunelean barruan edukitzeak bi arazoak aldi berean saihesten ditu.

Egiaztatu helburuaren aldea ere. 127.0.0.1-ri soilik lotutako zerbitzu batek ezin du tunelaren interfazean iristen den konexio bat onartu, atebidearen bideak zein zuzenak diren gorabehera. Portua tokiko azpisareetatik soilik baimentzen duen ostalariaren suebaki-arauak bulegoko trafikoa ere baztertuko du, eta arau hori gainetik dagoen VPN politikatik independentea da.

Izenak eta helbideak diseinu-erabakiak dira

Tunelaren barneko helbide bat ez da automatikoki izen bat. Kontrolatzen duzun DNS erregistro pribatu bat argiagoa da aurkikuntza-protokolo batek tunela zeharkatuko duela espero baino, esteka-lokalean multicast bidezko izen-ebazpena segmentu lokalean geratzen baita eta ez baita azpisare arteko DNS bihurtzen.

Helbidearen egonkortasunak beste hainbeste balio du. VPN bezeroek alokairu laburreko igerileku batetik hartzen badute, eramangarriaren barne helbidea saioen artean aldatzen da eta haren gainean eraikitako laster-marka, suebaki-eremu eta monitorizazio-egiaztapen bakoitza isilean apurtzen da. Erabili erreserba bat edo dokumentatutako eguneratze dinamikoko bide bat.

Adostu izena VPN identitatearen jabearekin, erregistroa, helbide-esleipena eta sarbide-politika elkarrekin alda daitezen, hiru tiket bereizitan beharrean.

Proba itzazu zerbitzua, ez kidetza

Helburutik, egiaztatu zer entzuten ari den eta zein helbidetan, gero egiaztatu atebidearen itzulera-bidearen ikuspegia:

$ 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

Orain probatu bulegoaren aldetik benetako eskaera batekin, oihartzun batekin beharrean. Zerbitzuaren aurkako curl arrakastatsuak bidea, politika eta entzulea aldi berean frogatzen ditu, ping arrakastatsuak ICMP baimenduta dagoela soilik frogatzen duen bitartean. Eskaerak huts egiten badu, joan atzera hiru zatietan zehar, suebakia zabaldu eta itxaroten hasi beharrean.

Erabilgarritasunak elkarrizketa berean du lekua. Eramangarri bat lo egiten du, sareen artean ibiltzen da eta egunaren amaieran deskonektatzen du. Edozein ordutan erantzun behar duen zerbitzu bat beti piztuta dagoen ostalari batean dagokio; ahalegin oneneko zerbitzu bat, berriz, bezeroan geratu daiteke muga hori idatzita.

Argitaratu baliabidea nahita, izen batekin, baimendutako deitzaileen zerrendarekin eta jabe batekin, eta urrutiko gailua zerbitzari ustekabeko bat izan beharrean sostengatutako zerbitzu bihurtzen da.

Erlazionatutako artikuluak