OpenVPN klients apstājas, kad tā serveris darbojas tajā pašā resursdatorā

Man bija laboratorijas dators, kas pieņēma tuneli no attālas vietas un arī zvanīja uz piegādātāja tīklu. Izejošais profils bija darbojies nedēļām. Pēc ienākošā servera pievienošanas izejošais savienojās un pēc tam dažu sekunžu laikā pārstāja pārvadīt datplūsmu, vai atteicās startēt ar kļūdu, ka adrese jau tiek izmantota. Konfigurācijas faili nebija mainījušies; resursdators vienkārši ieguva otru OpenVPN procesu ar savu viedokli par portiem un maršrutiem.

Kļūme nav nejauša, un tā nav autentifikācijas problēma. Divi dēmoni vienā mašīnā sacenšas par to pašu lokālo ligzdu un to pašu maršrutēšanas tabulu, un tas, kas startē vai atkārtoti pievienojas pēdējais, parasti uzvar. Zināšana, kura no šīm divām sadursmēm jums ir, nosaka, kur skatīties vispirms.

Lasiet simptomu otrādi

Sāciet ar to, kad tunelis mirst. Saistīšanas kļūda startēšanas laikā norāda uz klausīšanās pusi: kaut kas jau pieder šim portam, un OpenVPN atsakās startēt, nevis dalīties ar to. Tunelis, kas paceļas un pēc tam apklust, norāda uz maršrutēšanu, jo otras instances instalētais maršruts var novilkt ārējā savienojuma paketes no to ceļa.

Abi gadījumi rada vienu un to pašu lietotāja sūdzību, tāpēc atkārtošanas cilpas un uzraudzības skripti neko nelabo. Tie atkal pievieno klientu tajā pašā konfliktā. Pirmais lietderīgais jautājums ir, vai process joprojām darbojas, kad datplūsma apstājas.

Viena ligzda un viena ierīce katrai instancei

Klausīšanās serveris saista savu portu; izejošajam klientam arī vajadzīgs lokālais ports tā iekapsulētajai datplūsmai. Kad abi dzīvo vienā resursdatorā, klienta noklusējuma uzvedība var sadurties ar servera portu. Klienta lokālo portu var piespraust, un saistīšanu var izlaist tur, kur partnerim nav vajadzīgs fiksēts avota ports:

lport 1195
nobind
dev tun1

Šie skaitļi ir piemēri, nevis prasība. Svarīgi ir tas, ka klients pārstāj sacensties par servera portu un katra instance iegūst atsevišķu tuneļa ierīci. Divi dēmoni, kas dala tun0, pārraksta viens otra ierīces stāvokli pat tad, ja to porti atšķiras, tāpēc viena ierīce uz tuneli nav izvēles iespēja.

nobind pieder klienta pusei. Serverim joprojām ir jāsaista un jāklausās, tāpēc nekopējiet rindu servera konfigurācijā un neizslēdziet saistīšanu klientā, kura partneris filtrē pēc fiksēta avota porta.

Izvēlieties vienu noklusējuma maršruta īpašnieku

Tikai viens savienojums var instalēt noklusējuma maršrutu. Ja abi profili novirza visu datplūsmu, otrais savienojums klusi aizstāj pirmo, un pirmais izskatās salūzis. Vai nu paturiet izejošo tuneli sadalītu un spiediet tikai piegādātāja prefiksus, vai piešķiriet tam atsevišķu maršrutēšanas tabulu.

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

Iepriekš minētās adreses un tabulas numurs ir vietturi. Tūlīt pēc noteikuma pievienošanas apstipriniet, ka paša VPN servera adrese joprojām tiek atrisināta caur parasto tabulu; tabula, kas pārtver ārējo transportu, salauž tuneli, kuru tai vajadzēja aizsargāt, un tam sekojošā atkārtotās pievienošanās cilpa izskatās kā neuzticams pakalpojumu sniedzējs.

Iestatījumam, kam jāiztur atkārtotas pievienošanās un pārstartēšanas, tīkla nosaukumvieta ir stingrāka robeža. Otrais klients darbojas savā nosaukumvietā ar saviem interfeisiem un maršrutiem, un tiek atklāti tikai tie pakalpojumi, kuriem jāšķērso robeža. Resursdators patur vienu noklusējuma maršrutu, un nosaukumvietas atkārtota pievienošanās to nevar pārrakstīt.

Pārbaudiet ar tabulu, nevis ar statusa rindu

Klients, kas ziņo, ka ir pievienots, pierāda tikai savu vadības kanālu. Fiksējiet maršrutēšanas stāvokli pirms un pēc katras pievienošanās, pēc tam pajautājiet kodolam, kuru ierīci izmantotu īsts galamērķis:

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

Ja izvēlētā ierīce piegādātāja adresei mainās, kad startē otrais tunelis, jums ir maršrutu sadursme. Ja abi procesi parādās tajā pašā lokālajā portā, jums ir ligzdu sadursme. Pirmā labošana bez otrā tikai pārvieto kļūmi uz nākamo atkārtoto pievienošanos.

Ierakstiet portus, ierīces, tabulas un maršruta īpašnieku resursdatora runbook. Pretējā gadījumā nākamais cilvēks, kas pievienos trešo tuneli, atkal atklās to pašu sadursmi, un vienīgais redzamais pierādījums būs savienojums, kas darbojas, līdz kāds cits pārstartē savu dēmonu.