Usmerjati odjemalce OpenVPN skozi Cloudflare? Najprej preverite vlogo
Odjemalec naprave ni usmerjevalnik. Potrdite, da vloga Cloudflare posreduje pakete drugih gostiteljev, in pustite lastni tunel strežnika na stari poti.
Imate delujoč strežnik OpenVPN in gostitelja, ki poganja tudi programsko opremo naprave Cloudflare, in naslednji očitni korak je videti kot usmerjanje odjemalskega prometa nanj. Dve delujoči povezavi na enem stroju ne tvorita tranzitnega prehoda. Manjka vloga, dokumentirana za posredovanje paketov, ki pripadajo nekomu drugemu, in politika, ki te pakete razvrsti, ko prispejo.
Pred vsakim pravilom so štiri vprašanja: kakšen promet vstopa, kam gre naprej, kako odgovori najdejo pot nazaj in kaj naredi zasnova, ko ta druga pot odpove. Prvi dve sta vprašanji zmožnosti.
Dve storitvi na enem gostitelju nista tranzitna pot
Odjemalec naprave je zgrajen za obdelavo prometa, ki nastane na stroju, kjer deluje. Prestreže razreševanje imen ali izbrani promet aplikacij in ga pošlje skozi svoj tunel, njegova politika pa je napisana za uporabnika te naprave in procese te naprave. Paket, posredovan iz odjemalca OpenVPN, ni lokalni izhod, zato ga ista pravila ne razvrstijo. To ni podrobnost konfiguracije, ki bi jo lahko prekrili s širšim pravilom, ker odloča, ali programska oprema paket sploh vidi.
Zato je vprašanje zasnove vprašanje zmožnosti. Bodisi ima nameščeni izdelek dokumentirano vlogo, ki posreduje promet za druga omrežja, bodisi tranzitna funkcija pripada povsem drugemu mestu.
Katera vloga Cloudflare sme posredovati
Odjemalec naprave Cloudflare ponuja načine, ki se razlikujejo po obsegu: samo razreševanje imen, promet iz naprave in včasih oboje. Noben od teh načinov ne spremeni gostitelja v usmerjevalnik za zasebno območje, ki prihaja po drugem tunelu. Namenska vloga usmerjanja je ločen izdelek z lastnim konektorjem, registracijo in omrežnim modelom.
| 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 |
Preverite nameščeno vlogo, preden oblikujete poti okoli nje. Preberite, kateri vmesnik ustvari konektor, ali oglašuje določene predpone ali privzeto pot in ali lokalna politika velja tudi za posredovane pakete, ne le za lokalne. Če se obdeluje samo lokalni promet, strežnik OpenVPN ne more biti tranzitna točka, ne glede na to, kako je napisano pravilo prevajanja.
Tu je treba tudi zahtevo po javnem izhodu natančno oblikovati. Izhod, ki ga Cloudflare zagotavlja za posredovani odjemalski promet, je poseben primer uporabe in ga je treba potrditi glede na storitev, ki jo dejansko imate.
Ohranite zunanji tunel neodvisen od nove poti
V trenutku, ko dodate privzeto pot na novi vmesnik, se lastni odhodni promet strežnika začne potegovati zanjo, to pa vključuje odgovore odjemalcem OpenVPN in vašo sejo SSH do stroja. Običajna simptom je tunel, ki se vzpostavi in nato umre, ali skrbnik, zaklenjen zunaj, medtem ko se zdi, da je sprememba uspela. Primerjajte ip route get za končno točko pred in po ter uporabite usmerjanje na podlagi politike ali pot do gostitelja, da lastni promet strežnika ostane tam, kjer je bil. To primerjavo izvedite s stroja samega, ker šteje lasten pogled strežnika na njegovo pot.
Izjema za javni naslov strežnika sama po sebi ni dovolj, ker je povratna pot vsakega oddaljenega skrbnika drugačen tok. Odločite, kateri od teh tokov morajo prestati spremembo, in nato preverite vsakega, namesto da predpostavljate, da prvi pokriva ostale.
Omejite posredovanje in prevajanje na en tok
Prejeti paketi sledijo poti posredovanja, ne poti lokalnega izhoda, zato pravilo, ki šteje, živi v kljuki forward. Kjer naslednji vmesnik potrebuje prevajanje, omejite vir na odjemalski nabor, cilj na dovoljeno in izhod na ta edini vmesnik. Pravilo masquerade, vezano le na vmesnik, samo ne izbere poti in ne dovoli posredovanja mimo nobenega drugega filtra.
Vnaprej odločite o vedenju ob zaprtju zaradi napake in ga nato preizkusite. Ustavite naslednjo pot in potrdite, da odjemalci izgubijo predvideni izhod, namesto da se tiho vrnejo na običajno nadrejeno povezavo, ker je to rezultat, ki ga nihče ne opazi, dokler promet ne začne izhajati skozi napačna vrata. Ponovite preverjanje za razreševanje imen in za IPv6, ker nabor pravil samo za v4 pušča pot v6 odprto.
Zapišite štiri odgovore, na katerih ste se ustavili, in opažanje, ki vsakega dokazuje. Tranzitna pot, ki jo znate opisati, je tista, ki jo znate zagovarjati na naslednjem pregledu incidentov.