I-ruruta ang mga kliyente ng OpenVPN sa Cloudflare? Suriin muna ang tungkulin
Ang kliyente ng device ay hindi router. Kumpirmahin na ipinapasa ng tungkulin ng Cloudflare ang mga packet ng ibang host, at panatilihin ang sariling tunnel ng server sa dati nitong landas.
Mayroon kang gumaganang OpenVPN server at host na nagpapatakbo rin ng software ng device ng Cloudflare, at ang halatang susunod na hakbang ay parang ituro doon ang trapiko ng mga kliyente. Ang dalawang gumaganang koneksyon sa isang makina ay hindi bumubuo ng transit gateway. Ang kulang ay isang tungkuling may dokumento para magpasa ng mga packet na pag-aari ng iba, at patakarang nag-uuri sa mga packet na iyon pagdating.
Bago ang anumang patakaran, may apat na tanong: anong trapiko ang pumapasok, saan ito pupunta susunod, paano nakakahanap ng daan pabalik ang mga sagot, at ano ang ginagawa ng disenyo kapag nabigo ang ikalawang landas na iyon. Ang unang dalawa ay mga tanong sa kakayahan.
Dalawang serbisyo sa isang host ay hindi landas ng transit
Ang kliyente ng device ay ginawa para pangasiwaan ang trapikong nagmumula sa makinang pinatatakbo nito. Kinukuha nito ang resolusyon ng pangalan, o piling trapiko ng aplikasyon, at ipinapadala ito sa sarili nitong tunnel, at ang patakaran nito ay isinulat para sa user ng device na iyon at mga proseso ng device na iyon. Ang packet na ipinasa mula sa kliyente ng OpenVPN ay hindi lokal na output, kaya hindi ito inuuri ng parehong mga patakaran. Hindi ito detalye ng configuration na maaaring takpan ng mas malawak na patakaran, dahil ito ang nagpapasya kung nakikita man ng software ang packet.
Kaya ang tanong sa disenyo ay tanong sa kakayahan. Alinman may dokumentadong tungkulin ang naka-install na produkto na nagpapasa ng trapiko para sa ibang network, o ang tungkuling transit ay pag-aari ng buong ibang lugar.
Aling tungkulin ng Cloudflare ang pinapayagang magpasa
Nag-aalok ang kliyente ng device ng Cloudflare ng mga mode na naiiba sa saklaw: resolusyon ng pangalan lamang, trapiko mula sa device, at kung minsan pareho. Wala sa mga mode na iyon ang gumagawa sa host na router para sa pribadong saklaw na dumarating sa ibang tunnel. Ang nakalaang tungkulin sa pagruruta ay hiwalay na produkto na may sariling connector, pagpapatala at modelo ng network.
| 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 |
Suriin ang naka-install na tungkulin bago magdisenyo ng mga ruta sa paligid nito. Basahin kung aling interface ang ginagawa ng connector, kung nag-aanunsyo ito ng partikular na prefix o default na ruta, at kung nalalapat ang lokal na patakaran sa mga ipinasa at lokal na packet. Kung lokal na trapiko lamang ang pinangangasiwaan, hindi maaaring maging transit point ang OpenVPN server, kahit paano isulat ang patakaran sa pagsasalin.
Dito rin dapat tumpak na sabihin ang pangangailangan sa pampublikong labasan. Ang labas na ibinibigay ng Cloudflare para sa ipinasang trapiko ng kliyente ay partikular na kaso ng paggamit, at kailangang kumpirmahin laban sa serbisyong talagang mayroon ka.
Panatilihing malaya ang panlabas na tunnel sa bagong ruta
Sa sandaling magdagdag ka ng default na ruta patungo sa bagong interface, nagsisimulang makipagkumpitensya para dito ang sariling palabas na trapiko ng server, at kasama doon ang mga sagot sa mga kliyente ng OpenVPN at ang iyong sesyon ng SSH sa makina. Ang karaniwang sintomas ay tunnel na naitatag at pagkatapos ay namamatay, o administrador na nakakandado sa labas habang ang pagbabago ay parang gumana. Ihambing ang ip route get para sa endpoint bago at pagkatapos, at gamitin ang routing na nakabatay sa patakaran o ruta sa host upang panatilihin ang sariling transportasyon ng server kung saan ito naroon. Patakbuhin ang paghahambing na iyon mula sa makina mismo, dahil ang sariling pananaw ng server sa sarili nitong ruta ang mahalaga.
Ang eksepsiyon para sa pampublikong address ng server ay hindi sapat sa sarili nito, dahil ang daan pabalik ng bawat malayong administrador ay ibang daloy. Magpasya kung alin sa mga daloy na iyon ang dapat lumagpas sa pagbabago, pagkatapos ay i-verify ang bawat isa sa halip na ipagpalagay na sakop ng una ang iba.
Limitahan ang pagpasa at pagsasalin sa isang daloy
Ang mga natanggap na packet ay sumusunod sa landas ng pagpasa, hindi sa landas ng lokal na output, kaya ang mahalagang patakaran ay nabubuhay sa forward hook. Kung saan kailangan ng pagsasalin ang susunod na interface, limitahan ang pinagmulan sa pool ng kliyente, ang destinasyon sa pinapayagan at ang labasan sa nag-iisang interface na iyon. Ang patakarang masquerade na nakatali lamang sa isang interface ay hindi pumipili ng ruta nang mag-isa at hindi pinapayagan ang pagpasa lampas sa anumang ibang filter.
Magpasya nang maaga sa pag-uugali ng pagsasara kapag nabigo, pagkatapos ay subukan ito. Itigil ang susunod na landas at kumpirmahin na nawawala ng mga kliyente ang nilalayong labasan sa halip na tahimik na bumalik sa karaniwang uplink, dahil iyon ang resultang walang makakapansin hanggang sa lumabas ang trapiko sa maling pinto. Ulitin ang pagsusuri para sa resolusyon ng pangalan at para sa IPv6, dahil ang set ng patakarang para sa v4 lamang ay nag-iiwan ng bukas na landas ng v6.
Isulat ang apat na sagot na napagkasunduan mo at ang obserbasyong nagpapatunay sa bawat isa. Ang landas ng transit na mailalarawan mo ay ang maipagtatanggol mo sa susunod na pagsusuri ng insidente.