Zure mahai gaineko inprimagailu, NAS edo garapen-makina bat erantzuteari uzten dio laneko VPNa konektatzen den unean. Batzuetan ibilbide-komando batek segundo batzuetan konpontzen du; beste batzuetan ibilbide bera zuzena da eta paketeak desagertzen dira oraindik, eta horrek esan nahi du antzeko sintoma duen beste arazo bati aurre egiten ari zarela. Erabakia hiru galderetara laburtzen da, eta okerreko ordenan egitea da jendeak gau osoa ibilbideak ezabatzen eta berriro gehitzen igarotzeko arrazoia.

Hiru galdera edozein komandoren aurretik

Lehenengoa: ba al dago tokiko aurrizkirako sarrerarik, eta adaptagailu fisikora seinalatzen du? Bigarrena: bezeroak sare lokaleko baimena edo ukapena jasotzen al du atetik konektatzean? Hirugarrena: LANerako irteerako sarbidea baino ez duzu behar, edo interneteko zerbait ere zure makinan exekutatzen den zerbitzu batera iritsi behar da?

Lehen galderak bideratze-matxura bat iragazte-matxura batetik bereizten du. Bigarrenak esaten du bideratze-konponketa bat onartzen den ala ez. Hirugarrenak konponketa aldatzen du: ibilbide batek irteerako trafikoa konpontzen du, eta iristezin den sarrerako zerbitzua, normalean, entzulearen lotura eta itzulera-bidearen arazoa da, eta ibilbide batek okerragotzen du.

What you seeWhat it points at
No local prefix in the tableMissing route
Correct prefix, no replyClient filter or gateway policy
Works by IP, fails by nameResolver changed by the tunnel
Inbound service dies, outbound fineReturn path or listener binding

Lehen galdera: ibilbidea, iragazkia edo izena

Irakurri taula ezer gehitu aurretik. Interfazearen indizeak garrantzia du, beheko ibilbide-komando bakoitza horretara lotuta dagoelako:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Zuzenean konektatutako azpisare batek estekakako ibilbidea mantendu ohi du tunela aktibo dagoen bitartean ere, beraz sarrera bat egon daiteke eta trafikoak huts egin dezake. Konbinazio hori bideratzearen ondoren exekutatzen den iragazki baten sinadura da, eta bigarren ibilbide zehatzago batek ezer aldatzen ez duen kasua da.

Probatu helbidearen eta izenaren arabera bereizita. ping 192.168.1.50 erantzuten badu eta net view 192.168.1.50 ez, bideratze-taula ez zen inoiz arazoa izan: tunelak ebazlea aldatu zuen eta tokiko izena ez da gehiago ebazten. Horretarako ibilbide bat gehitzea alferrikako lana da.

Bigarren galdera: atea tokiko LANerako sarbidea baimentzen du?

Bezero komertzial batek ibilbideak baino gehiago instalatzen ditu. Konektatzean politika bat jasotzen du, eta politika horrek sare lokaleko baimen esplizitua izan dezake. Cisco IPsec hedapenetan talde-politikak split-tunneling ezarpena eta tokiko LANerako sarbidearen bandera bereizi bat daramatza; bezeroaren laukitxoa atetzarrak ukatu dezakeen eskaera bat da. AnyConnecten profilek split-en barne eta kanpo zerrendak eta baimen bera kontrolatzen ditu. Windows RRASen baliokideak profileko ate lehenetsiaren aukera eta zerbitzariak esleitzen dituen ibilbide estatikoak dira.

Bandera itzalita dagoenean, dokumentatutako portaera da bezeroak zuzenean konektatutako azpisarera trafikoa blokeatzen duela, baliozko ibilbide zehatzago bat badago ere. Horregatik ere, bezeroarena ez diren ibilbideak gehitzen dituzunetik segundo batzuetara desagertu daitezke: bezeroak eraikitzeko esan zioten egoera berreraikitzen du, ez da zure aurka borrokatzen.

