A migráció 0. fázisának anyaga — az a réteg, ami már a Workers előtt is létezett. DNS-zónák és a narancs felhő, TLS-módok (és a klasszikus lábonlövés), a szabálymotor, és a legfontosabb: milyen sorrendben fut le minden, mire a kódod meghívódik.
Amikor egy domaint a Cloudflare alá viszel, létrejön egy zóna, és a domain nameszerverei a Cloudflare-re mutatnak. Innentől minden DNS-rekordnál eldöntöd a legfontosabb dolgot: proxyzott (narancs felhő) vagy csak DNS (szürke felhő).
| 🟠 Proxyzott | ⚪ DNS-only | |
|---|---|---|
| Mit lát a világ | a Cloudflare IP-jét — az origined címe rejtve marad | a valódi IP-det |
| Áthalad rajta | CDN, cache, WAF, DDoS-védelem, Workers-route-ok | semmi — a Cloudflare csak névfeloldást ad |
| Mikor kell | minden webes forgalomnál | SMTP, SSH, adatbázis-hostok, tanúsítvány-validáció |
mail vagy egy adatbázis-host rekordját narancsra állítod, eltörik a szolgáltatás (a proxy csak HTTP(S)-forgalmat kezel a szokásos portokon).Két különálló kapcsolat van: a látogató → Cloudflare és a Cloudflare → origin. Az SSL/TLS-mód a másodikról szól, és itt lehet csendben titkosítatlan forgalmat hagyni:
| Mód | Mit jelent | Használd? |
|---|---|---|
| Off | nincs titkosítás | soha |
| Flexible | látogató→CF titkosított, CF→origin nyílt | csak ha az origin képtelen TLS-re — és akkor is átmenetileg |
| Full | mindkét szakasz titkosított, de az origin tanúsítványát nem ellenőrzi (lehet lejárt, önaláírt, rossz névre szóló) | átmeneti |
| Full (strict) | titkosított + a tanúsítvány érvényes, publikusan megbízható CA-tól vagy Cloudflare Origin CA-tól, egyező névvel | ez a cél |
Az origin-tanúsítványt ingyen megkapod a Cloudflare Origin CA-tól (hosszú lejáratú, kifejezetten erre a szakaszra). Egy szinttel tovább az Authenticated Origin Pulls (mTLS): ekkor az origined csak olyan kérést fogad el, ami a Cloudflare-től jön kliens-tanúsítvánnyal — így senki nem tudja megkerülni a WAF-ot az origin IP-jének ismeretében. Fontos részletek: AOP nem működik Flexible/Off módban, és nem kompatibilis a Cloudflare Tunnellel (ott a tunnel saját hitelesítése adja ugyanezt).
Ez a modul legfontosabb szakasza, mert konkrét hibakeresési időt spórol. Egy proxyzott kérés nem egyenesen a Workeredhez megy: több réteg fut le előtte, és ezek felül tudják írni vagy meg tudják állítani a kérést, mielőtt a kódod egyáltalán meghívódna.
A gyakorlati következmények, amiket érdemes fejben tartani:
request.cf mezők (ország, colo, bot-pontszám, TLS-adatok) azért állnak rendelkezésre a kódodban, mert ezek a korábbi rétegekben már kiszámolódtak.Sok mindent kétféleképpen is megoldhatsz: egy dashboardon felvett szabállyal vagy néhány sor kóddal a Workerben. Az irányelv egyszerű:
| Szabálytípus | Mire való | Kód helyett? |
|---|---|---|
| Redirect Rules | régi URL-ek átirányítása, domain-konszolidáció (www → csupasz) | igen — ne terheld ezzel a Workert |
| Transform Rules | URL-átírás, kérés/válasz-fejlécek módosítása | egyszerű esetben igen |
| Configuration Rules | zóna-beállítások felülírása útvonalanként | igen |
| Custom Rules (WAF) | blokkolás/kihívás feltétel szerint (ország, ASN, path, header) | igen — a Worker előtt fut, tehát olcsóbb és gyorsabb |
| Cache Rules | cache-viselkedés útvonalanként | Workers Cachinggel átfed (18. modul) — válassz egyet, ne keverd |
| Üzleti logika | bármi, ami a te adataidtól függ | nem — ez Worker-kód |
A 4. modulban felmerült, hogy a Hyperdrive-nak el kell érnie az Auroráját. Három út van, és érdemes tudni a különbséget:
| Megoldás | Hogyan | Mikor |
|---|---|---|
| Publikus + IP-szűrés | az origin publikusan elérhető, de csak a Cloudflare IP-tartományaiból (+ AOP) | gyors megoldás, ha a hálózati csapat engedi |
| Cloudflare Tunnel | a te oldaladon fut egy cloudflared konnektor, ami kifelé épít kapcsolatot — nincs nyitott bejövő port, nincs publikus IP | ez az ajánlott: privát VPC-hez, on-prem szolgáltatáshoz, belső admin-felülethez |
| Workers VPC | a Workered privát hálózati erőforrást ér el | ha mélyebb hálózati integráció kell |
A Tunnel a migráció alatt kétszeresen hasznos: egyrészt így éri el a Hyperdrive az Aurorát anélkül, hogy azt publikussá tennéd, másrészt a belső eszközeidet (admin, monitoring, adminer) is kiteheted rá — Cloudflare Access-szel a login elé (9. modul), VPN nélkül.
① A DNS-rekord szürke (DNS-only), tehát a forgalom nem megy át a proxyn; ② egy redirect- vagy transform-szabály előbb fut és átirányít/átír; ③ a WAF vagy egy rate limit szabály blokkol (a Security Eventsben látszik) — vagy cache-találat van a Worker előtt (18. modul).
Mert a látogató HTTPS-t lát (lakat a böngészőben), miközben a Cloudflare→origin szakasz titkosítatlan — vagyis a védelem látszólagos. Emellett AOP sem működik ilyenkor. A cél a Full (strict), origin-tanúsítvánnyal (akár ingyenes Cloudflare Origin CA-tól).
Az origined csak olyan kérést fogad el, amit a Cloudflare kliens-tanúsítvánnyal küld — így nem lehet az origin IP ismeretében megkerülni a WAF-ot. Nem használható Off/Flexible módban, és nem kompatibilis a Cloudflare Tunnellel (ott a tunnel hitelesítése adja ugyanezt).
Szabállyal, ami statikus és nem függ az adataidtól (átirányítás, fejléc-módosítás, ország/ASN-alapú blokkolás) — ez a Worker előtt fut, nem fogyaszt CPU-t, és nem-fejlesztő is látja. Kóddal, ami a felhasználótól, tenanttól vagy adatbázistól függ. Ugyanazt a path-t ne kezelje mindkettő.
Mert a konnektor kifelé épít kapcsolatot: nem kell publikus IP-t vagy bejövő portot nyitni a VPC-ben. Ugyanezzel a mechanizmussal a belső eszközeidet is közzéteheted Cloudflare Access mögött, VPN nélkül.