Rute OpenVPN-klientar gjennom Cloudflare? Sjekk rolla først
Ein einingklient er ikkje ein ruter. Stadfest at Cloudflare-rolla sender vidare pakkar frå andre vertar, og hald den eigen tunnelen til tenaren på den gamle vegen sin.
Du har ein fungerande OpenVPN-tenar og ein vert som òg køyrer einingsprogramvara til Cloudflare, og det openberre neste steget ser ut som å peike klienttrafikken mot han. To fungerande samband på éin maskin utgjer ikkje ein transitport. Det som manglar, er ei rolle som er dokumentert for å senda vidare pakkar som høyrer til nokon andre, og ein politikk som klassifiserer desse pakkane når dei kjem.
Før kvar regel kjem fire spørsmål: kva trafikk som kjem inn, kvar han går vidare, korleis svara finn vegen tilbake, og kva designet gjer når den andre vegen sviktar. Dei to første er kapasitetsspørsmål.
To tenester på éin vert er ikkje ein transittveg
Ein einingklient er bygd for å handtera trafikk som oppstår på maskina der han køyrer. Han fangar opp namneoppslag, eller utvald applikasjonstrafikk, og sender det gjennom sin eigen tunnel, og politikken hans er skriven for brukaren av den eininga og prosessane til den eininga. Ein pakke som blir send vidare frå ein OpenVPN-klient er ikkje lokal utdata, så dei same reglane klassifiserer han ikkje. Dette er ikkje ein konfigurasjonsdetalj du kan dekkje over med ein breiare regel, fordi han avgjer om programvara i det heile ser pakken.
Derfor er designspørsmålet eit kapasitetsspørsmål. Anten har det installerte produktet ei dokumentert rolle som sender vidare trafikk for andre nettverk, eller høyrer transittfunksjonen heime ein heilt annan stad.
Kva Cloudflare-rolle har lov til å senda vidare
Einingsklienten til Cloudflare tilbyr modusar som varierer i omfang: berre namneoppslag, trafikk frå eininga, og nokre gonger begge. Ingen av desse modusane gjer verten til ein ruter for eit privat område som kjem inn over ein annan tunnel. Den dedikerte rutingsrolla er eit eige produkt med sin eigen connector, registrering og nettverksmodell.
| 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 |
Sjekk den installerte rolla før du designar ruter rundt henne. Les kva grensesnitt connectoren opprettar, om han annonserer bestemte prefiks eller ei standardrute, og om lokal politikk gjeld for vidaresende pakkar så vel som lokale. Blir berre lokal trafikk handtert, kan OpenVPN-tenaren ikkje vere transittpunktet, uansett korleis omsetjingsregelen er skriven.
Her må òg kravet om offentleg utgang formulerast presist. Ein utgang levert av Cloudflare for vidaresend klienttrafikk er eit bestemt brukstilfelle, og det må stadfestast mot tenesta du faktisk har.
Hald den ytre tunnelen uavhengig av den nye ruta
I det augneblinken du legg til ei standardrute mot det nye grensesnittet, byrjar den eigen utgåande trafikken til tenaren å konkurrere om henne, og det omfattar svar til OpenVPN-klientane og SSH-økta di til maskina. Det vanlege symptomet er ein tunnel som blir etablert og deretter døyr, eller ein administrator som blir låst ute medan endringa ser ut til å ha verka. Samanlikn ip route get for endepunktet før og etter, og bruk policy-ruting eller ei vertsrute for å halde den eigen transporten til tenaren der han var. Køyr den samanlikninga frå maskina sjølv, fordi tenaren sitt eige syn på ruta si er det som tel.
Eit unntak for den offentlege adressa til tenaren er ikkje nok i seg sjølv, fordi returvegen til kvar ekstern administrator er ein annan straum. Avgjer kva av desse straumane som må overleve endringa, og stadfest deretter kvar einskild i staden for å gå ut frå at den første dekkjer resten.
Avgrens vidaresendinga og omsetjinga til éin straum
Mottekne pakkar følgjer vidaresendingsvegen, ikkje den lokale utdatvegen, så regelen som tel, lever i forward-kroken. Der det neste grensesnittet treng omsetjing, avgrens kjelda til klientpoolen, målet til det som er tillate og utgangen til det eine grensesnittet. Ei masquerade-regel som berre er knytt til eit grensesnitt, vel inga rute sjølv og tillèt ikkje vidaresending forbi nokon annan filter.
Avgjer fail-closed-åtferda på førehand, og test henne deretter. Stopp den vidare vegen og stadfest at klientane mistar den tiltenkte utgangen i staden for å falle stille tilbake til den vanlege oppstraumslenkja, fordi det er resultatet ingen legg merke til før trafikken byrjar å gå ut gjennom feil dør. Gjenta kontrollen for namneoppslag og for IPv6, fordi eit regelsett berre for v4 lèt ein v6-veg stå open.
Skriv ned dei fire svara du landa på, og observasjonen som viser kvart av dei. Ein transittveg du kan skildre, er ein du kan forsvare på neste hendingsgjennomgang.