Zer uzten dio OpenVPN-eko route-nopull-ek zerbitzariari bidaltzen
route-nopull-ek bidalitako ibilbideak eta DHCP aukerak botatzen ditu, ez esku-ematea. Hautatu haren, pull-filter-en edo ezeren artean, eta gero gehitu ibilbideak zuk zeuk.
route-nopull bezero-profil batean jarri zenuen tunelak zure ibilbide lehenetsia irents ez zezan, eta orain bulegoko azpisarea iristezina da bezeroak oraindik konektatuta dagoela dioen bitartean. Bi behaketak egiazkoak dira, eta ezerk ez du huts egin. Banderak bezeroari esaten dio zerbitzariak bidaltzen dituen ibilbideak eta DHCP sarrerak saltatzeko, gehitzerakoan jende gehienak espero duena baino argibide estuagoa. Geratzen dena funtzionatzen duen tunel bat da, zein helburuk erabili beharko luketenari buruzko iritzirik gabe.
Hutsune hori da artikulu honen gaia den erabaki osoa. Edo zerbitzariak sarearen deskribapena ematen du, edo bezeroak egiten du, eta banderak bezeroari ematen dio lan hori, zuretzat ezer egin gabe.
Zer itzaltzen duen banderak konektatzean
Igotzen den OpenVPN bezeroak, normalean, autentifikazioaren ondoren zerbitzaritik sorta bat jasotzen du: ibilbideak, ate lehenetsiaren birbideraketa, DNS zerbitzariak eta doitze-zuzentarau batzuk. route-nopull indarrean dagoela, bezeroak saioa onartzen jarraitzen du, ziurtagiriak egiaztatzen jarraitzen du, zifratzeak eta keepalive-ak negoziatzen jarraitzen du, eta interfazea altxatzen jarraitzen du. Botatzen duena bidalitako route lerroen eta bidalitako dhcp-option lerroen aplikazioa da, DNS barne.
Nahastea aplikazio hildako baten ondoan dagoen adierazle berde batetik dator. Tunela existitzen da; helburuen eta tunel horren arteko mapaketa ez. Bezeroaren egoera-panelean ezerk ez du bereizten «konektatuta eta bideratzen» eta «konektatuta eta geldirik», tunelaren ikuspuntutik biak egoera bera baitira.
Zergatik tunel bizia ez den gai ezer bideratzeko
Interfazea bere helbidearekin agertzen da eta, puntutik punturako lotura batean, sarritan ez du parekidearekiko ostalari-ibilbidea baino zehatzago ezer. Azpisare pribatu bat iristeko modukoa da ibilbide batek interfaze horri aurrizki zuzenarekin seinalatzen dionean soilik, eta bidalketa desgaituta dagoela ibilbide hori ez da inoiz iristen. Deskargatutako profilak ere ezin du normalean lagundu, zerbitzariak informazio hori zehazki emango zuelakoan idatzi baitzen. Horregatik interfazea osasuntsu egon daiteke azpisarea ilun mantentzen den bitartean.
Beraz, profila irakurtzeak oso gutxi frogatzen du. Irakurri exekuzio-egoera, konektatutako makinan:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10
Bigarren komandoan azpisare-ibilbiderik gabeko helbidea arazo honen sinadura da. Hirugarren komandoak, orduan, erabiltzaileei benetan axola zaien galderari erantzuten dio, nukleoak helburu jakin baterako aukeratuko lukeen interfazea jakinarazten baitu, erabili nahi zenukeen zerrendaren ordez. Zure lotura fisikotik erantzuten badu, tunela ez dago bidean batere.
Izenen ebazpenak erlazionatutako arrazoi batengatik huts egiten du, ez arrazoi bereizi batengatik. Bidalitako dhcp-option DNS sarrerak bandera berak saltatzen ditu, beraz barne-ostalarien kontsultak sare lokalak eman duen ebazlera doaz. Ebazle horrek ez du bulegorako gunerik, beraz kontsultak huts egiten du edo erantzun publiko bat itzultzen du, eta hutsegitea zerbitzariaren arazo dirudi bezeroaren konfigurazioaren arazoa denean. Izen baten aurretik helbide bat probatzeak bereizten ditu biak.
Banderaren eta aurrizki-iragazki baten artean hautatzea
Bi aukerek kexa beraren forma desberdinak konpontzen dituzte, eta hautapen txarrak sortzen du konektatuta-baina-erabilgaitza egoera. Batek bidalitako politika oso-osorik ordezkatzen du, besteak aurrizkiz editatzen duen bitartean. Taulak bertsio laburra ematen du, eta ondorengo paragrafoak jendea harrapatzen duen zatia estaltzen du.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter hiru aditzeko aurrizki-konkordantzailea da, beraz lerro-familia bat onar dezake, isilean baztertu edo konexioa erabat ukatu dezake aurrizki bat agertzen denean. Azken jokabide hori da ezagutzea merezi duena: ukapen-arau batek politika-desadostasuna esku-emate huts bihurtzen du isiliko ez-egitearen ordez. OpenVPN 2.6 eskuliburuak onartutako aurrizkiak eta aditz bakoitzaren semantika zehatza zerrendatzen ditu.
Erdibide ohikoa redirect-gateway soilik ukatzea eta bulegoko ibilbideak eta DNS nahi bezala iristea da. Horrek bidalketa funtzionatzen mantentzen du zerbitzariak zu baino hobeto ulertzen dituen zatietarako, eta aldi berean galarazten du zure ibilbide lehenetsia hartuko lukeen lerro bakarra.
Ibilbideak eta ebazle bat eskuz gehitzea
Bandera mantentzen baduzu, profilak zerbitzariak esango zukeena esan behar du. Bezeroaren aldeko route zuzentarauak konexioa ezarri ondoren aplikatzen dira, beraz banderaren ondoan funtzionatzen dute, hark blokeatu beharrean. Jarri horiek profilean, ez komando-lerro interaktiboan, bestela hurrengo berrikonexioak ez du funtzionatzen duen egoera erreproduzituko.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53
DNS lerroa posizio deserosoan dago: bezeroaren aldeko zuzentaraua da, baina bezero batzuek plataformaren DNS integrazioaren bidez aplikatzen dute soilik, eta horrek gainidatzi dezake lotura aldatzen denean. systemd ostalari batean, ebazlea tunelaren interfazean zuzenean ezartzea aurreikusteko modukoagoa da bezeroak lehentasun-lehiaketa irabaziko duela espero baino:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com
Bideratze-domeinuak helbideak adina axola du. Hura gabe, izen publikoen kontsultak barne-ebazlera ere bidal daitezke, eta errekurtsioa ukatzen duen edozein barne-ebazlek nabigazioa hautsi eta gune pribatua funtzionatzen utziko du. Harekin, atzizki horren azpiko izenak bakarrik bideratzen dira tunel-ebazlera eta gainerako guztiak lotura fisikoari jarraitzen dio.
Emaitza egiaztatzea: helbidea, izena eta kanpoko bidea
Hiru probak bereizten dituzte hutsegite posibleak. Lortu helbide pribatua IPz, gero ostalari bera izenez, gero webgune publiko arrunta. Funtzionatzen duen IP batek izen hutsarekin ebazlera seinalatzen du; huts egiten duen IP batek izen funtzionalarekin bideratzera seinalatzen du; biek huts eginez gero, normalean tunela ez dago bidean.
Gero begiratu kanpora, ez barrura. Tunelaren muturraren ibilbide propioak aldaketari iraun behar dio, eta blokeatzen duen edozein hutsegite tunelera mugatu behar da muturra harrapatu gabe. Tunela erori ondoren nabigatzen jarraitzen duen bezeroa politika-arazoa da, ez bideratze-arazoa, eta ez da goiko hiru probetakoren batean ere agertuko.
Idatzi azken zerrenda profilaren dokumentazioan: ibilbideak, ebazlea, domeinuak eta bakoitza zergatik existitzen den. Taula bera erreproduzitzen duen berrikonexioa da tokiko politika osoa delako froga bakarra. Aplikazioek huts egiten badute tunela altxatuta eta hiru probak gaindituta, hurrengo begiratzeko lekua konektatuta-baina-lineaz-kanpo arazoen klasea da, jada egiaztatutako ziurtagiriak ez.