Zergatik hausten du bigarren VPN tunel batek lehenengoa?

Bezero-sare batera iristeko bigarren VPN bezero bat instalatzea da hau hasteko ohiko modua, eta lehen tunela iluntzen da bi bezeroek arrakasta jakinarazten duten bitartean. Bezero bakoitzak bide lehenetsi bat instalatu zuen, bigarrena zehatzagoa zen, eta kernela orain hari jarraitzen dio lehen tunelaren kanpoko konexioa izan ezik guztiarentzat. Ezer ez zen erori eta ez dago profil okerrik. Bide batek beste bat ordezkatu zuen, eta konponbidea lehenetsia zein tuneli dagokion erabakitzea da.

Sintoma: bigarren bezeroak isilka irabazten du

OpenVPN: redirect-gateway def1 aukerak ez du 0.0.0.0/0 gainidazten. 0.0.0.0/1 eta 128.0.0.0/1 gehitzen ditu: elkarrekin IPv4 helbide guztiak hartzen dituzte, eta prefijo bakoitzak bide lehenetsi soil bat gainditzen du luzeran. Jatorrizko bide lehenetsia taulan geratzen da eta ez da trafiko arrunterako erabiltzen, eta VPN zerbitzarirako host bideak tunela bere kanpoko paketeak harrapatzetik babesten du. Bi bezeroek egiten dute hori, eta bigarrenak bere bikotea geroago instalatzen du besterik gabe.

Horregatik lehen tunela hilda dirudi deskonektatuta egon beharrean. Bere interfazea aktibo dago, kontrol kanala bizirik, eta ez dio aplikazio trafikorik heltzen jada. Aurkako kexak falta den push berbera du: konektatzen den baina ezer bidaltzen ez duen telefono batek normalean redirect-gateway inoiz iragarri ez zuen zerbitzari batekin hitz egiten du, beraz gailuak bere lehenetsia mantentzen du eta igerilekura soilik iristen da.

Egin bideen argazki bat bigarren bezeroa konektatu aurretik eta ondoren. Taulan agertzen diren bi erdi-bideek osatzen dute aldaketa osoa, eta bi kexak azaltzen dituzte. Taulan beste ezerk ez du mugitu behar sintoma agertzeko. Horregatik bigarren bezeroa kentzeak lehenengoa berehala leheneratzen du.

Irakurri zein tunel irabazten duen benetan

Ez ondorioztatu irabazlea bezeroak hasi ziren ordenatik ezta erretiluko ikonotik ere. Galdetu kernelari bi sare pribatuetatik kanpoko helmuga baterako zein bide erabiliko lukeen, eta irakurri itzultzen den interfazea.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Lehen biak Linuxen erantzuna dira eta azken biak Windowsen baliokidea. Exekutatu itzazu bi tunelak aktibo daudela, gero deskonektatu bat eta exekutatu berriro. Bi irteeren arteko aldea konponbide bat aukeratu aurretik behar duzun egitatea da, eta edozein bezeroren erregistroa irakurtzea baino denbora gutxiago hartzen du.

Erregistratu emaitza, interfazearen izena eta bat etorri den prefijoa barne. Bigarren VPNk lehenengoa hautsi zuela dioen txartela sintomaren deskribapena da, ez inork jardun dezakeen bideratze-adierazpena. Bilaketak hurrengo ingeniariak komando bakarrean erreproduzi dezakeen egitate bihurtzen du.

Windows: eragotzi profil batek lehenetsia edukitzea

