Atsevišķa izeja: VPN baseins uz usb0, vārtejas trafiks uz eth0

Klienti pieslēdzas un autentificējas, un tad viņu trafiks iziet pa nepareizo augšupielādes saiti, jo vienīgais noklusējuma maršruts ierīcē pieder pašai vārtejai. Šī noklusējuma maršruta aizstāšana salauztu pašas ierīces atjauninājumus un pārvaldības piekļuvi, tāpēc atlasei jābūt šaurākai par «visu trafiku». Strādājošā forma ir politikas noteikums, kas balstīts uz klientu baseina iekšējo avota adresi un norāda uz otru maršrutēšanas tabulu, kurai pieder alternatīvais WAN. No turienes kontrolsaraksts attiecas uz pilnīgumu un uzvedību kļūmes gadījumā, nevis uz pašu noteikumu.

Pārliecinieties, ka avota adrese saglabājas līdz maršrutēšanas lēmumam

Politikas noteikums, kas atbilst avota diapazonam, iedarbojas tikai tad, kad pakete meklēšanas brīdī vēl nes šo avotu. Pārsūtītais klientu trafiks to dara, kamēr nekas augstāk to nav pārrakstījis pirms maršrutēšanas. Vārtejas ģenerētais trafiks to nedara, un tieši tāpēc vārtejas pašas noklusējuma maršruts var palikt savā vietā.

Šeit vietējie testi maldina. Uz vārtejas palaists curl ir lokāli ģenerēta plūsma ar vārtejas adresi, tāpēc tā izmanto galveno tabulu un neko nepierāda par klienta ceļu. Pārbaudiet no pievienota klienta vai ģenerējiet trafiku ar avotu, kas patiešām pieder baseinam.

Sāciet ar īsto vērtību pierakstīšanu: baseina prefikss, to nesošā tuneļa saskarne, otrā WAN adrese un nākamais lēciens, un tabulas numurs, ko plānojat izmantot. Pirms jaunu noteikumu pievienošanas notīriet vecos noteikumus no jebkura iepriekšējā mēģinājuma, jo dublēti noteikumi ar atšķirīgām prioritātēm rada kļūmes, kas izskatās nejaušas.

Izveidojiet atlasītu tabulu, kas ir pilnīga

Tabula nav noklusējuma maršruts ar draugu. Tai vajag pietiekami daudz maršrutu, lai katra meklēšana atrisinātos tās iekšienē, tostarp pievienoto WAN apakštīkla maršrutu, lai nākamais lēciens būtu sasniedzams. Baseinam 10.77.0.0/24 uz tun1, WAN adresei 203.0.113.20/24 ar nākamo lēcienu 203.0.113.1 un 600 tabulai:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Noteikums atrodas zemākā prioritātē nekā jebkurš esošais visu tvērējs noteikums, tāpēc atbilstošie klienti vispirms nonāk 600 tabulā, un viss pārējais iekrīt galvenajā tabulā. ip-rule uzziņa pilnībā apraksta sakārtotās meklēšanas modeli un selektora sintaksi.

Pēc tam padomājiet, kas tabulā nav. Galamērķis, kam maršruts ir tikai galvenajā tabulā, piemēram, pārvaldības apakštīkls, sasniedzams caur eth0, netiks atrasts 600 tabulā un neatgriezīsies galvenajā, tiklīdz tur būs noklusējuma maršruts. Ja šie ceļi ir svarīgi, skaidri pievienojiet tos atlasītajai tabulai, kas parasti ir pareizā atbilde VPN izejas tabulai.

Turiet paša klausītāja trafiku ārpus politikas

Klausītājam OpenVPN ir savs ārējais savienojums, kas tiek nests pa to augšupielādes saiti, pa kuru klients to sasniedza. Šim trafikam jāsaglabā atgriešanās ceļš, ar kādu tas ieradās, un plašs noteikums, kas aptver servera publisko adresi vai visu tuneļa saskarni, var to ievilkt alternatīvajā tabulā. Ierobežojiet noteikumu ar iekšējo baseinu un ne ar ko citu.

