Maršrutizuoti OpenVPN klientus per Cloudflare? Pirmiausia patikrinkite vaidmenį
Įrenginio klientas nėra maršrutizatorius. Patvirtinkite, kad Cloudflare vaidmuo persiunčia kitų hostų paketus, ir palikite serverio tunelį sename kelyje.
Turite veikiantį OpenVPN serverį ir hostą, kuriame taip pat veikia Cloudflare įrenginio programinė įranga, o akivaizdus kitas žingsnis atrodo kaip klientų srauto nukreipimas į jį. Du veikiantys ryšiai viename kompiuteryje nesudaro tranzitinio tinklų vartų. Trūksta vaidmens, dokumentuoto persiųsti paketus, priklausančius kam nors kitam, ir politikos, kuri tuos paketus klasifikuoja jiems atvykus.
Prieš bet kurią taisyklę kyla keturi klausimai: koks srautas įeina, kur jis eina toliau, kaip atsakymai randa kelią atgal ir ką daro dizainas, kai tas antrasis kelias nepavyksta. Pirmieji du yra galimybių klausimai.
Dvi paslaugos viename hoste nėra tranzitinis kelias
Įrenginio klientas sukurtas tvarkyti srautą, kylantį mašinoje, kurioje jis veikia. Jis perima vardų sprendimą arba pasirinktą programų srautą ir siunčia jį savo tuneliu, o jo politika parašyta to įrenginio naudotojui ir to įrenginio procesams. Paketas, persiųstas iš OpenVPN kliento, nėra vietinė išvestis, todėl tos pačios taisyklės jo neklasifikuoja. Tai ne konfigūracijos smulkmena, kurią galima uždengti platesne taisykle, nes ji lemia, ar programinė įranga apskritai mato paketą.
Todėl dizaino klausimas yra galimybių klausimas. Arba įdiegtas produktas turi dokumentuotą vaidmenį, kuris persiunčia srautą kitiems tinklams, arba tranzito funkcija priklauso visai kitai vietai.
Kuris Cloudflare vaidmuo gali persiųsti
Cloudflare įrenginio klientas siūlo režimus, kurie skiriasi apimtimi: tik vardų sprendimas, srautas iš įrenginio ir kartais abu. Nė vienas iš šių režimų nepaverčia hosto maršrutizatoriumi privačiam diapazonui, kuris ateina per kitą tunelį. Specialus maršrutizavimo vaidmuo yra atskiras produktas su savo jungtimi, registracija ir tinklo modeliu.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Patikrinkite įdiegtą vaidmenį prieš projektuodami maršrutus aplink jį. Perskaitykite, kokią sąsają sukuria jungtis, ar ji skelbia konkrečius prefiksus ar numatytąjį maršrutą, ir ar vietinė politika taikoma persiųstiems paketams, kaip ir vietiniams. Jei tvarkomas tik vietinis srautas, OpenVPN serveris negali būti tranzito tašku, kad ir kaip būtų parašyta vertimo taisyklė.
Čia taip pat reikia tiksliai suformuluoti viešosios išvesties reikalavimą. Cloudflare teikiama išvestis persiųstam klientų srautui yra konkretus naudojimo atvejis, ir jį reikia patvirtinti pagal paslaugą, kurią iš tikrųjų turite.
Laikykite išorinį tunelį nepriklausomą nuo naujo maršruto
Tą akimirką, kai pridedate numatytąjį maršrutą į naują sąsają, serverio savas išeinantis srautas pradeda dėl jo konkuruoti, ir tai apima atsakymus OpenVPN klientams bei jūsų SSH sesiją į mašiną. Įprastas simptomas yra tunelis, kuris užsimezga ir tada miršta, arba administratorius, užrakintas lauke, kol pakeitimas atrodo suveikęs. Palyginkite ip route get galiniam taškui prieš ir po, ir naudokite politikos pagrindu veikiantį maršrutizavimą arba hosto maršrutą, kad serverio savas transportas liktų ten, kur buvo. Atlikite šį palyginimą iš pačios mašinos, nes svarbus yra serverio požiūris į savo maršrutą.
Išimtis serverio viešajam adresui pati savaime nepakanka, nes kiekvieno nuotolinio administratoriaus grįžimo kelias yra skirtingas srautas. Nuspręskite, kurie iš šių srautų turi išgyventi pakeitimą, tada patikrinkite kiekvieną, o ne manykite, kad pirmasis apima likusius.
Apribokite persiuntimą ir vertimą vienu srautu
Gauti paketai seka persiuntimo keliu, o ne vietinės išvesties keliu, todėl svarbi taisyklė gyvena forward kabliuke. Kai kitai sąsajai reikia vertimo, apribokite šaltinį klientų telkiniu, paskirties vietą leidžiamais ir išvestį ta viena sąsaja. Masquerade taisyklė, susieta tik su sąsaja, pati nepasirenka maršruto ir neleidžia persiuntimo pro jokį kitą filtrą.
Iš anksto nuspręskite elgseną gedimo atveju ir tada ją išbandykite. Sustabdykite tolesnį kelią ir patvirtinkite, kad klientai netenka numatytos išvesties, o ne tyliai grįžta prie įprasto uplink, nes tai yra rezultatas, kurio niekas nepastebi, kol srautas nepradeda išeiti pro netinkamas duris. Pakartokite patikrinimą vardų sprendimui ir IPv6, nes taisyklių rinkinys tik v4 palieka v6 kelią atvirą.
Užrašykite tuos keturis atsakymus, prie kurių sustojote, ir stebėjimą, kuris kiekvieną įrodo. Tranzitinis kelias, kurį galite aprašyti, yra tas, kurį galite apginti kitame incidentų aptarime.