Serveris vai klients: kura OpenVPN vienība uz Pi ar divējādu lomu

Uz Pi darbojas divi OpenVPN procesi, kas vienlaikus pieņem klejojošus lietotājus un sasniedz augšupēju pakalpojumu sniedzēju, un tie gandrīz neko nedala, izņemot aparatūru. Viens klausās ienākošos tuneļus, otrs zvana uz āru. Katrs lasa savu direktoriju, un katram ir savs atteices režīms. Nepareizās vienības restartēšana ir visizplatītākais veids, kā klienta labojums tā vietā satricina klausītāju.

Saskaņojiet vienības nosaukumu ar direktoriju, kuru tā ielādē

Upstream 2.6 piegādā divas veidnes vienības, [email protected] un [email protected]. Servera veidne sākas /etc/openvpn/server un no turienes ielādē %i.conf. Klienta veidne sākas /etc/openvpn/client. Instance ar nosaukumu roaming var pastāvēt abās vietās vienlaikus, gan kā serveris, gan kā klients, ar divām nesaistītām konfigurācijām un bez jebkādas saites starp tām, izņemot virkni.

Jautājiet systemd, nevis failu sistēmai, jo pakotņu veidotāji pievieno papildu failus, kas var mainīt darba direktoriju vai argumentus, ko saņem binārais fails.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Pirmā komanda uzskaita katru izveidoto vienību, tostarp tās, kas neizdevās un palika ielādētas. Otrā izdrukā vienības failu kopā ar jebkuru pārrakstīšanu. Trešā ir ātrākais veids, kā redzēt divus faktus, kas izšķir jautājumu: direktoriju, kurā process sākas, un konfigurācijas ceļu, kas tam tika dots.

Izlemiet pēc pakešu virziena, nevis pēc saskarnes nosaukuma

Servera instancei pieder klausīšanās ligzda, un tā pieņem savienojumus. Tās šifrētais transports ir lokāla ievade un lokāla izvade uz Pi, bet trafiks, ko tā pārsūta lietotājiem, seko pārsūtīšanas ceļam un pakļaujas citai noteikumu kopai. Klienta instancei šajā nozīmē nav klausītāja: tā zvana partnerim, tāpēc tās šifrētais transports ir lokāla izvade uz apakšējo slāni.

Šī atšķirība pasaka, kur pieder noteikums. Noteikums, kas atbilst saskarnei pārsūtīšanas ķēdē, tikai atļauj trafiku, ko maršrutēšana jau izvēlējusies; tas nekad neizvēlas maršrutu. Kad klejojoša lietotāja paketes iziet pa nepareizo ceļu, pārbaudāmā ķēde ir forward, nevis output.

Apskatiet ligzdas pirms teorēšanas. Serveris, kas piesaistīts udp/1194, rāda klausīšanās ligzdu. Klients rāda asociāciju ar pakalpojumu sniedzēja adresi un neko, kas klausās.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Vienas instances noklusējuma maršruts var pārtvert otras atbildes

redirect-gateway, ko uzspiež augšupējais klients, instalē noklusējuma maršrutu, kas konkurē ar visu pārējo mašīnā, tostarp atbildēm, ko serveris sūta klejojošiem lietotājiem. OpenVPN izdara izņēmumu savai partnera adresei, lai tunelis paliktu sasniedzams, bet šis izņēmums neko nepasaka par telefonu viesnīcas tīklā.

Simptoms parasti ir asimetrisks. Rokasspiediens beidzas, klients ziņo par savienojumu, un trafiks mirst pēc pirmās atbildes paketes. Avotā balstīta politikas maršrutēšana vai pakešu atzīme, kas uzstādīta servera instancē ar --mark, tur divas plūsmas atsevišķi; neviens pats par sevi nav pilnīgs noteikumu kopums, un abiem vajadzīgi derīgi maršruti tabulā, ko tie izvēlas.

Pārbaudiet lokālo lēmumu, nevis tuneļa stāvokli, jo kodols izvēlas avotu un saskarni pirms tam, kad OpenVPN ierauga paketi.

ip route get 203.0.113.44
ip rule show

Restartējiet vienu lomu un pierādiet, ka otra izdzīvoja

Secība ir svarīga, ja abas lomas ir atkarīgas no viena un tā paša apakšējā slāņa. Vispirms restartējiet klientu, ja augšupējam maršrutam jāpastāv pirms lietotāju trafika pārsūtīšanas, un vispirms restartējiet serveri, ja maināt tikai tā klausītāju vai tā baseinu. Jebkurā gadījumā pēc tam apstipriniet abas vienības, jo neizdevies restarts var atstāt otru lomu darbojamies ar novecojušu stāvokli.

Pierakstiet apturēšanas nosacījumu pirms izmaiņām: vai augšupējā tuneļa zudums bloķē klejojošus lietotājus, vai arī atkrīt uz paša Pi augšupējo saiti? DNS un IPv6 arī vajag skaidru atbildi, jo uzspiests atrisinātājs bieži dzīvo ilgāk nekā maršruts, kas to padarīja noderīgu.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Pieņemiet izmaiņas tikai tad, kad trīs lietas ir spēkā vienlaikus: jauns ienākošs savienojums tiek pabeigts, pārsūtītā lietotne sasniedz galamērķi pa paredzēto izeju, un abi procesi joprojām ziņo par savu gaidīto partneri. Ja viens no trim neizdodas, jūs mainījāt nepareizo instanci vai nepareizo maršrutu, un nākamais solis ir vienību izlasīt vēlreiz, nevis restartēt ko citu.