Sare lokala irisgarria ez VPN konektatuta dagoela? Lau egiaztapen

Tunela altxatzen da, intraneta agertzen da eta inprimagailua erantzuteari uzten dio. Sare lokalean ez da ezer huts egin; bezeroak aldatu du jada lokal gisa hartzen ez dituen helbideetarako erabiltzen duen bidea. Egin beheko lau egiaztapenak hurrenez hurren eta gelditu batek desadostasun zehatza ematen duenean, sintoma berak lau arrazoi ohiko dituelako eta horietako bat baino ez delako konpontzen VPNa aldatuta.

Lehenik, begiratu bezeroak instalatutako bideratze-taula

Ireki bezeroaren bideratze-taula VPN konektatuta dagoela. Linuxen erabili ip route, Windowsen route print edo Get-NetRoute, eta macOSen netstat -rn. Tunelaren bidezko bideratze lehenetsi bat bila ari zara, eta bideratze lehenetsi fisikoari zer gertatu zaion.

Tunel osoko bezero batek askotan bi erdi-bideratze lehenetsi gehitzen ditu, 0.0.0.0/1 eta 128.0.0.0/1, 0.0.0.0/0 ordezkatu beharrean. Jatorrizko bideratze lehenetsia ikusgai geratzen da baina bilaketa guztiak galtzen ditu, eta horregatik taulak osorik dirudi azpisareaz kanpoko trafiko guztia mugitzen den bitartean. VPN bezeroak tunel zatituaren aukera eskaintzen badu eta politikak uzten badu, hori da konponbiderik garbiena.

Tunelak bideratze lehenetsia izaten jarraitu behar badu, ainguratu azpisare lokala. Linuxen bideak interfaze fisikoa eta atebidea izendatzen ditu; Windowsen gehitu -p iraunkorra izateko eta irakurri interfazearen zenbakia route print-tik, asmatu beharrean:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Ainguratutako bideak apenas dirauen izendatzen duen helbidea berdin jarraitzen duen bitartean. Konexio bakoitzean bere Wi-Fi egokitzailea berriz zenbakitzen duen eramangarriak araua berriro hautsiko du, beraz, egiaztatu interfazearen helbidea konponbidea huts egin duela erabaki aurretik.

Bigarrenik, egiaztatu helbidea hasieratik lokala zela

Helmuga konektatutako azpisarearen barruan badago, tunelaren bideratze lehenetsia ez da inoiz aplikatzen eta VPN ez da arrazoia. 192.168.1.40 helbideko inprimagailuak, 192.168.1.0/24 duen bezeroan, konektatutako bidea erabiltzen du; helbide horrek huts egiten badu, begiratu gailua, kommutadorea edo bezeroaren suebakia, ez VPNa.

Jendea engainatzen duen kasua zerbitzari lokal baterako helbide publikoa da. Sare lokaletik barrura, routerraren WAN helbidera iristeak eta itzultzeak hairpin NAT behar du, eta router askok ez dute portu-birbideratzeetarako ezartzen. Probatu helbide pribatua publikoaren ondoan. Helbide pribatuak funtzionatzen badu eta publikoak ez, VPNak jada zegoen NAT muga bat baino ez zuen agerian utzi.

Ostalari-izenak okerrera egiten du. Izen lokalak orain helbide publikora ebazten badu, bezeroak ezin duen bidea probatzen jarraituko du. Erabili helbide pribatua probarako, eta gero konpondu izena beste portu-birbideratze bat gehitu beharrean.

Hirugarrenik, ikusi nor arduratzen den izenez orain

Enpresako ebazleak intraneta ezagutzen du, eta normalean ez daki ezer NAS ostalari-izenaz, inprimagailu baten Bonjour izenaz edo router baten alias lokalaz. VPNak bere DNS zerbitzariak bultzatzen dituenean, izen horiek ebazteari uzten diote, haien helbideak oraindik irisgarriak izan arren. Galdetu izena zuzenean eta alderatu erantzuna gailuak duen helbidearekin.

Linuxen, resolvectl query nas.local-k erakusten du zein ebazlek erantzun zuen. Windowsen, nslookup nas.local-k zerbitzariaren izena ematen du, eta ipconfig /all-k ebazleen ordena erakusten du. Sufixu lokala orain enpresako ebazleak kudeatzen badu, bideratu sufixu hori ebazle lokalera edo erabili gailuaren IP helbidea.

Aurkikuntza geruza bereizia da. mDNS eta difusioa ez dira bideratutako tuneletik pasatzen, beraz gailua helbidez irisgarria izan daiteke bere izena ikusezina den bitartean. Islatzaile batek edo DNS sarrera lokal batek konpontzen du hori; bide batek ez.

Laugarrenik, egiaztatu beste makina ere VPN batean dagoen

Iritsi nahi duzun makinak ere VPN bezeroa exekutatzen badu, zure saioa irits daiteke bere erantzuna beste tunel batetik irteten den bitartean. Horrek ezartzen den eta gero trabatzen den konexio bat sortzen du, edo zure aldean errorerik gabe iraungitzen den RDP eta SSH saiakera bat. Egiaztatu beste ostalariaren bideratze-taula eta bere bide lehenetsia zure bezeroa erruduntzatu aurretik.

Egiaztatu zerbitzuak entzuten duen helbidea ere. Tunelaren helbidera soilik lotutako entzuleak VPNtik datozen konexioak onartzen ditu eta sare lokaletik datozenak ukatzen ditu, bideratzea perfektua denean ere. Hori zerbitzuaren konfigurazioa da, ez sare-bide bat, eta ohikoa da VPN helbidera mugatutako kudeaketa-interfazeetan.

Mantendu tuneletik independentea den kudeaketa-bide bat: zure iturburu-sarea izendatzen duen bide estatikoa, sare lokalera konektatutako beste interfaze bat, edo tunela erabat saihesten duen kontsola bat. Bide hori saioa erori ondoren diseinatzea askoz zailagoa da hurrengo konexioaren aurretik gehitzea baino.

Aplikatu huts egin zuen egiaztapenari dagokion konponbidea

Bideratze-taulak erdi-lehenetsiko kaptura erakutsi badu, aukeratu tunel zatitua politikak uzten duenean eta ainguratutako bide lokala uzten ez duenean. Helbidea publikoa gertatu bada, aldatu proba eta izena helbide pribatura. Ebazleak eskuak aldatu baditu, mugatu sufixu lokala edo erabili helbidea. Beste ostalaria tunelean badago, konpondu bere itzulera-bidea edo entzulearen lotura.

Aldatu gauza bat, eta gero errepikatu egiaztapen bera. Azpisare okerrarentzat gehitutako bidea, errore tipografikoa duen ebazle-sufixua eta berriz zenbakitzen den interfaze bateko bide ainguratua jatorrizko hutsegitearen itxura dute denek. Errepikapenak bereizten du konponbidea kasualitatetik.

Idatzi VPN konektatuta zegoela funtzionatu zuten bidea, helbidea eta ebazlea. Hurrengo berrikonexioak horietako bat gutxienez aldatuko du, eta oharrak hurrengo etenaldia ikerketa berri bat izan beharrean konparazio labur bihurtuko du.