VPN konektatuta baina suebakiak oraindik blokeatzen du: nola jakin zein

Bezeroak konektatuta dio, baliabideak ukatzen jarraitzen du, eta hurrengo urrats ohikoa zerbait desaktibatzea da. Esaldi horretako bi kontrolok lan desberdinak egiten dituzte: VPNak bidea eraikitzen du estalitako trafikoarentzat, eta suebakiak konexio bakoitzeko erabakitzen du trafikoak pasa dezakeen. Ukatzen duen politikarekin funtzionatzen duen tunela hondatutako tunelaren berdin-berdina da erabiltzailearen eserlekutik, beraz zeregina zein geruzak erantzuten duen aurkitzea da. Hona hemen jarraitzen dudan ordena, gelditzeko esaten dizun irakurketarekin.

Bereizi bidea politikatik

Hasi hutsegitearen formarekin, informazio doakoa baita. Paketea botatzeak itxarote-denbora sortzen du: bezeroak berriro saiatzen da, ezer ez da itzultzen, eta komandoak zintzilik jarraitzen du amore eman arte. Ukapenak uko edo berrezarpena sortzen du: zerbait erantzun zuen eta ezetza esan. Entzuten ez duen zerbitzuak ostalarian bertan ukatzen du, suebakirik gabe.

Hiru emaitza horiek geruza desberdinak seinalatzen dituzte. Itxarote-denborak esan nahi du nonbait politikaren batek isilka botatzen duela, edo bideak ez duela makina inoiz uzten. Ukatuak esan nahi du ostalarira iritsi zinela eta haren pilak edo suebaki lokalak uko egin ziola. Isiltasun osoak, tunelaren interfazea aktibo eta helmugarako biderik gabe, bidea okerra dela esan nahi du eta suebaki-arau batek ere ez duela konponduko.

Irakurri bidea pasaraldi bakarrean

Egiaztatu tunelek helmuga estaltzen duela arau bakarrera begiratu aurretik. Bulegoko azpisarea soilik daraman tunel zatituak ez du eskaera beste barruti batera bideratuko, eta orduan hutsegiteak suebaki-blokeoa dirudi, ez den arren:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Bidearen irteerak paketea zein interfazetatik aterako den eta zer jatorri-helbide eramango duen adierazten du. Interfaze hori zure txartel fisikoa bada eta ez tunela, arazoa bideratzean edo tunelaren baimendutako barrutietan dago, eta VPNaren konfigurazioari dagokio, ez suebakiari.

VPNari dagokion tranpa batek bere egiaztapena merezi du. WireGuarden, pare baten AllowedIPs bidea eta filtro kriptografikoa da aldi berean: jatorri-helbidea parearen multzo baimenduan ez duen paketea baztertzen da edozein suebaki-arau kontsultatu aurretik. Beraz, erabat zuzena den ostalari-suebaki bat politikak dirudien isilako bazterketa baten atzean egon daiteke, eta konponbidea gakoaren konfigurazio-lerro bat da, ez arau bat.

Irakurri politika erantzuten duen geruzan

Bidea zuzena denean, ibili politika ostalaritik kanpora eta begiratu kontagailuak mugitzen dituen geruza bakarra:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Entzuten ari den socketak arauek baino galdera desberdina erantzuten du. Atakan ezer entzuten ez bada, kernelak ukatzen du konexioa eta sarrerako arau bat ere ez da garrantzitsua. Socketa badago eta bezero urruneko konexioak iraungitzen bada, bazterketa bidearen nonbait gertatzen ari da, eta arauen kontagailuek hemen gertatzen den esaten dizute.

Aktibatu erregistroa susmatzen duzun profil edo katearentzat, kanpotik asmatu beharrean. Jatorria, helmuga eta ataka izendatzen dituen erregistratutako bazterketa bakar batek geruza eta araua identifikatzen ditu, eta paketea iritsi zela ere frogatzen du, bezeroaren aldeari inongo probak ez dezakeena.

Irakurri atearen erabakia tunelek han amaitzen duenean

Gune-guneko edo urruneko sarbideko ate batean, VPNak erabiltzailea autentifikatzen du eta politikak baliabidea baimenduko du, eta horiek emakida bereiziak dira. Tunelera onartutako erabiltzailea ez da automatikoki barneko ostalari guztietara onartzen, eta ukoa birbidalketa-arau batetik etortzen da sarritan, tunela bera sano dagoela. Bereizketa bera agertzen da IPsecen, trafikoa hautatzen duen segurtasun-politika hura onartzen duen iragazkitik ezberdina baita, eta horregatik biak mekanismo desberdin gisa dokumentatzen dira RFC 4301.

Egiaztatu itzulera-bidea joateko bidea bezain arretaz. Egoera-iragazkiak erantzuna ikusi behar du, beraz tuneletik norabide batean eta haren inguruan bestean bideratze asimetrikoak ausazkoak diruditen bazterketak sortzen ditu, bezero batzuetatik soilik errepikatzen direnak. Trafikoak atea iritsi eta gelditzen bada, irakurri birbidalketa-araua eta itzulera-bidea elkarrekin ezer zabaldu aurretik.

Atea da, halaber, NAT edo maskaratze-arau batek benetako jatorria ezkuta dezakeen tokia. Barneko ostalariek bezeroaren ordez atearen helbidea ikusten badute, bezeroen multzoarekin bat etorri behar duten haien suebaki-arau lokalek ez dute inoiz bat egingo, eta konponbidea atearena da, ez zerbitzari bakoitzarena.

Aldatu geruzarik estuena, eta gero egiaztatu

Aurka iezaiozu konponketa zabalari. Suebaki lokala desaktibatzeak, dena baimentzen duen arau bat gehitzeak edo interfaze bakoitza profil fidagarri batera behartzeak bere lana egiten zuen kontrola kentzen du, eta aldaketak gertaera gainditzen du. Jatorri-barrutira eta dagokion atakara mugatutako araua errazago berrikusten da, errazago kentzen da, eta makinaren gainerako politika ukitu gabe uzten du.

Egiaztatu huts egin zuen proba berarekin, bezero beretik, eta gero beste behin berriz konektatu ondoren, tunelek berriro negoziatu aurretik bat zetorren arauak gero bat ez etortzea gerta baitaiteke:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Hori itxi aurretik:

• Helmugarako bidea tunelaren interfazetik ateratzen da, eta jatorri-helbidea politikak espero duenarekin bat dator.
• Zerbait entzuten ari da atakan, eta ukoa edo itxarote-denbora izendatutako arau bati egozten zaio, ez da suposatzen.
• Ateak bi norabideetan birbidaltzen du, eta helmugak zure arauak idatzi ziren jatorria ikusten du.
• Ez zen kontrolik desaktibatu proba pasa zedin, eta egin zenuen aldaketak jatorri-barruti bat eta ataka bat izendatzen ditu.