Bezeroaren logak erabakia erregistratzen du konektatzean, eta hura irakurtzea makinako edozein esperimentu baino azkarragoa da. Logak sarbide lokala blokeatuta dagoela esaten badu, gelditu: komando-lerroko konponketarik ez da horretatik bizirik ateratzen, eta falta diren bideak politika-aldaketa bat, baliabidera tunelaren bidez iristea, edo bezeroa makina birtual batean sartzea eta ostalaria sare lokalean uztea dira.

Hirugarren galdera: zein norabide behar duzu?

Gertuko gailu baterako irteerako trafikoa bideratze-kontua da. Bideratu LANaren aurrizkia tokiko aterantz tunelaren ibilbide lehenetsia gainditzeko bezain metrika baxuarekin:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Bigarren formak gailu bakarra finkatzen du, eta hori da nahi duzuna helbide bat denean baldintza osoa. netsh baliokideak erabaki bera erregistratzen du interfazearen izenaren arabera, indizearen arabera beharrean:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Ibilbide-komandoek Parametroa okerra da errorearekin huts egiten dute helbidea eta maskara bat ez datozenean, adibidez /24 maskara duen ostalari-helbide bat. Erabili sarearen helbidea azpisare-ibilbiderako eta ostalari-maskara ostalari bakarrerako.

Sarrerakoa desberdina da. Makina bereko VNC edo SSH zerbitzari bat iristezin bihurtzen da sarrerako konexio bati erantzunek VPN atea zeharkatzen dutenean eta inoiz ez direnean itzultzen. Egiaztatu zerbitzuak zer entzuten duen ibilbideak ukitu aurretik:

netstat -ano | findstr :5900

Helbide zehatz batera lotutako entzule batek ez du beste interfazean erantzungo. Hura interfaze guztietara lotzea erabaki deliberatua da, konfiantza duzun sarera mugatutako suebaki-arau batekin batera hartua. Horren ondoren bakarrik berreskuratzen du ibilbide-konponketak itzulera-bidea.

Aplikatu bat datorren aldaketarik txikiena

Beste mugimendu ohikoa «Erabili ate lehenetsia urruneko sarean» markatzea kentzea da IPv4ren propietate aurreratuetan. Interneteko trafikoa lokal mantentzen du, baina bi gauza egiten ditu aldi berean: VPNa ez da bide lehenetsia izaten, eta bezeroak urruneko sarearen ibilbideak jasotzeari uzten dio, multicast barne. Kendu marka eta urruneko LANa desagertzen da, zerbitzariak bezero bakoitzak behar dituen urruneko aurrizki zehatzak bultzatzen ez baditu.

Asimetria horrek erabakitzen du lanaren ordena. Urruneko aldea erabat iristeko moduan egon behar bada, bultza itzazu urruneko azpisareak zerbitzaritik eta utzi tokiko lehenetsia bakean. Zerbitzaria aldatu ezin baduzu, gehitu ibilbide iraunkor bat urruneko aurrizkira tunelak esleitutako helbidearen bidez, eta egiaztatu route print erabiliz aurrizkiak VPN interfazera seinalatzen duela eta lehenetsiak oraindik ate fisikora seinalatzen duela.

Gero egiaztatu konponketak berriz konektatzea gainditzen duela, ibilbide ez-iraunkorrak adaptagailuarekin hiltzen direlako eta konexio bakoitzaren ondoren exekutatzen den script bat delako haientzako leku zintzoa. Probatu tokiko gailu bat eta urruneko baliabide bat saio berean, deskonektatu, berriro konektatu eta probatu berriro. Tokiko gailuak huts egiten badu ibilbidea zuzena dirudien bitartean, itzuli bigarren galderara: bezeroa iragazten ari da, eta erantzuna politika-aldaketa da, ez bigarren ibilbide lehiakor bat.

Erlazionatutako artikuluak