Windowsk gordetako profilak mantentzen ditu, eta klients integratuak bati bestearen mende egoteko aukera ematen dio, bigarrena markatzean lehena automatikoki altxa dadin. Azkenik konektatu den profila izan ohi da lehenetsia mantentzen duena, beraz jabari praktikoa azken markatzea da, ez lehena. Eman profil bakoitzari bere push bideak eta aktibatu tunel zatitua lehenetsia eduki behar ez duenarentzat.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Tunel zatituak hori aldatzen du: zerbitzariak bultzatutako prefijoak soilik iristen dira taulara, eta horrek lehen tunelari uzten dio lehenetsia. Diseinuak huts egiten du oraindik bi zerbitzariek bide lehenetsi bat bultzatzen badute, orduan azken konexioak irabazten baitu eta bezero aldeko ezarpen batek ere ez du hori aldatzen. Konpondu zerbitzari aldeko pusha edo onartu jabari bakarra.

Aplikazioek abiarazitako profilak beste funtzio bat dira eta merezi du jakitea: Windows profil bat exekutagarri izendatu bat abiatzean has daiteke, trafiko iragazkiek zer daraman erabakita. Profil ezarpena da eta ez suebaki araua, eta lehenetsitako bidearen gatazkatik desberdina den arazo bat konpontzen du.

Linux: eduki bigarren tunela taula nagusitik kanpo

Makinela bakarrean bi openvpn --config instantzia exekutatzeak bi bezeroak taula berean jartzen ditu, eta hiru aukerek gero eta isolamendu handiagoz bereizten dituzte. Arinena bigarren bezeroak taula batere editatu ez dezan eragoztea da: route-nopull bide esplizituekin, edo route-up script bat zuk nahi duzuna soilik instalatzen duena. Orduan bigarren tunelak izendatzen dituzun prefijoak zehazki daramatza eta besterik ez. Orduan zuk erabakitzen duzu zein prefijo norantz doan, geroago deskubritu beharrean.

Politika bideratzea erdiko aukera da. Arau batek taula bereizi bat hautatzen du iturburu helbide bakar baterako edo suebaki marka baterako, eta taula horrek bigarren tunelaren bideak daramatza. Alderantzizko bidearen iragazketa tranpa da hemen, taulak hautatuko lukeen interfaze desberdinean iristen den erantzuna baztertu egiten baita, beraz egiaztatu rp_filter ezarpena tunela hondatuta dagoela ondorioztatu aurretik.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Sare izen-espazioak aukera astunena eta garbiena dira. Abiarazi bigarren bezeroa ip netns barruan, eman veth pare bat, eta sartu izen-espazio horretan erabiltzeko. Interferentzia desagertzen da izen-espazio bakoitzak bere taulak baititu bat partekatu beharrean, eta hori merezi du ezarpen gehigarriak bi tunelak astez aktibo egon behar dutenean.

Aplikazio bakoitzeko, eta kateatzea arazo bereizi gisa

Batzuetan programa bakar batek erabili beharko luke bigarren tunela. Linuxen, erabiltzaile, cgroup edo portu bidezko politika bideratzeak lortzen du emaitza hori, eta helmuga bakarra interfaze batera lotu daiteke lehenetsia batere ukitu gabe. Bere socket-a interfaze bakar batera lotzen duen aplikazioak ez du bideratze taulari batere kontsultatzen, beraz abiarazleak egokitzaile fisikoa erabiltzen jarrai dezake bere ezarpenetan helbide bat aukeratu arte.

Kateatzea bi tunel elkarren ondoan exekutatzea baino eragiketa desberdina da. A B-ren gainetik kateatzeak esan nahi du barneko zerbitzariaren helbidea kanpoko tunelaren barrutik irisgarria izan behar dela. Kanpoko bezeroak ere ez du barneko bezeroaren pakete zifratuak isuri gisa hartu behar. Bezero bat makina birtual baten barruan bertsio zakar baina fidagarria da; biak host berean egoteko goiko bideratze lana behar da gehi barneko zerbitzarirainoko kanpoko bide bat barne tunelera inoiz sartzen ez dena.

Idatzi lehenetsiaren jabea, tunel bakoitzak daraman prefijo zerrenda eta DNS bidea. Hiru egitate horiek hurrengo gertaera ikerketa bat izan beharrean bilaketa bat bihurtzen dute.