URL bakarra bulegorako eta VPNrako? Zergatik huts egiten duen baimenduen zerrendaren mitoak

Konektatu tunela, ireki laster-marka bera, eta baimendutako guneak bulegotik bezalaxe erantzuten du. Hori da urruneko sarbideko plan gehienek isilka oinarritzat hartzen duten ustea, eta aldi berean hiru gauza bereizi egiazkoak diren bitartean baino ez du balio. Horietako bat ere ez da VPN bezeroaren ezaugarri, eta DNS erregistro batek ere ezin du horietako bat bera ere eman. Laster-markak etxean huts egiten duenean, nabigatzaileak errore generiko bakarra ematen dizu, kausa bide falta bat, onartu gabeko irteera-helbide bat edo jakinarazten duen iturria ordezkatu duen proxy bat izan. Hiru horiek arazo bakartzat hartzea da politika konponketa txiki bat baimenduen zerrendak zabaltzeko aste bihurtzen duen bidea.

Bulego-sare erreal batekin kontaktua gainditzen duen diseinua ustea baino estuagoa da: hiru errenkadako erabaki-taula esplizitu bat, saihestu ezin den betearazpen-puntu bat eta zerbait frogatzen duen ukapen-proba bat. Ustea desmuntatzea lehenengo dator, ondorengo guztiak zein geruzak oker aurkezten duen iturria jakitearen mende baitago.

Mitoa: konektatzea ez da bideratzea

Tunel bat ezartzen da, eta bezeroak bide batzuk instalatzen ditu prefijo multzo batentzat. Hori da konektatzeak egiten duen guztia. Erlaziorik gabeko HTTPS eskaera bat tuneletik igaroko den eta iristean zein helbide publikotatik datorren itxura duen, geroago beste osagaiek hartzen dituzten erabakiak dira: bideratze-taulak bidea aukeratzen du, eta irteerak iturria aukeratzen du.

Horregatik desberdintzen dira bulegoa eta sukaldeko mahaia portatil berarekin, nabigatzaile-profil berarekin eta laster-marka berarekin. Bulegoan eskaera gunearen operadoreak onartutako helbide publiko mantendu batetik ateratzen da. Tunel oso batetik VPN irteeratik atera daiteke, hau da, beste helbide bat eta, norbaitek gehitu arte, onartu gabea. Tunel zatitu batetik agian ez da tunelean sartzen ere. Hiru bide horietatik bik baino ez zuten inoiz gunearen jabearekin egindako akordioaren parte izan, eta hirugarrena ez da allow sarrera gehigarri batekin adabakitu beharreko akatsa.

Hiru eskaera-egoera, bi irteera onartu

Idatzi matrizea suebaki bat ukitu aurretik, taula diseinua baita eta araua haren ezarpen bakarra baino ez. Beheko helbideak dokumentazio-barrutiak dira; ordeztu itzazu zure balio mantenduekin eta gorde itzazu gunearen jabeak auditatu ditzakeen lekuan.

Erdiko errenkada da plan horietako gehienak hausten diren tokia. Betearazteko gailuak ikusten duen helbidea da garrantzitsua, ez portatilek tunelean barruan duen helbide pribatua eta ez haren LAN helbidea. 10.8.0.6 bezalako balio batek ez du ezer esan nahi gune publiko batentzat, eta 192.168.1.44 ere ez. Tuneleko helbidea tunelaren helbideratze-xehetasuna da, ez guneari egiaztatu ahal dion kredentziala.

Zure VPNak irteera egonkor eta dokumentaturik eman ezin badu, matrizeak ez du erdiko errenkada baliagarririk eta baimenduen zerrenda kopuruak ez du bat asmatuko. Une horretako aukera zintzoak bide pribatu esplizituen bidez iristen den gune pribatu bat edo aplikazioaren aurrean identitateaz jabetzen den sarbide-ate bat dira. Biek baimenduen zerrenda publiko batek ez bezalako kontratua dute, eta biak errazago azaltzen zaizkio auditore bati funtzionatzen hasi zen arte hazi zen zerrenda bat baino.

