Atskiras išėjimas: VPN telkinys usb0, šliuzo srautas eth0

Klientai prisijungia ir autentifikuojasi, o paskui jų srautas išeina netinkama aukštynkryptės jungtimi, nes vienintelis numatytasis maršrutas įrenginyje priklauso pačiam šliuzui. Pakeitus tą numatytąjį maršrutą, sugestų paties įrenginio atnaujinimai ir administravimo prieiga, todėl pasirinkimas turi būti siauresnis nei „visas srautas“. Veikianti forma yra politikos taisyklė, pagrįsta vidiniu klientų telkinio šaltinio adresu ir nukreipianti į antrą maršrutizavimo lentelę, kuriai priklauso alternatyvusis WAN. Nuo toliau kontrolinis sąrašas kalba apie išsamumą ir elgseną gedimo metu, o ne apie pačią taisyklę.

Patvirtinkite, kad šaltinio adresas išlieka iki maršrutizavimo sprendimo

Politikos taisyklė, atitinkanti šaltinio diapazoną, suveikia tik tada, kai paketas paieškos metu dar neša tą šaltinį. Persiunčiamas klientų srautas taip daro, kol niekas aukščiau jo neperrašė prieš maršrutizavimą. Šliuzo generuojamas srautas taip nedaro, ir būtent todėl šliuzo numatytasis maršrutas gali likti savo vietoje.

Čia klaidina vietiniai testai. Šliuze paleistas curl yra vietoje sukurtas srautas su šliuzo adresu, todėl jis ima pagrindinę lentelę ir nieko neįrodo apie kliento kelią. Testuokite iš prijungto kliento arba kurkite srautą su šaltiniu, kuris tikrai priklauso telkiniui.

Pradėkite užsirašydami tikrąsias reikšmes: telkinio prefiksą, jį nešantį tunelio sąsają, antrojo WAN adresą ir kitą šuolį bei lentelės numerį, kurį ketinate naudoti. Prieš pridėdami naujas taisykles išvalykite senąsias iš bet kurio ankstesnio bandymo, nes dubliuotos taisyklės skirtinguose prioritetuose sukelia gedimus, kurie atrodo atsitiktiniai.

Sukurkite pasirinktą lentelę, kuri yra išsami

Lentelė nėra numatytasis maršrutas su draugu. Jai reikia pakankamai maršrutų, kad kiekviena paieška išsispręstų jos viduje, įskaitant prijungtą WAN potinklio maršrutą, kad kitas šuolis būtų pasiekiamas. Telkiniui 10.77.0.0/24 tun1 sąsajoje, WAN adresui 203.0.113.20/24 su kitu šuoliu 203.0.113.1 ir 600 lentelei:

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

Taisyklė stovi žemesniu prioritetu nei bet kuri esama viską pagaunanti taisyklė, todėl atitinkantys klientai pirmiausia patenka į 600 lentelę, o visa kita krinta į pagrindinę lentelę. ip-rule nuoroda išsamiai aprašo eilės tvarka atliekamos paieškos modelį ir selektoriaus sintaksę.

Tada pagalvokite, ko lentelėje nėra. Paskirties vieta, turinti maršrutą tik pagrindinėje lentelėje, pavyzdžiui, administravimo potinklis, pasiekiamas per eth0, nebus rastas 600 lentelėje ir negrįš į pagrindinę, kai joje jau bus numatytasis maršrutas. Jei tie keliai svarbūs, aiškiai įtraukite juos į pasirinktą lentelę, o tai paprastai yra teisingas atsakymas VPN išėjimo lentelei.

Laikykite paties klausytojo srautą už politikos ribų

OpenVPN klausytojas turi savo išorinį ryšį, nešamą ta aukštynkryptės jungtimi, kuria klientas jį pasiekė. Tas srautas turi išsaugoti atvykimo grįžimo kelią, o plati taisyklė, apimanti viešą serverio adresą ar visą tunelio sąsają, gali įtraukti jį į alternatyviąją lentelę. Apribokite taisyklę vidiniu telkiniu ir niekuo kitu.

