Divi OpenVPN klienti vienā Linux resursdatorā: kam pieder maršruts?
Divi klienti var dalīt resursdatoru, ja katram prefiksam ir īpašnieks. Izstaigājiet mērķi, baseinus, instanču nosaukumus un katra tuneļa apturēšanas testu — tieši šādā secībā.
Abi profili ziņo par savienojumu, un viens no tiem klusi pārsūta trafiku, kas paredzēts otram. Divi klienti vienā resursdatorā ir atbalstīts izvietojums; divi klienti bez īpašnieka katram prefiksam nav. Darbs mazāk saistīts ar otrā tuneļa pacelšanu un vairāk ar lēmumu, kurš process drīkst pieprasīt kuru maršrutu. Izstaigājiet zemāk doto secību, un konfigurācija izriet no atbildēm.
Sāciet ar jautājumu, kam paredzēts otrais tunelis
Trīs situācijas statusa rindā izskatās vienādi un prasa atšķirīgus risinājumus. Sadalījums pēc galamērķiem sūta vienu prefiksu caur biroja profilu, bet otru caur laboratorijas profilu, un neviens nepieprasa noklusējuma maršrutu. Sadalījums pēc lietojumprogrammas parasti patur vienu pilnu tuneli un konkrētu trafiku novirza ar politikas noteikumiem. Pārslēgšanās kļūmes gadījumā uztur tieši vienu tuneli vienlaikus, kas nozīmē, ka otrais nedrīkst startēt automātiski.
Pierakstiet gadījumu pirms jebkura konfigurācijas faila atvēršanas, jo šī atbilde nosaka visu pēc tam.
Biežākais salauztais izvietojums ir divi pilni tuneļi, kas abi izstūmuši noklusējuma maršrutu, kur uzvar pēdējais pievienojušais, bet pirmais turpina izlikties. Šis stāvoklis statusa rindā izskatās tīšs un izšķiež dienu no maršrutēšanas tabulas. Ja gadījumu nosauc vispirms, tas kļūst neiespējams, nevis tikai maz ticams.
Apskatiet baseinus pirms maršrutiem
Divi serveri viegli izsniedz adreses no viena privāta diapazona, un, kad to dara, klients paliek ar divām saskarnēm vienā prefiksā. Tad nevienu galamērķi nevar attiecināt uz saskarni pēc adreses, jo abas izskatās vienlīdz pareizas. Pārnumurējiet vienu baseinu, tā vietā lai izgudrotu noteikumu neizšķirta pārtraukšanai.
Pārbaudiet arī vietējo tīklu, jo mājas vai biroja LAN, kas pārklājas ar tuneļa diapazonu, rada tādu pašu neskaidrību no otras puses. Salīdziniet resursdatora adreses ar abām servera konfigurācijām, pirms vainojat klientu. Baseina maiņa laboratorijas serverī ir piecu minūšu labojums, savukārt politikas maršrutēšanas apvedceļš pārklājamam prefiksam ir pastāvīgs nodoklis ikvienam, kurš vēlāk lasīs konfigurāciju. Izlemiet, kuru no abiem vēlaties, pirms izvēlaties, kur iejaukties.
Divas adrešu saimes nozīmē divas šīs pārbaudes kārtas. IPv6 baseini saduras tikpat klusi kā IPv4.
Piešķiriet katram profilam īpašnieku
Viena instance uz profilu, viens konfigurācijas fails uz instanci un viens nosaukums, kas identificē pāri. Debian stila iepakojumā nosaukums pēc @ zīmes izvēlas failu, tāpēc divi profili, kas dala instances nosaukumu, nekad nevar strādāt abi. Apstipriniet kartējumu no instalētās vienības, nevis no apmācības.
systemctl cat [email protected]
ip -4 addr showPēc tam izlemiet, kas instalē maršrutus, un tas ir politikas, nevis sintakses jautājums.
Kad divi serveri izstumj nesaderīgus komplektus, vai nu pievienojiet route-nopull un uzskaitiet tikai tos prefiksus, kas nepieciešami katram profilam, vai arī ļaujiet vienam paturēt savu noklusējuma maršrutu un novirziet pārējo ar politikas noteikumu. Divi procesi, kas abi instalē noklusējuma maršrutu, beidzas ar vienu uzvarētāju, un neviens nevar pateikt, kāpēc. Kad divi tuneļi pārvadā trafiku no dažādiem avotiem, atbilde var iziet pa nepareizo, un modelis, kas iztur, ir savienojuma atzīme, kas tiek atjaunota uz atbildēm un novirzīta savā tabulā. Ierobežojiet atzīmes, lai pašu tuneļu šifrētās paketes nekad tām neatbilstu.
Pārbaudiet katru tuneli, tad apturiet vienu
Kad abi ir augšā, ņemiet trīs rādījumus: adresi katrā tuneļa ierīcē, maršrutu uz resursdatoru, kas dzīvo aiz katra, un ceļu, ko izvēlētos galamērķis ārpus abiem. Parasts maršrutu saraksts pārstāj aprakstīt galīgo meklēšanu, tiklīdz spēlē nāk noteikumi, tāpēc pajautājiet kodolam, ko tas patiešām izvēlētos. Pēc tam apturiet vienu instanci un skatieties, kas pazūd. Ja pirmā apturēšana traucē otrai, kaut kas starp tām joprojām ir kopīgs: maršruts, ierīces nosaukums vai ugunsmūra noteikums, ko neviens nav atdalījis.
ip rule show
ip route get 203.0.113.9Atgrieziet apturēto profilu un atkārtojiet tos pašus pārbaudes, jo tunelis, kas pēc pārstartēšanas strādā vienu reizi un vairs nekad, ir dzīves cikla kļūda maršrutēšanas kostīmā.
Ierakstiet izvietošanas piezīmēs, kuram profilam pieder kurš prefikss, blakus baseinu diapazoniem. Divi tuneļi ir apzināts izvietojums, un nākamajam lasītājam ir jāredz robeža, pirms pieskarties jebkuram profilam. Bez šīs piezīmes robežu no jauna atklāj tas, kurš ir dežūrā, kad kopīgais prefikss beidzot saplīst.