OpenVPN-asiakasohjelma pysähtyy, kun sen palvelin toimii samalla isännällä

Minulla oli laboratoriokone, joka otti vastaan tunnelin etäsivustolta ja soitti myös ulos toimittajan verkkoon. Lähtevä profiili oli toiminut viikkoja. Kun saapuva palvelin lisättiin, lähtevä yhdisti ja lakkasi sitten välittämästä liikennettä sekunneissa tai kieltäytyi käynnistymästä osoite-jo-käytössä-virheellä. Asetustiedostot eivät olleet muuttuneet; isäntä oli yksinkertaisesti saanut toisen OpenVPN-prosessin, jolla oli oma mielipiteensä porteista ja reiteistä.

Vika ei ole satunnainen, eikä se ole todennusongelma. Kaksi taustapalvelua yhdellä koneella kilpailevat samasta paikallisesta pistokkeesta ja samasta reititystaulusta, ja se, joka käynnistyy tai yhdistää uudelleen viimeisenä, yleensä voittaa. Tieto siitä, kumpi näistä kahdesta törmäyksestä sinulla on, ratkaisee, mistä katsoa ensin.

Lue oire takaperin

Aloita siitä, milloin tunneli kuolee. Sidontavirhe käynnistyksessä osoittaa kuuntelevaan puoleen: jokin omistaa jo tuon portin, ja OpenVPN kieltäytyy käynnistymästä sen jakamisen sijaan. Tunneli, joka nousee ja sitten vaikenee, osoittaa reititykseen, koska toisen instanssin asentama reitti voi vetää ulomman yhteyden paketit pois reitiltään.

Molemmat tapaukset tuottavat saman käyttäjävalituksen, minkä vuoksi uudelleenyrityssilmukat ja vahtikoiraskriptit eivät korjaa mitään. Ne yhdistävät asiakkaan uudelleen samaan ristiriitaan. Hyödyllinen ensimmäinen kysymys on, onko prosessi vielä käynnissä, kun liikenne pysähtyy.

Yksi pistoke ja yksi laite instanssia kohden

Kuunteleva palvelin sitoo porttinsa; lähtevä asiakas tarvitsee myös paikallisen portin kapseloidulle liikenteelleen. Kun molemmat elävät samalla isännällä, asiakkaan oletuskäyttäytyminen voi törmätä palvelimen porttiin. Asiakkaan paikallinen portti voidaan kiinnittää, ja sidonta voidaan ohittaa, kun vastapuoli ei tarvitse kiinteää lähdeporttia:

lport 1195
nobind
dev tun1

Nuo luvut ovat esimerkkejä, eivät vaatimus. Tärkeää on, että asiakas lakkaa kilpailemasta palvelimen portista ja että jokainen instanssi saa erillisen tunnelilaitteen. Kaksi taustapalvelua, jotka jakavat tun0-laitteen, kirjoittavat toistensa laitetilan yli, vaikka niiden portit eroaisivat, joten yksi laite tunnelia kohden ei ole valinnainen.

nobind kuuluu asiakaspuolelle. Palvelimen on edelleen sidottava ja kuunneltava, joten älä kopioi riviä palvelimen asetukseen äläkä poista sidontaa käytöstä asiakkaalla, jonka vastapuoli suodattaa kiinteän lähdeportin perusteella.

Valitse oletusreitille yksi omistaja

Vain yksi yhteys voi asentaa oletusreitin. Jos molemmat profiilit uudelleenohjaavat kaiken liikenteen, toinen yhteys korvaa ensimmäisen hiljaa, ja ensimmäinen näyttää rikkoutuvan. Joko pidä lähtevä tunneli jaettuna ja työnnä vain toimittajan etuliitteet, tai anna sille erillinen reititystaulu.

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

Yllä olevat osoitteet ja taulun numero ovat paikkamerkkejä. Vahvista heti säännön lisäämisen jälkeen, että VPN-palvelimen oma osoite ratkeaa edelleen normaalin taulun kautta; taulu, joka kaappaa ulomman kuljetuksen, rikkoo tunnelin, jota sen oli tarkoitus suojella, ja sitä seuraava uudelleenyhdistämissilmukka näyttää epäluotettavalta palveluntarjoajalta.

Asetukselle, jonka on kestettävä uudelleenyhdistämiset ja uudelleenkäynnistykset, verkkonimiavaruus on vankempi raja. Toinen asiakas toimii omassa nimiavaruudessaan omine liitäntöineen ja reitteineen, ja vain rajapinnan ylittävät palvelut paljastetaan. Isäntä pitää yhden oletusreitin, eikä nimiavaruuden uudelleenyhdistäminen voi kirjoittaa sitä uudelleen.

Tarkista taulusta, älä tilapalkista

Asiakas, joka ilmoittaa olevansa yhteydessä, todistaa vain ohjauskanavansa. Tallenna reititystila ennen ja jälkeen jokaisen yhteyden, kysy sitten ytimeltä, mitä laitetta todellinen kohde käyttäisi:

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

Jos toimittajan osoitteelle valittu laite vaihtuu toisen tunnelin käynnistyessä, sinulla on reittitörmäys. Jos molemmat prosessit näkyvät samassa paikallisessa portissa, sinulla on pistoketörmäys. Ensimmäisen korjaaminen ilman toista siirtää vain vian seuraavaan uudelleenyhdistämiseen.

Kirjoita portit, laitteet, taulut ja reitin omistaja isännän runbookiin. Muuten seuraava henkilö, joka lisää kolmannen tunnelin, löytää saman törmäyksen uudelleen, ja ainoa näkyvä todiste on yhteys, joka toimii, kunnes jonkun toisen taustapalvelu käynnistyy uudelleen.