Proxyak tunelaren helbide zaharrean jarraitzen du VPN berriro konektatu ondoren?

VPN bezeroa berrabiarazteak tunela itzuli dela frogatzen du soilik. Ez du ezer esaten haren bidez irteteko agindua jaso zuen proxyaz. Squid, tinyproxy eta beste birbidaltzaile gehienek abiaraztean ebatzitako tokiko iturburu-helbidea gordetzen dute, zerbait birkargatzera behartu arte. Berriz konektatzeak tunel-helbide berri bat ematen duenean, birbidaltzaileak irteerako konexio bakoitzean huts egiten du, edo zure ohiko bideetatik irteten hasten da.

Bigarren hutsegite hori da arriskutsua: tunela martxan dago, orrialdeak kargatzen dira, eta irteera-helbidea soilik da okerra.

Hasi entzulearekin, ez tunelarekin

Hiru helbide daude jokoan, eta berriz konektatzeak horietako batzuk soilik mugitzen ditu. Entzulea zure nabigatzaileak seinalatzen duen lekua da, normalean 127.0.0.1 edo LAN helbide bat, eta ez zaio axola tunela aldatu izana. Irteerako tokiko iturburua birbidaltzaileak hurrengo jauzia markatzean nukleoari erabiltzeko eskatzen diona da, eta tunel-gailuari lotuta dago. Irteera publikoa web zerbitzari batek erregistratzen duena da, eta hainbat jauzitara itzulitako helbidea izan daiteke.

IP publikoaren bilaketak azken galderari soilik erantzuten dio. Ezin dizu esan zein tokiko helbidetara lotu behar den birbidaltzailea, irteera publiko batek barne-iturburu batzuk ezkuta baititzake. Irakurri helbidea konexioaren jabe denarengandik: bezeroaren egoera-irteeratik, interfazetik beretik edo tunela bizi den izen-espaziotik. Tunel itxura duen izena duen lehen interfaza hartzeak erantzun okerra ematen du bigarren profil bat dagoen unetik.

Edukiontzi eta izen-espazio diseinuek isilean hausten dute suposizio hori. Sare izen-espazio bateko birbidaltzaileak ezin du beste batean dagoen tunel batera lotu, eta konfigurazioa editatzeak ez du hori konpontzen.

Lau egiaztatze ezer editatu aurretik

Egin itzazu ordenan. Huts egiten duen lehen egiaztatzea da gelditzen zaren tokia, ondorengoek aurrekoak balio dutela suposatzen baitute.

1. Egiaztatu erabiltzen ari den tunela proxyaren inguruan eraiki zen profila dela, ez bere kabuz konektatu zen bigarren profil bat.
2. Inprimatu gailu horretan orain dagoen helbidea eta alderatu exekuzioan dagoen konfigurazioko helbidearekin.
3. Galdetu birbidaltzaileari zein iturburu ebatzi duen, diskoan dagoen fitxategiak dioenaren ordez.
4. Egiaztatu birbidaltzailearen trafikoa benetan espero duzun bideratze- eta suebaki-politikaren mende dagoela.

Gailuaren helbidea erraza da: ip -4 addr show dev tun0 uneko helbidea inprimatzen du, eta ip -4 route get 1.1.1.1 nukleoak helmuga horretarako zein interfaz aukeratuko lukeen erakusten du. Helbide zehatz batera lotzen den birbidaltzaileak ozenki huts egiten du helbidea desagertzean. Gailu batera lotzen den edo iturburu lehenetsira jotzen duen birbidaltzaileak lanean jarraitzen du eta ihes egiten du, eta hori da emaitza isila.

Parekatu dokumentazioa exekutatzen duzun bertsioarekin, ez bilaketa-emaitzarik gorenekoarekin. Squid-en irteera-helbiderako direktiba v7 eta lehenagokoentzat dokumentatuta dago, eta v8 dokumentazioak argi dio direktiba ez dagoela eskuragarri han, beraz haren inguruan eraikitako script batek ez du muga hori gainditzen (ikusi Squid tcp_outgoing_address erreferentzia). Egiaztatu produktuaren beraren analizatzailearekin ezer birkargatu aurretik: squid -k parse erroreak jakinarazten ditu eta irteten da exekuzioan dagoen prozesua ukitu gabe.