Irakurri iturria erabakia hartzen den tokian

Jarri murrizketa eskaera amaitzen duen gailuan, eta egiaztatu beste jatorri-bide batek ez duela saihesten. Nginx sarbide-modulua allow eta deny jarraibideak ordenan ebaluatzen ditu, lehen bat-etortzeak irabazten du, eta inguruko bloke batetik heredatutako arauak oraindik location barruan aplikatzen dira. allow estua allow zabal baten ondoan leku berean egoteak normalean zabala dela erabakitzen duela esan nahi du. Irakurri location horretarako konfigurazio eraginkor osoa haren lerro bakarra editatu aurretik.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Karga-balanceatzaile edo alderantzizko proxy baten atzean arau horrek proxya ikusten du, bestela esaten ez badiozu. Berreskuratu deitzailearen helbidea onartutako konfiantzazko proxy mekanismoaren bidez soilik, proxy helbideen zerrenda esplizitu batekin. Onartutako helbide bat dioen eskaera-goiburu bat ez da deitzaileak hura duenik frogatzen duen ebidentzia, eta entzule publiko batean baliozkotu gabeko aurreratutako goiburu batek baimenduen zerrenda apaingarri bihurtzen du.

Ondoren egiaztatu beste helbide-familia. IPv4 soilik estaltzen duen arau-multzo bat erabaki osatugabea da AAAA-n ere erantzuten duen ostalari-izenerako, eta IPv6 lan egiten duen bezero bat aplikazio berberera iritsiko da inoiz berrikusi ez duzun bide batetik.

Tunel zatitua: sekula sartzen ez den eskaera

Tunel zatitu batek bere zerrendan dauden prefijoak bakarrik daramatza. Bulegoko azpisare barnekoak normalean zerrenda horretan sartzen dira; webgune publiko bat ez. Nabigatzaileak izena ebazten du, aukeratutako helbidea bideratze-taularekin alderatzen du, eta hala ere tokiko ate lehenetsia aurkitzen du aurrean.

Horrela eskaera erabiltzailearen etxeko konexiotik iristen da, ukatu egiten da, eta txostenak VPN hondatuta dagoela dio tunelak hain zuzen konfiguratu zeneko lana egiten duen bitartean. Bi konponketa dira zilegi: bideratu helmuga hori tuneletik eta utzi onartutako irteerari hura garraiatzen, edo onartu gunera zuzenean iristen dela eta eman urruneko erabiltzaileei beste bide onartu bat, hala nola sarbide-atea. Gunearen baimenduen zerrenda publikoa etxeko helbide bat kasualitatez sartu arte zabaltzea ez da bi horietako bat ere, eta diseinuak betearazi behar zuen muga kentzen du. Lehenengo biek matrizea zintzo mantentzen dute; hirugarrenak isilka errenkada bat ezabatzen du.

Froga ezazu ukapena, gero berreskuratzea

Probatu benetako erabakia gauzatzen duen eskaera batekin, taulako errenkada bakoitzean dagoen bezero batetik. Helbidea erakusten duen erlaziorik gabeko orri baten aurkako irisgarritasun-egiaztapenak ez du ezer frogatzen, helmuga horrek aplikazioak ez duen bide bat jarrai baitezake.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Konparatu mugako sarbide-erregistroa taulak aurreikusi zuenarekin. Gero jaitsi tunela eta egin ukatu beharko litzatekeen eskaera berri bat; dagoeneko kargatutako orri batek edo dagoeneko irekitako konexio batek ez du ezer probatzen. Ukapenik agertzen ez bada, betearazpen-puntua ez dago uste duzun tokian.

Mantendu aplikazioaren autentifikazioa sarean onartu ondoren, bulegoko irteera batek eta VPN irteera batek bakoitzak jende asko ordezkatzen baitu eta batek ere ez du norbanako bat identifikatzen. Erabiltzaileentzako jarraibidea laburra da: altxatu onartutako tunela, eta gero saiatu berriro. Horrek URL bat erosoa izaten mantentzen du, iturri-araua asmakizuna beharrean erabakia izaten jarraitzen duen bitartean.