Divi OpenVPN klienti vienā Linux vārtejā: sadaliet politiku

Divi OpenVPN dēmoni var abi ziņot par veiksmīgu tuneli, kamēr vārteja katru klientu sūta pa to pašu. Neviens rokasspiedienā neizlemj, kuru tuneli klients izmanto; to izlemj kodols, pa pakešu, izejot cauri politikas noteikumiem un pēc tam tabulai, ko nosauc katrs noteikums. Ja uz to skatās tā, konfigurācija pārstāj būt par OpenVPN opcijām un kļūst par maršrutēšanas matricu ar diviem īpašniekiem.

Izlemj kodols, nevis dēmons

Pārsūtītā pakete nonāk LAN saskarnē, un maršrutēšanas kods izvērtē noteikumu sarakstu prioritātes secībā. Pirmais noteikums, kura selektors sakrīt, nosauc tabulu, un šīs tabulas maršruti izvēlas izvades ierīci. Ja tabulā nav atbilstoša maršruta, meklēšana turpinās pie nākamā noteikuma, un tieši šī detaļa liek pusgatavai konfigurācijai neizdoties klusi, nevis skaļi.

Tuneļa procesam šajā gājienā nav teikšanas. Tas izveido saskarni un var instalēt maršrutus, bet tas, vai konkrēta klienta pakete nonāk šajā saskarnē, pilnībā atkarīgs no tabulas, uz kuru tā nosūtīta. Tāpēc divi tuneļi ar identiskiem importētiem maršrutiem konkurē, un pēdējais rakstītājs uzvar visiem. Tāpēc konfigurācija failos var izskatīties līdzsvarota un tomēr sūtīt visus klientus caur vienu dēmonu.

Piešķiriet katrai instancei savu resursu kopu

Sāciet ar nosaukumiem, jo atkārtoti lietoti nosaukumi ir ceļš, kā divas instances nejauši sāk dalīt stāvokli. Piešķiriet atsevišķas tuneļa ierīces, atsevišķus konfigurācijas failus, atsevišķus akreditācijas datus un atsevišķas servisa vienības. Ierakstiet katras instances ārējo galapunktu un tuneļa adresi tajā pašā tabulā kā politikas matricu, lai vēlākai izmaiņai būtu viena vieta, kur paskatīties.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull tur servera stumtos maršrutus ārpus vietējās tabulas, un tas ir tieši tas, ko vēlaties, kad politikas tabulām jābūt skaidrām. Vai konkrēts serveris stumj arī redirect-gateway opciju un vai jūsu klienta versija atbalsta filtra formu, ir vērts pārbaudīt rokasgrāmatā, nevis pieņemt.

Uzrakstiet matricu: avots, tabula, ierīce

Katrai klientu grupai pievienojiet noteikumu, kas izvēlas tabulu pēc avota adreses, pēc tam ievietojiet paredzēto ceļu šajā tabulā:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabulai vajag galamērķa maršrutus, kādi grupai jābūt, plus jebkādus vietējos vai pārvaldības izņēmumus, kas notur vārteju lietojamu. Tabula, kurā ir tikai noklusējuma maršruts, ir pilna tuneļa politika šai grupai, un tas var būt tieši pareizi, bet tam jābūt lēmumam, nevis izlaidumam.

Paša tuneļa transports nav klientu grupā

Katra dēmona šifrētās paketes rodas pašā vārtejā, adresētas ārējam partnerim. Noteikums, kas sakrīt tikai ar klienta avota prefiksu, atstāj šīs paketes mierā, tāpēc uz avotu attiecinātie noteikumi ir drošāki par noteikumiem, kas sakrīt ar visu. Noteikums bez selektora var sagrābt paša tuneļa transportu un nosūtīt to atpakaļ caur tuneli, un tad savienojums neizdodas tā, ka izskatās pēc pakalpojumu sniedzēja problēmas.

Turiet vietējo pārvaldības sesiju un apakšējā slāņa ceļu skaidri ārpus politikas tabulām. Pierakstiet šos izņēmumus blakus matricai; tie ir dizaina daļa, nevis apiešanas risinājums, kas jāatklāj no jauna incidenta laikā.

Ceļa izvēle to neatļauj

Atļauja pārsūtīt ir otrs lēmums, kas pieņemts vēlāk ceļā. Ugunsmūra noteikums, kas pieņem paketes, kuras iziet caur otro tuneli, nepanāk, ka maršrutēšanas kods to izvēlas, un pareiza tabula nedod atļauju pārsūtīt. Abiem jābūt, un tests, kas pierāda tikai vienu, jūs maldinās par otru. Kad viena grupa strādā, bet otra ne, pārbaudiet šos divus soļus atsevišķi, nevis pārrakstiet tabulas.

Avota tulkošana ir trešais lēmums, un tas jāierobežo ar avota grupu un tuneļa ierīci, kas to patiešām pārvadā. Pievienojiet atsevišķu ķēdi abām instancēm, nevis iztukšojiet postrouting ķēdi, jo nesaistīti pakalpojumi tur var būt ierakstus, un iztukšošana tos klusi noņem.

Kas notiek, kad viens tunelis krīt

Izlemiet atteices uzvedību iepriekš. Kad tuneļa tabula zaudē savu maršrutu, meklēšana nokrīt pie nākamā noteikuma, un grupas satiksme turpinās caur otru tuneli vai parasto augšupejošo saiti bez jebkādas kļūdas. Ja tas nav pieņemami, pievienojiet beigu noteikumu ar zemāku prioritātes numuru, kas šim avotam atgriež nesasniedzamu rezultātu, lai zudums būtu redzams, nevis absorbēts.

Nosūtiet jaunu pieprasījumu no katras avota grupas un pierakstiet četrus faktus: izvēlēto tabulu, izvades ierīci, tulkoto avotu un vai atbilde atgriezās pa to pašu ceļu. Pēc tam nolaidiet vienu tuneli un atkārtojiet. Divas TUN ierīces saskarņu sarakstā pierāda, ka abi dēmoni startēja; tās neko nesaka par to, kuru izmantoja konkrēts klients. Otrais palaidums, kad viena tuneļa vairs nav, ir tas, kas parāda, vai jūsu rezerves noteikums dara to, ko bijāt iecerējis.