Zergatik da OpenVPN bezero baten atzeko azpisarea iristezina?

Zerbitzariaren tunel helbidera egindako ping-ek arrakasta dute, bezeroaren bere bideratze-taulak ondo dirudi, eta bezero horren atzeko LAN-era oraindik ezin da iritsi. Bezeroaren bideratze-taulak zuzena dirudi, zerbitzariak tunelera seinalatzen duen bide bat du, eta paketeak oraindik desagertzen dira. layer-3 tunel baten sintoma klasikoa da, bere bezeroetako bat pasabide ere badela ez daki eta.

tun interfazeak ez du hurrengo jauzirik bezero bakoitzeko. Kernelak pare asko dituen interfaze bakarra ikusten du, beraz urruneko LAN baterako paketea zein bezerok jaso behar duen erabakia OpenVPN prozesuaren barruan hartu behar da. Erabaki hori iroute-rekin konfiguratzen da, eta hori gabe paketeak ez du nora joan.

Zerbitzariak bezeroaren arabera bideratzen du, ez interfazearen arabera

Zerbitzariak bezero baten tunel helbidera pakete bat bidali behar duenean, erantzuna argia da: helbidea bezero horren saioarena da. Helmuga bezero horren atzeko azpisare osoa denean, helbidea zerbitzariak ezagutzen duen inorena ez da, eta kernelaren tunelerako bideak "interfaze honetatik" baino ez dio, pare zein den esan gabe.

OpenVPN barne-bideratze taula batekin konpontzen du, helburu-prefixua bezero jakin bati esleitzen diona. Taula hori iroute sarrerekin eraikitzen da, horregatik zerbitzariaren ostalarian bide arrunt bat ez da nahikoa. Kernelaren bideak paketea tunel interfazera eramaten du; barne-esleipenak erabakitzen du zein saiok jasoko duen. Horregatik ere konponketa ez da inoiz agertzen kernelaren bide-irteeran.

Esleipena falta bada, paketea zerbitzarira iristen da, tunel-bidearekin bat dator eta baztertzen da, inongo bezerok helmuga aldarrikatzen ez duelako. Ezerk ez du errore garbirik erregistratzen, horregatik hutsa zulo beltz isil baten moduan ikusten da, bideratze-begizta baten ordez.

Bezeroa izendatzen duen iroute sarrera idaztea

iroute bezeroaren berariazko konfigurazio-fitxategian bizi da, ez zerbitzariaren konfigurazio nagusian. Zuzendu zerbitzaria direktorio batera client-config-dir aukerarekin, gero sortu fitxategi bat, zeinaren izena bezeroaren ziurtagiriaren izen arrunta den, eta jarri prefijoa bertan.

LAN-a 10.20.0.0/24 duen eta ziurtagiriaren izen arrunta branch-router duen adar baterako, bide horretako fitxategiak iroute 10.20.0.0 255.255.255.0 bezalako lerro bat dauka. Konfigurazio nagusiak direktorio-aukerra soilik behar du; prefijoa bezeroarekin bizi da.

Izen arrunta da zati hauskorra. Beste subject batekin jaulkitako ziurtagiri batek, edo erabiltzaileak erabiltzaile-izenaz autentikatzen dituen ezarpen batek fitxategia ziurtagiriaren arabera izendatuta dagoen bitartean, inoiz irakurtzen ez den fitxategia sortzen du. Egiaztatu zerbitzariak saiorako benetan jakinarazten duen izena, eta aztertu bat ez datorren bezeroa huts egitera behartzen duen aukera, isilean bere biderik gabe konektatu beharrean. Fitxategia ziurtagiriarekin bat etor dadin berrizendatzea bost minutuko konponketa da, oso gau luzea saihesten duena.

Bezero batek hainbat prefixu izan ditzake. Gehitu iroute lerro bat sare bakoitzeko, eta eduki zerrenda bezero horren gainerako ezarpenen ondoan, esleipena egiaztagarria izan dadin.

Itzulera-bidea bi noranzkoetan eraikitzea

Paketeak urruneko LAN-era eramatea lanaren erdia da. Bezeroak LAN horren trafikoa tunelera ere bidali behar du, eta hori normalean bide bat bezeroari bultzatuta egiten da: push "route 10.8.0.0 255.255.255.0" bezalako lerro batek bezero bakoitzari esaten dio nola iritsi zerbitzari aldeko sarera. Adarrarentzat, baliokide den bideak tunelera seinalatzen du zerbitzari aldean iritsi behar duen guztiarentzat.

Itzulera-noranzkoak jabe bat behar du urruneko aldean. Alde horretan norbaitek itzulera-bidea ezagutu behar du: LAN-eko bideratzailean VPN pool-a zerbitzarira zuzentzen duen bide estatiko bat, edo zerbitzarian helbide-itxulpena trafikoa LAN-era sartu aurretik. Bide estatikoak jatorrizko helbideak ikusgai uzten ditu erregistroetan eta sarbide-arauetan, baina LAN-aren jabearen lankidetza eskatzen du; itzulpena burujabea da baina nork egiaztatu zuen benetan ezkutatzen du.

Birbidaltzea zerbitzariaren ostalarian gaituta egon behar da. Hori gabe kernelak tunel-etik paketea onartzen du eta LAN interfazera pasatzeari uko egiten dio, eta bezeroaren ikuspegitik iroute faltan bezala ikusten da.

Irisgarritasuna zunda egokiekin egiaztatzea

Probatu geruzaz geruza, urruneko muturrera ping egin eta asmatu ordez. Zerbitzaritik, egiaztatu prefijoarentzako barne-esleipena badela eta kernelaren bidea tunelera seinalatzen duela. Bezerotik, berretsi bultzatutako bidea instalatuta dagoela eta LAN helbiderako bide lehenetsia tunela dela.

Gero begiratu paketeak. Tunel interfazean egindako kapturak zerbitzaria bezeroaren aldera transmititzen ari den erakusten du, eta LAN interfazean egindako kapturak birbidaltzen ari den. Lehenak paketeak erakusten baditu eta bigarrenak ezer ez, birbidaltzea edo iragazki bat da arazoa; batek ere ezer erakusten ez badu, bilaketak lehenago huts egin zuen.

Tunel batez lotutako bi zerbitzarik arau bera errepikatzen dute bi aldeetan: bakoitzak bestearen pool-erako iroute bat behar du, eta bakoitzak bidea simetrikoa egiten duten bidea eta birbidaltzea behar ditu. Bideratzea eta politika gai bereiziak dira hemen. Bideratzeak paketea nora joan daitekeen erabakitzen du, FORWARD arau batek baimenduta dagoen erabakitzen duen bitartean, beraz iroute lerro bi dituen bezero batek bi prefixuetara irits daiteke, iragazkiren batek kontrakoa esaten ez badu.