Divi OpenVPN tuneļi vienā Linux resursdatorā: kam pieder maršruts?

Divi profili ir savienoti, un viens no tiem klusi pārvadā satiksmi, kas paredzēta otram. Linux resursdators var vienlaikus bez grūtībām darbināt abus OpenVPN klientus. Ko tas nevar izdarīt, ir izlemt jūsu vietā, kurš process drīkst pieprasīt kuru prefiksu. Šis lēmums jāpieņem pirms otrā tuneļa pacelšanas, nevis pēc tam, kad kāds resurss pārstāj atbildēt.

Sāciet ar darbu, kas otrajam savienojumam jāveic

Birojs, kas sasniedzams caur vienu profilu, un laboratorija, kas sasniedzama caur citu, prasa abus tuneļus paceltus un nevienu no tiem nepieprasām visu. Vienai ietiepīgai programmai, kurai jāiziet caur otro profilu, vajadzīgs politikas noteikums, nevis otrs noklusējuma maršruts. Rezerves savienojumam vienlaikus vajadzīgs tikai viens darbojošs tunelis, tāpēc rezervei nevajadzētu startēt kopā ar mašīnu.

Tās ir trīs dažādas konfigurācijas, un tās tiek sajauktas, jo visas trīs sākas vienādi: otrs profils un veiksmīgs savienojums. Vispirms pierakstiet iecerēto izkārtojumu, pēc tam konfigurējiet uz to. Viens teikums par nodomu ietaupa stundu pakešu tveršanas.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Pirmā komanda uzskaita darbojošās instances, tostarp tās, kas palaistas ar roku ārpus pārvaldnieka. Otrā izdrukā pašreizējo noklusējuma pieprasījumu, un tas ir stāvoklis, kas jums vēlāk būs jāpaskaidro.

Pārklājošies baseini lūzt pirms maršrutēšanas

Divi serveri labprāt piešķirs adreses no tā paša 10.8.0.0/24. Tad klientam ir divas saskarnes vienā prefiksā, un nekas nepasaka, kura galamērķis pieder kurai, un iegūtā uzvedība izskatās pēc maršrutēšanas kļūdas, bet patiesībā tā ir numerācijas kļūda. Baseina pārnumurēšana izmaksā vienu konfigurācijas labojumu; katrs vēlākais maršrutēšanas apvedceļš izmaksā nedēļas nogali. Pārbaudiet baseinu pirms maršruta pievienošanas tam.

Apskatiet arī vietējo LAN. Mājas LAN ar numuru 192.168.1.0/24, ko atklāj arī viens tunelis, rada tādu pašu neskaidrību, un simptoms ir resursdatora nosaukums, kas tiek atrisināts, kamēr savienojums nekad netiek pabeigts. Tas izskatās pēc nosaukumu atrisināšanas kļūdas, līdz izdrukājat maršrutus.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Salīdziniet abas izejas ar abām servera konfigurācijām pirms klienta aizskaršanas. Ja prefiksi pārklājas, apstājieties un pārnumurējiet, jo neviens restartu skaits tos nešķirs.

Dodiet katram profilam savu vienību un katram prefiksam īpašnieku

Katrs profils iegūst savu instances nosaukumu un savu konfigurācijas failu, tāpēc instance ar nosaukumu office ielādē office.conf, bet lab ielādē lab.conf. Apstipriniet šo kartējumu caur pakalpojumu pārvaldnieku, nevis uzticoties direktorijas sarakstam, jo drop-in var mainīt, kurš fails tiek ielādēts. Nepareizs kartējums nozīmē, ka regulējat profilu, kas nedarbojas.

Pēc tam izlemiet, kas instalē maršrutus. Kad serveri sūta nesaderīgus kopumus, vai nu atsakieties no sūtīšanas un uzskaitiet prefiksus paši, vai ļaujiet vienam profilam saglabāt noklusējumu un virziet otru ar politikas noteikumiem. Divi procesi, kas abi instalē noklusējumu, beidzas ar klusu uzvarētāju un bez rakstiska lēmuma ieraksta.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Pirmā parāda vienību ar jebkuru pārrakstīšanu, kas maina tās argumentus. Otrā parāda, vai profils vispār pieņem nosūtītos maršrutus, un tas ir slēdzis, kas nosaka visu turpmāko.

Atzīmes notur atbildes uz saskarnes, no kuras tās nāca

Kad katrs tunelis apkalpo dažādus avotus, atbilde var iziet pa nepareizo saiti, un savienojums mirst pēc pirmās paketes. Modelis, kas notur, ir atzīmēt ienākošās paketes pēc ievades saskarnes, atjaunot šo atzīmi atbildē un dot katrai atzīmei tabulu ar savu noklusējuma vārteju.

Vaļīga apgrieztā ceļa filtrēšana parasti ir jāatslābina skartajām saskarnēm, jo atbilde likumīgi nāk pa saiti, kuru galvenā tabula nekad neizvēlētos. Turiet atzīmes šauras, lai tās nekad neuzķertu pašu tuneļu šifrēto satiksmi, kas tuneli sūtītu caur to pašu.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Izlasiet esošos noteikumus pirms vēl viena pievienošanas. Dublētas prioritātes un aizmirstas tabulas ir ierastais iemesls, kāpēc atzīmju politika šķiet pilnīgi neiedarbojoša.

Pierādiet izolāciju, apturot vienu savienojumu

Ar abiem tuneļiem paceltiem pierakstiet katras saskarnes adresi, maršrutu uz vienu resursdatoru aiz katra tuneļa un ceļu, ko izvēlas nesaistīts galamērķis. Lūdziet kodolam veikt meklēšanu, nevis lasiet vienu tabulu, jo viena tabula nekad neparāda galīgo lēmumu.

Pēc tam apturiet vienu instanci un vērojiet, kā tās saskarne un maršruti pazūd, kamēr otra turpina. Pārtraukums izdzīvojušajā nozīmē, ka abi joprojām dala ierīces nosaukumu, maršrutu vai ugunsmūra noteikumu, ko neviens nav atdalījis.

Atgrieziet apturēto profilu un atkārtojiet tos pašus pārbaudījumus. Kad tunelis izdzīvo tikai pirmo startu pēc pārstartēšanas, jūs redzat dzīves cikla defektu, nevis maršrutēšanas dizainu.