Imel sem laboratorijski stroj, ki je sprejemal tunel z oddaljene lokacije in se hkrati povezoval v omrežje dobavitelja. Odhodni profil je deloval tedne. Po dodajanju vhodnega strežnika se je odhodni povezal in nato v nekaj sekundah prenehal prenašati promet, ali pa se ni hotel zagnati z napako, da je naslov že v uporabi. Konfiguracijske datoteke se niso spremenile; gostitelj je preprosto dobil drugi proces OpenVPN z lastnim mnenjem o vratih in poteh.

Napaka ni naključna in ni težava z overjanjem. Dva demona na enem stroju tekmujeta za isto lokalno vtičnico in isto usmerjevalno tabelo, in tisti, ki se zažene ali znova poveže zadnji, običajno zmaga. Vedeti, katera od teh dveh trkov imate, odloči, kam najprej pogledati.

Preberite simptom v obratni smeri

Začnite s tem, kdaj tunel umre. Napaka pri vezavi ob zagonu kaže na stran poslušanja: nekaj že ima ta vrata, in OpenVPN se noče zagnati, namesto da bi jih delil. Tunel, ki se dvigne in nato utihne, kaže na usmerjanje, ker lahko pot, ki jo namesti druga instanca, potegne pakete zunanje povezave z njihove poti.

Oba primera povzročita isto pritožbo uporabnika, zato zanke za ponovni poskus in skripti za nadzor ne popravijo ničesar. Odjemalca znova povežejo v isti konflikt. Prvo koristno vprašanje je, ali proces še teče, ko se promet ustavi.

Ena vtičnica in ena naprava na instance

Strežnik, ki posluša, veže svoja vrata; odhodni odjemalec prav tako potrebuje lokalna vrata za svoj zapakiran promet. Ko oba živita na istem gostitelju, lahko privzeto vedenje odjemalca trči ob vrata strežnika. Lokalna vrata odjemalca je mogoče pripeti, vezavo pa je mogoče preskočiti tam, kjer partner ne potrebuje stalnih izvornih vrat:

lport 1195
nobind
dev tun1

Te številke so primeri, ne zahteva. Pomembno je, da odjemalec preneha tekmovati za vrata strežnika in da vsaka instanca dobi ločeno tunelsko napravo. Dva demona, ki si delita tun0, si prepisujeta stanje naprave, tudi ko se njuna vrata razlikujejo, zato ena naprava na tunel ni izbirna.

nobind pripada odjemalski strani. Strežnik mora še vedno vezati in poslušati, zato vrstice ne kopirajte v konfiguracijo strežnika in ne onemogočite vezave na odjemalcu, katerega partner filtrira po stalnih izvornih vratih.

Izberite enega lastnika privzete poti

Samo ena povezava lahko namesti privzeto pot. Če oba profila preusmerita ves promet, druga povezava tiho zamenja prvo, in prva je videti pokvarjena. Bodisi obdržite odhodni tunel razdeljen in potiskajte samo predpone dobavitelja, bodisi mu dajte ločeno usmerjevalno tabelo.

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

Naslovi in številka tabele zgoraj so nadomestni znaki. Takoj po dodajanju pravila potrdite, da se lastni naslov strežnika VPN še vedno razrešuje prek običajne tabele; tabela, ki ujame zunanji transport, pokvari tunel, ki naj bi ga ščitila, in zanka za ponovno povezavo, ki sledi, je videti kot nezanesljiv ponudnik.

Za nastavitev, ki mora preživeti ponovne povezave in ponovne zagone, je omrežni imenski prostor trdnejša meja. Drugi odjemalec teče v svojem imenskem prostoru z lastnimi vmesniki in potmi, izpostavljene pa so le storitve, ki morajo prestopiti mejo. Gostitelj obdrži eno privzeto pot, in ponovna povezava imenskega prostora je ne more prepisati.

Preverjajte s tabelo, ne s statusno vrstico

Odjemalec, ki poroča, da je povezan, dokazuje samo svoj krmilni kanal. Zajemite stanje usmerjanja pred in po vsaki povezavi, nato vprašajte jedro, katero napravo bi uporabil resnični cilj:

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

Če se izbrana naprava za naslov dobavitelja spremeni, ko se zažene drugi tunel, imate trk poti. Če se oba procesa pojavita na istih lokalnih vratih, imate trk vtičnic. Popravljanje prvega brez drugega samo premakne napako na naslednjo ponovno povezavo.

Zapišite vrata, naprave, tabele in lastnika poti v runbook gostitelja. Sicer bo naslednja oseba, ki doda tretji tunel, znova odkrila isti trk, in edini vidni dokaz bo povezava, ki deluje, dokler se ne znova zažene demon nekoga drugega.

Sorodni članki