Enkursigi OpenVPN-klientojn tra Cloudflare? Unue kontrolu la rolon
Aparata kliento ne estas enkursigilo. Konfirmu, ke la rolo de Cloudflare plusendas pakaĵojn de aliaj gastigantoj, poste tenu la propran tunelon de la servilo sur ĝia malnova vojo.
Vi havas funkciantan OpenVPN-servilon kaj gastiganton, kiu ankaŭ rulas la aparatan programaron de Cloudflare, kaj la evidenta sekva paŝo ŝajnas direkti klientan trafikon al ĝi. Du funkciantaj konektoj sur unu maŝino ne sumiĝas al transita pordego. Kio mankas estas rolo dokumentita por plusendi pakaĵojn apartenantajn al iu alia, kaj politiko, kiu klasifikas tiujn pakaĵojn kiam ili alvenas.
Antaŭ čiu regulo staras kvar demandoj: kiu trafiko eniras, kien ĝi iras poste, kiel la respondoj trovas la vojon reen, kaj kion la dezajno faras kiam tiu dua vojo malsukcesas. La unuaj du estas demandoj pri kapablo.
Du servoj sur unu gastiganto ne estas transita vojo
Aparata kliento estas konstruita por pritrakti trafikon, kiu originas sur la maŝino kie ĝi ruliĝas. Ĝi interkaptas nomrezolucion aŭ elektitan aplikaĵan trafikon kaj sendas ĝin tra sia propra tunelo, kaj ĝia politiko estas skribita por la uzanto de tiu aparato kaj la procezoj de tiu aparato. Pakaĵo plusendita de OpenVPN-kliento ne estas loka eligo, do la samaj reguloj ne klasifikas ĝin. Tio ne estas agorda detalo, kiun vi povas kovri per pli larĝa regulo, ĉar ĝi decidas ĉu la programaro tute vidas la pakaĵon.
Tial la dezajna demando estas demando pri kapablo. Ĉu la instalita produkto havas dokumentitan rolon, kiu plusendas trafikon por aliaj retoj, aŭ la transita funkcio apartenas tute aliloke.
Kiu rolo de Cloudflare rajtas plusendi
La aparata kliento de Cloudflare proponas reĝimojn, kiuj diferencas laŭ amplekso: nur nomrezolucio, trafiko de la aparato, kaj foje ambaŭ. Neniu el tiuj reĝimoj igas la gastiganton enkursigilo por privata gamo, kiu alvenas per alia tunelo. La dediĉita enkursiga rolo estas aparta produkto kun sia propra konektilo, registriĝo kaj reta modelo.
| 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 |
Kontrolu la instalitan rolon antaŭ ol dezajni vojojn ĉirkaŭ ĝi. Legu kiun interfacon la konektilo kreas, ĉu ĝi anoncas specifajn prefiksojn aŭ defaŭltan vojon, kaj ĉu la loka politiko validas por plusenditaj pakaĵoj same kiel por lokaj. Se nur loka trafiko estas pritraktata, la OpenVPN-servilo ne povas esti la transita punkto, kiel ajn la traduka regulo estas skribita.
Ĉi tie ankaŭ la postulo pri publika eliro devas esti formulita precize. Eliro provizita de Cloudflare por plusendita klienta trafiko estas specifa uzkazo, kaj ĝi devas esti konfirmita kontraŭ la servo, kiun vi efektive havas.
Tenu la eksteran tunelon sendependa de la nova vojo
En la momento, kiam vi aldonas defaŭltan vojon al la nova interfaco, la propra elira trafiko de la servilo komencas konkurado por ĝi, kaj tio inkluzivas respondojn al la OpenVPN-klientoj kaj vian SSH-sesion al la skatolo. La kutima simptomo estas tunelo, kiu establiĝas kaj poste mortas, aŭ administranto ŝlosita ekstere dum la ŝanĝo ŝajnas esti funkciinta. Komparu ip route get por la finpunkto antaŭ kaj poste, kaj uzu politikan enkursigadon aŭ gastigantan vojon por teni la propran transporton de la servilo tie, kie ĝi estis. Rulu tiun komparon de la skatolo mem, ĉar la propra vido de la servilo pri sia vojo estas tiu, kiu gravas.
Escepto por la publika adreso de la servilo ne sufiĉas per si mem, ĉar la revena vojo de ĉiu fora administranto estas malsama fluo. Decidu, kiuj el tiuj fluoj devas postvivi la ŝanĝon, poste kontrolu ĉiun anstataŭ supozi, ke la unua kovras la ceterajn.
Limigu la plusendadon kaj tradukon al unu fluo
Ricevitaj pakaĵoj sekvas la plusendan vojon, ne la lokan eligan vojon, do la regulo, kiu gravas, vivas en la forward-hoko. Kie la sekva interfaco bezonas tradukon, limigu la fonton al la klienta baseno, la celon al tio permesita kaj la eliron al tiu ununura interfaco. Masquerade-regulo ligita nur al interfaco mem elektas neniun vojon kaj permesas neniun plusendadon preter iu ajn alia filtrilo.
Decidu la konduton de fermo ĉe fiasko anticipe, poste testu ĝin. Haltigu la sekvan vojon kaj konfirmu, ke la klientoj perdas la celitan eliron anstataŭ silente fali reen al la ordinara suprenligo, ĉar tio estas la rezulto, kiun neniu rimarkas ĝis la trafiko eliras tra la malĝusta pordo. Ripetu la kontrolon por nomrezolucio kaj por IPv6, ĉar regularo nur por v4 lasas vojon v6 malferma.
Skribu la kvar respondojn, pri kiuj vi decidis, kaj la observaĵon, kiu montras ĉiun. Transita vojo, kiun vi povas priskribi, estas tiu, kiun vi povas defendi ĉe la sekva okazaĵa revizio.