Atvirkštinio kelio filtravimas vertas dėmesio dėl tos pačios priežasties. Kai atsakymai klientams išeina per usb0, o užklausa atėjo kita jungtimi, griežtas rp_filter nustatymas gali išmesti paketus, kuriuos maršrutizavimo politika laiko galiojančiais. Patikrinkite galiojančias sysctl reikšmes abiejose sąsajose prieš darydami išvadą, kad taisyklė nepavyko.

Tvarka taip pat svarbi viso kito įrenginyje atžvilgiu. Docker tiltai, antras VPN ir bet kurios iš anksto buvusios taisyklės iš teikėjo atvaizdo prideda prioritetų, todėl skaitomą visą taisyklių sąrašą, o ne manykite, kad 100 prioritetas yra vienas.

Suderinkite persiuntimą ir vertimą su maršrutu

Maršrutizavimas pasirenka aukštynkryptės jungtį; jis nesuteikia leidimo persiųsti. Branduolyje turi būti įjungtas IPv4 persiuntimas, o ugniasienė turi priimti kryptį nuo kliento į WAN ir grįžtamąjį srautą. Teisinga lentelė su FORWARD grandine, kuri išmeta srautą, duoda tuos pačius simptomus kaip trūkstamas maršrutas, todėl abu tikrinami tame pačiame žingsnyje.

Jei antrasis WAN neberetransliuos privataus telkinio atgal į jus, išverskite šaltinį tame išėjime. Dinaminio adreso sąsajai įprastas pasirinkimas yra siaura masquerade taisyklė, apribota telkiniu ir sąsaja:

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

Čia aprėptis svarbesnė už tikslą. Masquerade taisyklė, atitinkanti bet kurią išeinančią sąsają, perrašys ir srautą, kuris teisingai išeina per eth0, o tai paslepia maršrutizavimo klaidas, o ne ištaiso jas. Vertimas vyksta po maršrutizavimo sprendimo, todėl jis niekada negali pataisyti paketo, išsiųsto netinkama aukštynkryptės jungtimi.

Tunelio sąnaudos taip pat reikalauja dėmesio, kai keliai skiriasi. Jei klientai susitaria dėl didelio TCP MSS, o alternatyvusis WAN turi mažesnį MTU arba tunelį savyje, dideli segmentai stringa, o maži veikia. MSS apribojimas persiuntimo kelyje paverčia tai nuspėjama elgsena, o ne periodišku užstrigimu.

Nuspręskite, kas atsitinka, kai usb0 dingsta

Tuščia lentelė nėra gedimo metu užsidaranti būsena. Jei atitinkamas maršrutas dingsta, paieška tęsiasi prie kitos taisyklės, pasiekia pagrindinę lentelę ir ima eth0 numatytąjį maršrutą. Srautas, kuris turėjo išeiti per antrąjį WAN, tyliai išeina per pirmąjį, o politikos pagrindu maršrutizuotame diegime tai paprastai yra mažiausiai pageidaujamas rezultatas.

Kur toks atsitraukimas nepriimtinas, į 600 lentelę įtraukite aiškų galinį maršrutą, pavyzdžiui, blackhole numatytąjį, arba kol sąsaja išjungta, išmeskite telkinį ugniasienėje. Bet kuris iš šių variantų yra sprendimas, kurį galite užrašyti; tyla – ne.

Patvarumas yra paskutinis punktas. Kas valdo abi jungtis, ar tai būtų tinklo tvarkyklė, siuntimo scenarijus ar ryšio gyvavimo ciklas, turi kiekvieno prisijungimo metu iš naujo sukurti maršrutus ir taisyklę, nepridedant dublikatų. Patikrinkite užklausa iš tikro kliento ir atskira užklausa iš šliuzo, patvirtinkite stebimą išėjimą abiem atvejais, tada ištraukite antrąjį WAN ir pažiūrėkite, kuris iš dviejų suprojektuotų rezultatų iš tikrųjų įvyksta. IPv6 reikia savo lentelės, taisyklės ir vertimo; aukščiau pateikta IPv4 taisyklė apie tai nieko nesako.