OpenVPN-i klientide suunamine läbi Cloudflare'i? Kontrollige esmalt rolli
Seadmeklient ei ole ruuter. Kinnitage, et Cloudflare'i roll edastab teiste hostide pakette, ja jätke serveri enda tunnel vanale teele.
Teil on töötav OpenVPN server ja host, mis käitab ka Cloudflare'i seadmetarkvara, ning ilmne järgmine samm näib olevat kliendiliikluse suunamine selle poole. Kaks töötavat ühendust ühes masinas ei moodusta transiidilüüsi. Puudu on roll, mis on dokumenteeritud teisele kuuluvate pakettide edastamiseks, ja poliitika, mis need paketid saabudes klassifitseerib.
Enne iga reeglit tuleb neli küsimust: milline liiklus siseneb, kuhu see edasi läheb, kuidas leiavad vastused tagasitee ja mida teeb disain, kui see teine tee ebaõnnestub. Esimesed kaks on võimekuse küsimused.
Kaks teenust ühes hostis ei ole transiiditee
Seadmeklient on loodud käsitlema liiklust, mis tekib masinas, kus see töötab. See püüab kinni nimelahenduse või valitud rakendusliikluse ja saadab selle oma tunnelist, ning selle poliitika on kirjutatud selle seadme kasutaja ja selle seadme protsesside jaoks. OpenVPN-i kliendist edastatud pakett ei ole kohalik väljund, seega samad reeglid ei klassifitseeri seda. See ei ole konfiguratsiooni detail, mille saaks katta laiema reegliga, sest see otsustab, kas tarkvara üldse paketti näeb.
Seetõttu on disainiküsimus võimekuse küsimus. Kas paigaldatud tootel on dokumenteeritud roll, mis edastab liiklust teiste võrkude jaoks, või kuulub transiidifunktsioon hoopis teise kohta.
Milline Cloudflare'i roll tohib edastada
Cloudflare'i seadmeklient pakub režiime, mis erinevad ulatuselt: ainult nimelahendus, seadmest tulev liiklus ja mõnikord mõlemad. Ükski neist režiimidest ei muuda hosti ruuteriks privaatse vahemiku jaoks, mis saabub teise tunneli kaudu. Spetsiaalne marsruutimisroll on eraldi toode, millel on oma konnektor, registreerimine ja võrgumudel.
| 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 |
Kontrollige paigaldatud rolli enne, kui projekteerite selle ümber marsruute. Lugege, millise liidese konnektor loob, kas see kuulutab konkreetseid prefikseid või vaikimisi marsruuti, ja kas kohalik poliitika kehtib ka edastatud pakettidele, mitte ainult kohalikele. Kui käsitletakse ainult kohalikku liiklust, ei saa OpenVPN-i server olla transiidipunkt, ükskõik kuidas tõlkereegel on kirjutatud.
Siin tuleb ka avaliku väljapääsu nõue täpselt sõnastada. Cloudflare'i pakutav väljapääs edastatud kliendiliikluse jaoks on konkreetne kasutusjuht ja see tuleb kinnitada tegelikult olemasoleva teenuse vastu.
Hoidke välimine tunnel uuest marsruudist sõltumatuna
Hetkest, mil lisate uue liidese suunas vaikimisi marsruudi, hakkab serveri enda väljuv liiklus selle nimel võistlema, ja see hõlmab vastuseid OpenVPN-i klientidele ning teie SSH-seanssi masinasse. Tavaline sümptom on tunnel, mis luuakse ja siis sureb, või administraator, kes jääb välja lukustatuks, samal ajal kui muudatus näib töötavat. Võrrelge ip route get lõpp-punkti jaoks enne ja pärast ning kasutage poliitikapõhist marsruutimist või hosti marsruuti, et hoida serveri enda transport seal, kus see oli. Tehke see võrdlus masina enda pealt, sest serveri enda vaade oma marsruudile on see, mis loeb.
Erand serveri avaliku aadressi jaoks ei ole iseenesest piisav, sest iga kaugadministraatori tagasitee on erinev voog. Otsustage, millised neist voogudest peavad muudatuse üle elama, ja seejärel kontrollige igaüht, selle asemel et eeldada, et esimene katab ülejäänud.
Piiritle edastamine ja tõlkimine ühe vooga
Vastuvõetud paketid järgivad edastusteed, mitte kohalikku väljundteed, seega elab oluline reegel forward-konksus. Kui järgmine liides vajab tõlkimist, piirake allikas kliendipõhiseks, sihtkoht lubatuga ja väljapääs selle ühe liidesega. Ainult liidesega seotud masquerade-reegel ei vali ise ühtegi marsruuti ega luba edastamist ühestki teisest filtrist mööda.
Otsustage sulgemisega ebaõnnestumise käitumine ette ja testige seda seejärel. Peatage järgmine tee ja kinnitage, et kliendid kaotavad kavandatud väljapääsu, selle asemel et vaikselt tavalisse ülesvoolu lülituda, sest see on tulemus, mida keegi ei märka enne, kui liiklus hakkab väljuma valest uksest. Korrake kontrolli nimelahenduse ja IPv6 jaoks, sest ainult v4 jaoks mõeldud reeglistik jätab v6 tee avatuks.
Kirjutage üles need neli vastust, millega te lõpuks jäite, ja tähelepanek, mis igaüht tõestab. Transiiditee, mida suudate kirjeldada, on see, mida suudate järgmisel juhtumite ülevaatusel kaitsta.