Dirigera OpenVPN-klienter via Cloudflare? Kontrollera rollen först
En enhetsklient är inte en router. Bekräfta att Cloudflare-rollen vidarebefordrar andra värdars paket och håll serverns egen tunnel på sin gamla väg.
Du har en fungerande OpenVPN-server och en värd som också kör Cloudflares enhetsprogramvara, och nästa uppenbara steg ser ut som att rikta klienttrafiken dit. Två fungerande anslutningar på en maskin utgör ingen transitgateway. Det som saknas är en roll som är dokumenterad för att vidarebefordra paket som tillhör någon annan, och en policy som klassificerar dessa paket när de anländer.
Före varje regel kommer fyra frågor: vilken trafik som kommer in, vart den tar vägen sedan, hur svaren hittar tillbaka, och vad designen gör när den andra vägen fallerar. De två första är kapacitetsfrågor.
Två tjänster på en värd är inte en transitväg
En enhetsklient är byggd för att hantera trafik som uppstår på maskinen där den körs. Den fångar upp namnmatchning, eller utvald applikationstrafik, och skickar den genom sin egen tunnel, och dess policy är skriven för enhetens användare och enhetens processer. Ett paket som vidarebefordras från en OpenVPN-klient är inte lokal utdata, så samma regler klassificerar det inte. Det är inte en konfigurationsdetalj som du kan täcka över med en bredare regel, eftersom den avgör om programvaran överhuvudtaget ser paketet.
Därför är designfrågan en kapacitetsfråga. Antingen har den installerade produkten en dokumenterad roll som vidarebefordrar trafik för andra nätverk, eller hör transitfunktionen hemma någon helt annanstans.
Vilken Cloudflare-roll får vidarebefordra
Cloudflares enhetsklient erbjuder lägen som skiljer sig i omfattning: bara namnmatchning, trafik från enheten och ibland båda. Inget av dessa lägen gör värden till en router för ett privat intervall som anländer via en annan tunnel. Den dedikerade routingrollen är en separat produkt med egen connector, registrering och nätverksmodell.
| 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 |
Kontrollera den installerade rollen innan du designar rutter runt den. Läs vilket gränssnitt connectorn skapar, om den annonserar specifika prefix eller en standardrutt, och om lokal policy gäller för vidarebefordrade paket såväl som lokala. Om bara lokal trafik hanteras kan OpenVPN-servern inte vara transitpunkten, oavsett hur översättningsregeln är skriven.
Här måste också kravet på offentlig utgång formuleras exakt. En utgång som Cloudflare tillhandahåller för vidarebefordrad klienttrafik är ett specifikt användningsfall, och det måste bekräftas mot den tjänst du faktiskt har.
Håll den yttre tunneln oberoende av den nya rutten
I samma ögonblick som du lägger till en standardrutt mot det nya gränssnittet börjar serverns egen utgående trafik konkurrera om den, och det inkluderar svar till OpenVPN-klienterna och din SSH-session till maskinen. Det vanliga symptomet är en tunnel som etableras och sedan dör, eller en administratör utelåst medan ändringen verkar ha fungerat. Jämför ip route get för slutpunkten före och efter, och använd policybaserad routing eller en värdrutt för att hålla serverns egen transport där den var. Kör den jämförelsen från maskinen själv, eftersom serverns egen syn på sin rutt är den som räknas.
Ett undantag för serverns offentliga adress räcker inte i sig, eftersom varje fjärradministratörs returväg är ett annat flöde. Bestäm vilka av dessa flöden som måste överleva ändringen och verifiera sedan varje enskilt i stället för att anta att det första täcker resten.
Begränsa vidarebefordran och översättningen till ett flöde
Mottagna paket följer vidarebefordringsvägen, inte den lokala utdatavägen, så regeln som betyder något lever i forward-kroken. Där nästa gränssnitt behöver översättning, begränsa källan till klientpoolen, målet till det som är tillåtet och utgången till det enda gränssnittet. En masquerade-regel som bara är knuten till ett gränssnitt väljer ingen rutt själv och tillåter inte vidarebefordran förbi något annat filter.
Bestäm fail-closed-beteendet i förväg och testa det sedan. Stoppa den vidare vägen och bekräfta att klienterna förlorar den avsedda utgången i stället för att tyst falla tillbaka på den vanliga upplänken, eftersom det är resultatet ingen märker förrän trafiken börjar gå ut genom fel dörr. Upprepa kontrollen för namnmatchning och för IPv6, eftersom en regeluppsättning bara för v4 lämnar en v6-väg öppen.
Skriv ner de fyra svar du landade i och den observation som visar vart och ett. En transitväg du kan beskriva är en du kan försvara vid nästa incidentgenomgång.