Direcționați clienții OpenVPN prin Cloudflare? Verificați mai întâi rolul
Un client de dispozitiv nu este un router. Confirmați că rolul Cloudflare redirecționează pachetele altor gazde și păstrați tunelul propriu al serverului pe vechea sa cale.
Aveți un server OpenVPN funcțional și o gazdă care rulează și software-ul de dispozitiv al Cloudflare, iar următorul pas evident pare să fie direcționarea traficului clienților către el. Două conexiuni funcționale pe o singură mașină nu formează o poartă de tranzit. Ce lipsește este un rol documentat pentru a redirecționa pachete care aparțin altcuiva, și o politică ce clasifică acele pachete când sosesc.
Înaintea oricărei reguli vin patru întrebări: ce trafic intră, unde merge mai departe, cum găsesc răspunsurile calea de întoarcere și ce face proiectarea când acea a doua cale eșuează. Primele două sunt întrebări de capacitate.
Două servicii pe o singură gazdă nu sunt o cale de tranzit
Un client de dispozitiv este construit să trateze traficul care provine de pe mașina pe care rulează. El interceptează rezolvarea numelor, sau traficul de aplicație selectat, și îl trimite prin propriul tunel, iar politica sa este scrisă pentru utilizatorul acelui dispozitiv și procesele acelui dispozitiv. Un pachet redirecționat de la un client OpenVPN nu este ieșire locală, așa că aceleași reguli nu îl clasifică. Acesta nu este un detaliu de configurare care poate fi acoperit cu o regulă mai largă, pentru că el decide dacă software-ul vede pachetul.
De aceea întrebarea de proiectare este o întrebare de capacitate. Fie produsul instalat are un rol documentat care redirecționează trafic pentru alte rețele, fie funcția de tranzit aparține cu totul altui loc.
Ce rol Cloudflare are voie să redirecționeze
Clientul de dispozitiv al Cloudflare oferă moduri care diferă ca amploare: doar rezolvarea numelor, trafic de la dispozitiv și uneori ambele. Niciunul dintre aceste moduri nu transformă gazda într-un router pentru un interval privat care sosește prin alt tunel. Rolul de rutare dedicat este un produs separat, cu propriul conector, înregistrare și model de rețea.
| 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 |
Verificați rolul instalat înainte de a proiecta rute în jurul lui. Citiți ce interfață creează conectorul, dacă anunță prefixe specifice sau o rută implicită și dacă politica locală se aplică pachetelor redirecționate la fel ca celor locale. Dacă este tratat doar traficul local, serverul OpenVPN nu poate fi punctul de tranzit, oricum ar fi scrisă regula de traducere.
Aici trebuie formulată precis și cerința de ieșire publică. O ieșire furnizată de Cloudflare pentru traficul clienților redirecționat este un caz de utilizare specific și trebuie confirmată față de serviciul pe care îl aveți cu adevărat.
Păstrați tunelul exterior independent de noua rută
În momentul în care adăugați o rută implicită către noua interfață, traficul de ieșire al serverului începe să concureze pentru ea, iar asta include răspunsurile către clienții OpenVPN și sesiunea dumneavoastră SSH către mașină. Simptomul obișnuit este un tunel care se stabilește și apoi moare, sau un administrator blocat afară în timp ce schimbarea pare să fi funcționat. Comparați ip route get pentru punctul final înainte și după, și folosiți rutarea bazată pe politică sau o rută de gazdă pentru a păstra transportul propriu al serverului acolo unde era. Rulați acea comparație de pe mașina însăși, pentru că viziunea serverului asupra propriei rute este cea care contează.
O excepție pentru adresa publică a serverului nu este suficientă de la sine, pentru că calea de întoarcere a fiecărui administrator la distanță este un flux diferit. Decideți care dintre aceste fluxuri trebuie să supraviețuiască schimbării, apoi verificați fiecare în loc să presupuneți că primul le acoperă pe celelalte.
Limitați redirecționarea și traducerea la un singur flux
Pachetele primite urmează calea de redirecționare, nu calea de ieșire locală, așa că regula care contează trăiește în cârligul forward. Unde interfața următoare are nevoie de traducere, limitați sursa la pool-ul de clienți, destinația la ce este permis și ieșirea la acea singură interfață. O regulă masquerade legată doar de o interfață nu alege singură nicio rută și nu permite redirecționarea dincolo de orice alt filtru.
Decideți dinainte comportamentul de închidere la eșec, apoi testați-l. Opriți calea următoare și confirmați că clienții pierd ieșirea dorită în loc să revină în tăcere la legătura ascendentă obișnuită, pentru că acesta este rezultatul pe care nimeni nu îl observă până când traficul nu începe să iasă pe ușa greșită. Repetați verificarea pentru rezolvarea numelor și pentru IPv6, pentru că un set de reguli doar pentru v4 lasă o cale v6 deschisă.
Notați cele patru răspunsuri la care v-ați oprit și observația care demonstrează fiecare. O cale de tranzit pe care o puteți descrie este una pe care o puteți apăra la următoarea revizuire a incidentelor.