Badirudi bi VPN bezero socket beragatik borrokan ari direla, eta konponbide nabaria bat desinstalatzea izan behar dela. Praktikan gutxitan ukitzen dute socket bera. Konexio bakoitzak sistema eragilearen bideratze-taula berridazten du, eta tunel osoko profilek bide lehenetsia aldarrikatzen du. Azkenik konektatu denak irabazten du normalean, eta horregatik sintomak bezeroen artean mugitzen direla dirudi.

Gatazka bideratze-taulan bizi da

Egokitzaile birtual bat gehi bide lehenetsi bat–horrela harrapatzen du trafikoa tunel osoak. Bigarren bezeroak bere bide lehenetsia instalatzen duenean, sarrera zaharragoa ordezkatu edo metrikaren arabera beheratua izaten da, eta helmuga bakoitza tunel berriagoan barrena joaten da orain. Lehen bezeroa konektatuta geratzen da eta ikono berdea erakusten du oraindik, beraz interfazea aktibo dago bidea desagertu den bitartean. Konexio-egoeraren eta bideratze-egoeraren arteko bereizketa horrek egiten du jokabidea nahasgarri.

Bezeroak taula partekatu bakarreko editoreak dira. Zein aldaketa gertatu zen azkenengo jakiteak sintoma ia guztiak azaltzen ditu.

Irakurri zein tuneli dagokion uneko bidea

Egiaztatu benetako erabakia konektatuta dagoela dioen bezeroan fidatu beharrean. Galdetu sistemari zein interfazek eramango lukeen helmuga jakin bat.

ip route get 10.20.0.5
route print -4

Lehen komandoak helmuga baterako interfazea eta iturburu-helbidea izendatzen ditu, eta hori da axola zaizun galdera zehatza. Bideen zerrendak Windows-en lehian dauden sarrera lehenetsiak eta haien metrikak erakusten ditu, beraz unean zein irabazten duen ikusten duzu. Exekutatu bilaketa urrutiko sare bakoitzean ostalari batentzat, helmuga bat zuzena izan baitaiteke beste sarea iristezina den bitartean. Erantzunak tunel okerra izendatzen badu, berriz konektatzeak ez du lagunduko; bideratze-politika aldatu behar da.

Geldiarazi bigarren bezeroa dena aldarrikatzetik

Bezero batek bide lehenetsia eduki beharko luke, eta besteak bere aurrizkiak bakarrik eraman. OpenVPN bezeroek uka dezakete zerbitzariak bultzatzen duena.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull-k bultzatutako bide guztiak alde batera uzten ditu, pull-filter ignore "redirect-gateway"-k berriz bide lehenetsiaren jarraibidea bakarrik botatzen du eta bultzatutako DNSa eta beste aukera batzuk mantentzen ditu. Hautatu bien artean zerbitzariaren konfiguraziorik zenbat nahi duzun oraindik, eta gero gehitu bigarren sareak behar dituen aurrizki zehatzak. Kontuan izan DNSa, bilaketak eramaten ez dituen tunel batek bultzatutako ebazlea ezer ez baitu itzultzen. Probatu ostalari ezagun bat sare bakoitzean eta egiaztatu urrutiko aldeak ikusten duen iturburu-helbidea.

Gainjartzen diren azpisareak ezin dira saihestu

Bi sareek aurrizki bera argitaratzen dutenean, kernelak sarrera bat gordetzen du bi leku desberdinetarako eta aukeratu behar du. Ostalari-bide batek ezin du falta den bereizketa asmatu, ezta metrika-doikuntzak ere. Zenbatu berriro alde bat, edo utzi bere administratzaileari urrutiko barrutia itzultzen aurrizkiak desberdinak izan daitezen. Egiaztatu benetako azpisareak bezeroei errua bota aurretik, etxeko bideratzaile baten lehenetsitako 192.168.1.0/24-k bulegoko barruti batekin talka egiten baitu inork espero baino sarriago. Idatzi bi barrutiak tiketan hurrengo aldaketak gainjartzea berriro sor ez dezan.

Bereizi bi helburu ere: bi sareetara iristea bideratze-arazo bat da, eta tunelak kateatzea pribatutasunagatik beste diseinu bat da, bidean operadore gehigarri bat duena. Ez erabili bata bestea konpontzeko.

Erlazionatutako artikuluak