Zenbakitu tunel bakoitza eta baztertu ordezkatze zaharkituak

Berriz konektatzea eskualdatze bat da, eta eskualdatzeek ordena behar dute. Markatu ikusitako konexio bakoitza ezarpen arrakastatsu bakoitzean handitzen den kontagailu edo denbora-marka batekin, eta gero eraman marka hori hautagai-konfigurazioaren barruan. Hautagai bateko marka unekoa baino zaharragoa denean, baztertu hautagaia aplikatu beharrean, aurreko tunelerako idatzitako eguneratze geldo batek unekoaren ezarpenak gainidatziko bailituzke bestela. Batu gertaeren boladak, lotura dardarati batek hamabost beharrean trantsizio bat sor dezan.

Antolatu lana lau mugimendutan: baliogabetu irteerako egoera zaharra, itxaron konexioaren jabeak osatzea jakinaraz dezan, eraiki kudeatutako zatia soilik, eta gero egiaztatu eta aktibatu zerbitzu-kudeatzailearen bidez. Fitxategi osoa bi helbide-balioetatik birsortzea da entzulearen murrizketak, autentifikazioa eta helmuga-politika isilean desagertzen diren modua. Errespetatu itzaltze deliberatua ere. Erabiltzaileak itzali duen tunel batera deitzen jarraitzen duen laguntzailea akatsa da, ez erresilientzia.

Soket irekiek ez dute helbide berria jarraituko

Birbidaltzailea berrikonfiguratzeak ez du ezer esaten jada ezarrita dauden konexioei buruz. Hustuko diren edo hilko diren produktuaren arabera dago, beraz behatu jokabidea suposatu beharrean.

Ordezkatzearen aurretik irekitako soket baten bidez zerbitzatutako eskaera oraindik bide zaharretik irteten da, konfigurazio berria zuzena denean ere. Hori garrantzitsua bada, erabaki espresuki: utzi hustuketa-leiho labur bat eta utzi lan berria onartzeari, edo itxi soket zaharrak eta onartu erroreak. Gero probatu konexio berri batekin eta eduki emaitza hori hustuketa-egiaztatzetik bereizita. Iturburuaren lotura ere ez da segurtasun-muga bat. Trafikoak sekula ohiko bidea ukitu behar ez duenean, behartu hori markekin eta suebaki-arauak erabiliz, DNS eta IPv6 barne, birkarga huts batek proxyak argi eta garbi itzalita utz ditzan irekita egon beharrean.

Frogatu irteera berria eskaera berri batekin

Garrantzitsua aktibatu ondoren irekitako eskaera da, ez ping bat eta ez dagoeneko cachean dagoen orrialde bat. Eskatu proxyari benetako URL bat eta irakurri urruneko aldeak jakinarazten duen irteera-helbidea, eta gero alderatu bezeroak tunelari buruz duen ikuspegiarekin hornitzaileak bat erakusten duenean.

Eduki analisia, birkarga eta eskaera komando bereizi gisa, hutsegite batek urrats bakarra seinala dezan. Lehenengo biek ez dute ezer aldatzen huts egiten dutenean, eta horregatik hain zuzen exekutatzen dira berrabiaraztearen aurretik.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

Birkargak huts egiten badu, gelditu zerbitzua eta konpondu zatia; irteera zaharkituarekin zerbitzatzen duen proxy bat etenaldi labur bat baino okerragoa da. Birkarga ondo badoa baina eskaera berriak ustekabeko lekuan irteten badu oraindik, itzuli bideratze-egiaztatzera helbideak berriz editatu beharrean. Idatzi baliozkotzean erabili duzun tunel-belaunaldia, hurrengo berriz konektatzeak zer konparatu zehatza izan dezan.