Bideratze errekurtsiboa: tunelak bere paketeak harrapatzen dituenean

Tunela altxatzen da, erregistroak osatutako eskuko-agurra erakusten du, eta segundo bat geroago saio bera hiltzen da eta berriz konektatzen da begizta batean. Eredu horrek arrazoi zehatza du: zerbitzarirako bideak tunelaren barrura seinalatzen du orain, beraz tunela daramaten paketeak tunelaren bidez bidaltzen dira. Autentifikazioan ezer ez da aldatu, eta horregatik ez du ezberdintasunik egiten kredentzialak berriz sartzeak. Konparatu kanpoko bidea bidea aldatu aurretik eta ondoren, eta errekurtsioa agerian geratzen da.

Egiaztatu kanpoko bidea lehenik

Jokoan bi pakete daude, bat ez. Barneko paketea aplikazioarena da eta zifratuta egon beharko luke, kanpoko paketea, berriz, zerbitzariari zuzenduta dago eta tunelaren mende ez dagoen bide batetik iritsi behar zaio.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Galdetu kernelari zerbitzariaren helbiderako bidea tunela martxan jarri ondoren, eta berriro lehenetsitako bidea aldatu ondoren. Tunel-gailuan lurreratzen den hurrengo jauzia errekurtsioa da, eta paketeak harrapatu gabe ikusten da. Interfazearekiko loturak, markek edo sare-izen-espazioak bilaketa arrunta osatu gabe utz dezakete, beraz erabili bezeroak berak erabiltzen duen testuingurua. Erantzuna zuzena dirudienean baina saioak begizta egiten jarraitzen badu, irakurri bideratze-politikaren arauak, taula nagusia soilik ez ezik.

Zergatik irauten du saioak une batez

Eskuko-agurra bide berria instalatu aurretik osatzen da, beraz lehen segundoak osasuntsu dirudite. Bezeroak lehenetsitako bidea gehitzen duen unetik, hurrengo kanpoko paketeak hura jarraitzen du kanpoko pakete horrek zeharkatu behar duen interfazeraino. Zerbitzariak ez du ezer ikusten, bezeroak berriz bidaltzen du, eta saiakera edo denbora agortzen da edo saioa hiltzen du eta hasieratik hasten da.

Ordena horrek azaltzen du zergatik funtziona dezakeen tunel batek eramangarri batean eta huts egin bideratzaile batean, eta zergatik hasten den hutsa maiz trafikoa abiatzean eta ez konektatzean. Begizta ere azaltzen du: berrabiarazte bakoitzak saioa berrezartzen du bideak ezinezko bihurtu aurretik.

Aurkitu nor den amaierako puntuaren salbuespenaren jabea

Onartutako bezeroek beren salbuespena antolatzen dute: zerbitzarirako ostalari-bidea jatorrizko atebidetik, edo kanpoko socket-a tunelatik kanpo mantentzen duen marka bat. Galdera zera da: beste zerbaitek kendu edo gainidatzi ote zuen.

Bideetan oinarritutako IPsec-en, aztertu tunelera zein pakete sartzen diren erabakitzen duten politika-hautatzaileak, eta egiaztatu parekoaren helbidea horietatik kanpo dagoela. WireGuard-en, interfazearen suebaki-markak eta haren politika-arauek garraio-paketeak tunelatik kanpo mantentzen dituzte, beraz eskuz gehitutako lehenetsitako bide batek antolaketa hori hauts dezake. Bigarren VPN profil bat edo lehenetsitako bidea berridazten duen kudeaketa-script bat izan ohi da erruduna. Banan-banan gehitutako inguratzeko arau zabalak izaten dira emaitza ohikoa, eta bideratze-errore bat inork mantendu ezin duen taula bihurtzen dute.

Egiaztatu berriro sare-aldaketaren ondoren

Wi-Fi atebide baten bidezko ostalari-bidea zuzena da makinak beste sare batera joan arte. Orduan sintoma bera itzultzen da konfigurazioan inolako aldaketarik gabe.

Idatzi amaierako puntuaren helbidea, konektatu aurreko eta ondorengo bidea, eta bakoitzak erabilitako interfazea. Hiru datu horiek bezeroaren errorea gainidaztetik bereizten dute normalean, eta horiek bildu zituen pertsona joan arren irauten dute.

Konektatu berriro sare berrian eta errepikatu irakurketa. Salbuespena berriz ere falta bada, konponketa hura duen profilean dago, ez etenaldi batean idatzitako behin-behineko komando batean.