Nola bidali IPv4 helmuga bat OpenVPN tunel batetik kanpora

Tunel osoaren ezarpen gehienek pakete guztiak VPN bidez bidaltzen dituzte, eta redirect-gateway da hori posible egiten duen direktiba. Helmuga bakar bat oraindik salbuets daiteke. Helbide horretarako host bide bat gehitzeak net_gateway leku-markarekin esaten dio bezeroari makinaaren jatorrizko atebidearen bidez irits dadila, eta gainerako guztiak tunela erabiltzen jarraitzen du.

Lerroa kaltegabetzat ematen du eta askotan hala da, baina galdera bakarra konpontzen du: IPv4 helbide zehatz horretarako paketeak nora doazen. Ez du DNSa, IPv6a, suebakiaren politika edo konexioa zein prozesuk ireki zuen aldatzen, eta horietako bakoitzak isilpean deusezta dezake salbuespena.

Zer izendatzen du net_gatewayk benetan

Salbuespen horretarako profileko sarrera lerro bakarra da: route 198.51.100.77 255.255.255.255 net_gateway. Lehen helbidea helmugarako dokumentazio leku-marka da, maskarak host bakarreko bide bihurtzen du, eta azken tokenak atebidearen leku-marka izendatzen du. OpenVPN tresnak atebide leku-markak ebazten ditu bideak instalatzen dituenean. vpn_gateway tunelaren beraren atebidea esan nahi du, VPN loturaren urruneko aldea. net_gateway VPNak ezer aldatu aurretik ostalariak zuen atebide lehenetsia esan nahi du, normalean sare fisikoko router lokala.

Hirugarren leku-marka batek, remote_host delakoak, VPN zerbitzariaren helbidea adierazten du, eta tunelak zerbitzarira bide fisikoan iritsi ahal izateko dago. Hiru hauek nahastea da salbuespen bat leku okerrean amaitzeko edo batere instalatu ez izateko arrazoi ohikoena.

Balioa konektatzean irakurtzen da, ez da fitxategian idazten. Makakina beste sare batera mugitzen bada, VPN aurreko atebidea aldatzen da eta bideak berriari jarraitzen dio. Hori da normalean nahi duzuna, baina salbuespenaren portaera bezeroa abiatu zen sarearen araberakoa dela esan nahi du.

Zergatik irabazten dion host bide batek tunelaren bide lehenetsiari

Bideratzea aurrizki bateragarririk zehatzenak erabakitzen du. redirect-gateway def1 ez du normalean bide lehenetsia ordezkatzen; bi erdi gehitzen ditu, helbide-espazioaren beheko erdiarentzako bide bat eta goiko erdiarentzako beste bat, jatorrizko bide lehenetsia beste erabilera batzuetarako gorde dadin. Erdi horiek helbide bakar bat baino zabalagoak dira.

Helbide baterako bidea 255.255.255.255 maskararekin /32 bat da, eta IPv4k irits dezakeen zehaztasun handiena da. Helbide horretarako pakete bat ebaluatzen denean, /32ak bat egiten du eta irabazi egiten du bide bat lehenago instalatu izanaz independente. Hori da salbuespenaren atzeko mekanismoa, eta berdin funtzionatzen du Linux, macOS eta Windowsen, bidea benetan badago betiere.

Windowsek bigarren dimentsio bat gehitzen du. Bi bide berdin zehatzak direnean, metrika txikiagoa duenak irabazten du, eta VPN egokitzaileak emaitza aldatzen duen interfaze-metrika izan dezake. /32ak oraindik erdiak baino zehatzagoa da, beraz salbuespenak normalean eusten du, baina aurreko saio bateko bide zaharkitu batek emaitza nahasia eman dezake berdin zehatza bada.

Salbuespenak estaltzen ez duena

DNS da lehen hutsunea. Bezeroak barne-ebazlearen ezarpenak bultzada ditzake, eta sistema eragileak horiek erabiltzen jarraituko du kontsultetarako. Konektatu aurretik izen bat ebazten duen aplikazio batek barne-helbide bat jaso dezake zuzen joan beharko lukeen zerbitzu baterako, edo kanpo-helbide bat, zuzen ebazten dena baina gero hurrengo hutsunean estropezu egiten duena.

IPv6 da bigarrena. Bide direktibak IPv4 baino ez du kudeatzen. Pila biko helmuga batek IPv6 lehenets dezake, eta horrek tunela edo ostalariaren IPv6 bide lehenetsia jarraitzen du politikaren arabera, beraz IPv4 salbuespena ez da inoiz aktibatzen. IPv6 bide egoki bat behar duzu, edo bezero horretarako IPv6 desgaitzeko erabaki kontzientea.

Aplikazio-esparrua da hirugarrena. Araua helmugan oinarrituta dago, beraz helbide horretara konektatzen den prozesu bakoitzak bide zuzena erabiltzen du, zure asmoa dena izan ala ez. Alderantziz, webgune batek hainbat helbidetatik erantzun dezake, beraz /32 bat salbuesteak ez du gunea salbuesten. Benetako eskakizuna aplikazio bakoitzeko bideratzea bada, Community bezeroaren bide-taula da tresna okerra.

Salbuespena zeure burua engainatu gabe egiaztatzea

Hasi instalatutako bidearekin, ez nabigatzaile batekin. Linuxen, galdetu kernelari zein bide eta hurrengo jauzi erabiliko dituen helbide zehatzerako; Windowsean, irakurri /32 horretarako bide-taula. Egiaztatu atebidea fisikoa dela, ez tunela. Sarrera falta bada, profila ez zen aplikatu edo bezeroak ez zuen bideak aldatzeko pribilegiorik.

Gero probatu bi helmuga. Salbuetsitako helbiderako eskaera interfaze fisikotik atera beharko litzateke, eta kontrol barne-helbide baterako eskaerak tunela erabiltzen jarraitu beharko luke. Salbuetsitako helbidea soilik probatzeak ez du ezer frogatzen tunelaren gainerakoaz, eta webgune publiko bat probatzeak gune horrek ebatzitako helbidea probatzen du, agian arauan dagoena ez dena.

Azkenik, bidea gaindi dezaketen kontrolak egiaztatu. Bezeroaren aldeko kill switch batek edo Windowseko block-outside-dns ezarpen batek zuzeneko trafikoa debeka dezake, eta hori bidea zuzena den arren huts egiten duen konexio gisa agertzen da. Ez itzali kontrol horiek salbuespena funtzionatzen duela emateko; politikak bide zuzena debekatzen badu, salbuespena diseinu-arazoa da VPN zerbitzuaren jabearentzat.

Berrikusi berriz konektatu edo sarea aldatu ondoren, VPN aurreko atebidea eta eskuragarri dagoen bidea momentuaren ezaugarriak baitira, ez profilarenak.