Savienot divus OpenVPN klientus vienā Linux resursdatorā ar fwmark

Otra OpenVPN klienta pievienošana vienā Linux resursdatorā neizdodas vienā no divām vietām. Vai nu iekšējais klients nevar sasniegt savu serveri, jo ārējais tunelis ir pārņēmis šo transportu, vai nu otrais klients pārraksta maršrutu tabulu un pirmais tunelis pārstāj darboties. Abas problēmas ir maršrutēšanā, nevis šifrēšanā, un abas tiek atrisinātas pirms jaunais tunelis pārvadā jebkuru lietojumprogrammu datplūsmu. Šeit adreses ir ilustratīvas: tun0 ir ārējais tunelis, 203.0.113.9 ir iekšējais serveris, un TCP 9999 ir plūsma, kurai jāizmanto iekšējais ceļš.

Divi atteices režīmi, viena maršrutu tabula

Iekšējais klients atver UDP ligzdu uz savu serveri, un šī ligzda seko pašreizējai maršrutu tabulai tāpat kā jebkura cita. Ja ārējais tunelis jau pārvalda noklusējuma maršrutu, rokasspiediena paketes nonāk ārējā tunelī. Tas darbojas tikai tad, kad ārējais serveris var sasniegt iekšējo serveri un otrā puse piekrīt pārvadāt plūsmu; citādi rokasspiediens apstājas un klients mēģina vēlreiz.

Otrā atteice nāk no servera push. Parastais push ir redirect-gateway def1, kas instalē 0.0.0.0/1 un 128.0.0.0/1, nevis aizstāj noklusējuma maršrutu. Tāpēc divi klienti, no kuriem katrs instalē savu /1 pāri, saduras, un jaunākais pāris uzvar gandrīz katram galamērķim. Meklējiet šos divus prefiksus tabulā, kad tunelis mirst pēc tam, kad otrais ir pievienojies, jo pats noklusējuma maršruts var nekad nebūt mainījies.

Atzīmējiet plūsmu un dodiet tai tabulu

Virziet atlasīto datplūsmu, atzīmējot to mangle tabulā un saskaņojot atzīmi politikas noteikumā. Noteikums norāda uz īpašu tabulu, kuras noklusējuma maršruts ir iekšējā ierīce, tāpēc tikai atzīmētās paketes iet iekšējo ceļu.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Lielākā daļa šī noteikumu kopuma atteiču nāk no divām kļūdām. Ugunsmūra iestatītā atzīmes vērtība un noteikuma saskaņotā vērtība nedrīkst atšķirties, jo neatbilstība nedod ne kļūdu, ne efektu. Un PREROUTING redz tikai paketes, kas nāk no ārpuses, tāpēc savienojumam, kas sākts šajā resursdatorā, pirms atzīmēšanas vispār ir vajadzīgs OUTPUT noteikums ar tādu pašu saskaņojumu.

Atņemiet maršrutu īpašumtiesības otrajam klientam

Divas opcijas neļauj otrajam klientam rediģēt tabulu, un tās darbojas dažādos punktos. route-nopull ignorē push nosūtītās maršruta opcijas, tāpēc nekas netiek instalēts. route-noexec pieņem push nosūtītās opcijas klienta vidē, bet tabulas maiņu atstāj hook, un tas ir tas, ko vēlaties, kad jums jāredz, ko serveris piedāvāja.

Hook darbojas ar push nosūtītajām vērtībām savā vidē, un tam jāpievieno tikai tās ieraksti, kurus esat apstiprinājis. Padariet to idempotentu: pirms pārbūves iztīriet tabulu, kuru tas pārvalda, un nepieņemiet, ka iepriekšējā palaišana atstāja tīru stāvokli. Atkārtots savienojums atkal izsauc hook, un hook, kas pievieno netīrot, uzkrāj dublētus maršrutus.

Izvēlieties vienu īpašnieku un pierakstiet to. Profils, kas iestata abas opcijas, vai hook, kas konkurē ar manuālu skriptu, rada tabulu, kuru vēlāk neviens nevar izskaidrot.

Piespraudiet abas servera adreses

Iekšējam serverim pirms iekšējā klienta savienošanās ir vajadzīgs resursdatora maršruts caur ārējo ierīci. Šis ieraksts notur iekšējo transportu ārējā tunelī, nevis ļauj tam sekot noklusējumam.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Pievienojiet arī atbilstošu resursdatora maršrutu ārējam serverim galvenajā tabulā, citādi atkārtots savienojums var maršrutēt paša ārējā klienta transportu tā paša tunelī. Secība nav obligāta: pievienojiet šos ierakstus pēc tam, kad attiecīgais interfeiss pastāv, tas ir, hook vai skripts, kas tiek palaists pēc savienojuma. Maršruts uz ierīci, kas ir izslēgta, tiek noņemts vai ignorēts, tāpēc ieraksts, kas rakstīts palaišanas laikā, neiztur jūsu pieņemto secību.

Pārbaudiet meklēšanu, nevis lasiet visu tabulu. Maršruta meklēšanas izvade nosauc ierīci un avota adresi, ko izmantos kodols, un tas ir tieši tas, ko klients saņem, atverot savu ligzdu.

Pārbaudiet ķēdi un padariet atteici redzamu

Tveriet ārējā interfeisā, kamēr iekšējais klients savienojas. Iekšējam rokasspiedienam jāparādās kā šifrētam saturam ārējā tunelī; ja tas parādās kā vienkāršs UDP uz 203.0.113.9, resursdatora maršruts trūkst un ķēde nekad netika uzbūvēta.

Ķēde, kas klusi atgriežas pie fiziskā uplink, ir sliktākais iznākums, jo interfeisa stāvoklis neko neizziņo un iekšējā datplūsma iziet no nepareizās avota adreses. Ja otrais klients var tieši atkārtoti savienoties, kad ārējais tunelis nokrīt, atspējojiet šo ceļu vai piesaistiet to ārējam interfeisam, lai atteice būtu redzama.

Pabeidziet ar divām plūsmām un vienu noteikumu izdruku: atzīmētam un neatzīmētam savienojumam jāiet pa dažādiem ceļiem, un ip rule show jāuzskaita prioritāte, kuru bijāt iecerējis. Ja abas plūsmas iet pa vienu ceļu, atzīme netiek piemērota tur, kur jūs domājat.