OpenVPN bezeroa blokeatzen da bere zerbitzaria host berean exekutatzen denean

Laborategiko makina bat nuen, urruneko gune batetik tunel bat onartzen zuena eta, aldi berean, hornitzaile baten sarera deitzen zuena. Irteerako profilek asteak zeramatzan lanean. Sarrerako zerbitzaria gehitu ondoren, irteerakoa konektatu eta segundo batzuetan zehar trafikoa pasatzeari utzi zion, edo helbidea erabilian dagoelako errorearekin abiarazteari uko egin zion. Konfigurazio-fitxategiak ez ziren aldatu; hostak OpenVPN prozesu bigarren bat besterik ez zuen lortu, portuei eta bideei buruzko bere iritziarekin.

Hutsegitea ez da ausazkoa, eta ez da autentifikazio-arazo bat. Makina bateko bi daemonek socket lokal beraren eta bideratze-taula beraren alde lehiatzen dute, eta azkenik abiarazten edo berriz konektatzen denak irabazi ohi du. Bi talka horietatik zein duzun jakiteak erabakitzen du non begiratu lehenik.

Irakurri sintoma atzerantz

Hasi tuneleko hiltzen den unetik. Abiaraztean bind errore batek entzuten ari den aldera seinalatzen du: zerbait dagoeneko portu horren jabe da, eta OpenVPN abiarazteari uko egiten dio partekatu beharrean. Altxatzen eta gero isiltzen den tunel batek bideratzeari seinalatzen dio, beste instantziak instalatutako bide batek kanpoko konexioaren paketeak haien bidetik atera baititzake.

Bi kasuek erabiltzailearen kexa bera sortzen dute, eta horregatik berriro saiatzeko begiztek eta zaintza-scriptek ez dute ezer konpontzen. Bezeroa gatazka berera berriz konektatzen dute. Lehen galdera erabilgarria da prozesua oraindik exekutatzen ari den trafikoa gelditzen denean.

Socket bat eta gailu bat instantzia bakoitzeko

Entzuten ari den zerbitzari batek bere portua lotzen du; irteerako bezero batek ere portu lokal bat behar du bere trafiko kapsulatuarentzat. Biak host berean bizi direnean, bezeroaren portaera lehenetsiak zerbitzariaren portuarekin talka dezake. Bezeroaren portu lokala finka daiteke, eta lotzea saltatu daiteke pareak jatorrizko portu finkorik behar ez duenean:

lport 1195
nobind
dev tun1

Zenbaki horiek adibideak dira, ez baldintza. Garrantzitsua da bezeroak zerbitzariaren portuaren alde lehiatzeari uztea eta instantzia bakoitzak tunel-gailu bereizi bat lortzea. tun0 partekatzen duten bi daemonek elkarren gailu-egoera gainidazten dute, haien portuak desberdinak izan arren, beraz tunel bakoitzeko gailu bat ez da hautazkoa.

nobind bezeroaren alderdiari dagokio. Zerbitzariak oraindik lotu eta entzun behar du, beraz ez kopiatu lerroa zerbitzariaren konfigurazioan, eta ez desgaitu lotzea pareak jatorrizko portu finkoaren arabera iragazten duen bezero batean.

Aukeratu jabe bakarra bide lehenetsirako

Konexio bakarrekoak soilik instala dezake bide lehenetsi bat. Bi profilek trafiko guztia birbideratzen badute, bigarren konexioak lehenengoa isilka ordezkatzen du, eta lehenengoa hautsita ematen du. Edo mantendu irteerako tunela zatituta eta bultzatu hornitzailearen aurrizkiak soilik, edo eman bideratze-taula bereizi bat.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Goiko helbideak eta taula-zenbakia leku-markak dira. Araua gehitu eta berehala, egiaztatu VPN zerbitzariaren beraren helbidea oraindik taula arruntaren bidez ebazten dela; kanpoko garraioa harrapatzen duen taula batek babestu behar zuen tunela hausten du, eta ondorengo berriz konektatzeko begiztak hornitzaile fidagarritasun gutxiko baten itxura ematen du.

Berriz konektatzei eta berrabiaraztei eusteko konfigurazio baterako, sare-namespace bat da muga sendoena. Bigarren bezeroa bere namespace propioan exekutatzen da, bere interfaze eta bideekin, eta muga zeharkatu behar duten zerbitzuak soilik uzten dira agerian. Hostak bide lehenetsi bat mantentzen du, eta namespace baten berriz konektatzeak ezin du hura berridatzi.

Egiaztatu taularekin, ez egoera-lerroarekin

Konektatuta dagoela jakinarazten duen bezero batek bere kontrol-kanala soilik frogatzen du. Erregistratu bideratze-egoera konexio bakoitzaren aurretik eta ondoren, eta gero galdetu kernelari zein gailu erabiliko lukeen benetako helmuga batek:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Hornitzailearen helbiderako hautatutako gailua bigarren tunela abiaraztean aldatzen bada, bideen talka duzu. Bi prozesuak portu lokal berean agertzen badira, socketen talka duzu. Lehenengoa bigarrena gabe konpontzeak hutsa hurrengo berriz konektatzera besterik ez du eramaten.

Idatzi portuak, gailuak, taulak eta bidearen jabea hostaren runbookean. Bestela, hirugarren tunel bat gehitzen duen hurrengo pertsonak talka bera berraurkituko du, eta froga ikusgai bakarra beste norbaiten daemona berrabiarazi arte funtzionatzen duen konexio bat izango da.