Apgrieztā ceļa filtrēšana ir pelnījusi ieskatu tā paša iemesla dēļ. Kad atbildes klientiem iziet pa usb0, bet pieprasījums ieradās pa citu saiti, stingrs rp_filter iestatījums var nomest paketes, ko maršrutēšanas politika uzskata par derīgām. Pārbaudiet spēkā esošās sysctl vērtības abās saskarnēs, pirms secināt, ka noteikums neizdevās.

Secība ir svarīga arī attiecībā pret visu pārējo ierīcē. Docker tilti, otrs VPN un jebkuri iepriekš esošie noteikumi no pakalpojumu sniedzēja attēla pievieno prioritātes, tāpēc lasiet visu noteikumu sarakstu, nevis pieņemiet, ka prioritāte 100 ir viena.

Saskaņojiet pārsūtīšanu un tulkošanu ar maršrutu

Maršrutēšana izvēlas augšupielādes saiti; tā nepiešķir atļauju pārsūtīt. Kodolā jābūt iespējotai IPv4 pārsūtīšanai, un ugunsmūrim jāpieņem virziens no klienta uz WAN un atgriešanās trafiks. Pareiza tabula ar FORWARD ķēdi, kas izmet plūsmu, rada tos pašus simptomus kā trūkstošs maršruts, tāpēc abi tiek pārbaudīti vienā piegājienā.

Ja otrais WAN nemaršrutēs privāto baseinu atpakaļ pie jums, tulkojiet avotu šajā izejā. Saskarnei ar dinamisku adresi parastā izvēle ir šaurs masquerade noteikums, ierobežots ar baseinu un saskarni:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Šeit tvērums ir svarīgāks par mērķi. Masquerade noteikums, kas atbilst jebkurai izejošajai saskarnei, pārrakstīs arī trafiku, kas pareizi iziet pa eth0, un tas slēpj maršrutēšanas kļūdas, nevis tās labo. Tulkošana notiek pēc maršrutēšanas lēmuma, tāpēc tā nekad nevar salabot paketi, kas nosūtīta pa nepareizo augšupielādes saiti.

Tuneļa izmaksas arī prasa uzmanību, tiklīdz ceļi atšķiras. Ja klienti vienojas par lielu TCP MSS un alternatīvajam WAN ir zemāks MTU vai tunelis tajā, lielie segmenti iestrēgst, kamēr mazie darbojas. MSS ierobežošana pārsūtīšanas ceļā to pārvērš paredzamā uzvedībā, nevis periodiskā iekāršanā.

Izlemiet, kas notiks, kad usb0 pazudīs

Tukša tabula nav kļūmes gadījumā aizverošs stāvoklis. Ja atbilstošais maršruts pazūd, meklēšana turpinās pie nākamā noteikuma, sasniedz galveno tabulu un izmanto eth0 noklusējumu. Trafiks, kam bija jāiziet pa otro WAN, klusi iziet pa pirmo, un politikas maršrutētā izvietojumā tas parasti ir vismazāk vēlamais rezultāts.

Kur šāda atkāpšanās nav pieņemama, pievienojiet 600 tabulai skaidru termināla maršrutu, piemēram, blackhole noklusējumu, vai, kamēr saskarne ir izslēgta, izmetiet baseinu ugunsmūrī. Jebkura no abām ir lēmums, ko varat pierakstīt; klusēšana nav.

Noturība ir pēdējais punkts. Kam pieder abas saites, vai tas būtu tīkla pārvaldnieks, sūtīšanas skripts vai savienojuma dzīves cikls, tam katrā atkārtotā savienojumā no jauna jāizveido maršruti un noteikums, nepievienojot dublikātus. Pārbaudiet ar pieprasījumu no īsta klienta un atsevišķu pieprasījumu no vārtejas, apstipriniet novēroto izeju abos, pēc tam izvelciet otro WAN un vērojiet, kurš no diviem projektētajiem rezultātiem patiešām notiek. IPv6 vajag savu tabulu, noteikumu un tulkojumu; iepriekš minētais IPv4 noteikums par to neko nesaka.