Cloudflare

01Քայլ առ քայլ՝ դոմենի միացում

1) Ստեղծեք Cloudflare հաշիվ՝ երկգործոն նույնականացմամբ, և ավելացրեք ձեր կայքը (root դոմենը, օրինակ՝ example.com)։ Ընտրեք պլան․ սկսելու համար Free-ն բավական է։ 2) Cloudflare-ը սկանավորում է ձեր ընթացիկ DNS-ը և ներմուծում գտած գրառումները։ Զգուշորեն համեմատեք դրանք ձեր ընթացիկ zone-ի հետ, որովհետև սկանը կարող է բաց թողնել գրառումներ․ ստուգեք A, AAAA, CNAME, MX, յուրաքանչյուր TXT (SPF, DKIM selector-ներ, DMARC, հաստատումներ) և SRV։ 3) Cloudflare-ը ձեզ տալիս է երկու nameserver։ Ձեր registrar-ում առկա nameserver-ները փոխարինեք այդ երկուսով, և եթե DNSSEC-ը միացված է registrar-ում, նախ անջատեք այն (հետո կրկին միացրեք Cloudflare-ի միջոցով)։ 4) Սպասեք, մինչև zone-ը ցույց տա Active․ սովորաբար րոպեներ, մինչև 24 ժամ։ 5) Կարևոր գրառումների վրա proxy-ն միացնելուց առաջ պատրաստեք origin սերտիֆիկատը և SSL ռեժիմը (հաջորդ բաժիններ)։ 6) Ստուգեք dig-ով և curl-ով։

1# Nameservers switched?
2dig example.com NS +short
3# Proxied records return Cloudflare IPs, not your server's
4dig example.com A +short
5# Response passes through Cloudflare
6curl -sI https://example.com/ | grep -iE "server|cf-ray|cf-cache-status"

02Proxied (նարնջագույն ամպ) vs DNS only (մոխրագույն ամպ)

Յուրաքանչյուր A, AAAA և CNAME գրառում ունի proxy status։ Proxied նշանակում է, որ DNS-ը պատասխանում է Cloudflare-ի IP-ներով․ այցելուները միանում են Cloudflare-ին, որն էլ իր հերթին միանում է ձեր origin-ին։ Ստանում եք քեշավորում, WAF, DDoS պաշտպանություն և թաքնված origin IP։ DNS only նշանակում է, որ Cloudflare-ը պարզապես պատասխանում է ձեր իրական IP-ով, ինչպես ցանկացած DNS host, և պաշտպանությունից ոչինչ չի գործում։ Proxy արեք ձեր կայքի hostname-ները (example.com, www)։ DNS only թողեք այն, ինչ HTTP չէ կամ պետք է անմիջապես հասնի սերվերին՝ MX գրառումներում օգտագործվող mail host-երը, SSH-ի կամ տվյալների բազայի hostname-ները և ծառայությունները այն պորտերում, որոնք Cloudflare-ը proxy չի անում։ Հիշեք, որ նույն սերվերին ցույց տվող մեկ DNS-only գրառումն անգամ բացահայտում է origin IP-ն, ուստի վեբ սերվերի հասցեի համար այդպիսին մի ստեղծեք, եթե իսկապես պետք չէ։

• Proxy՝ վեբ թրաֆիկ ստանդարտ HTTP(S) պորտերով։
• DNS only՝ փոստ, SSH, FTP, խաղային կամ custom TCP/UDP ծառայություններ։
• MX գրառումները չեն կարող ցույց տալ proxied hostname։

03SSL/TLS ռեժիմներ՝ ինչու Full (strict)

Երկու կապ կա՝ այցելուից Cloudflare, և Cloudflare-ից ձեր origin։ SSL/TLS encryption mode-ը կառավարում է երկրորդը։ Off՝ ընդհանրապես HTTPS չկա։ Flexible՝ HTTPS այցելուի հետ, պարզ HTTP ձեր սերվերի հետ․ կողպեքը երևում է, բայց origin-ի հետ թրաֆիկը գաղտնագրված չէ, իսկ HTTP-ն HTTPS-ի redirect անող origin-ը անվերջ loop է ստեղծում։ Full՝ HTTPS դեպի origin, բայց սերտիֆիկատը չի ստուգվում, այնպես որ self-signed կամ ժամկետանց սերտիֆիկատն անցնում է, և man in the middle-ը նույնպես կարող է անցնել։ Full (strict)՝ HTTPS դեպի origin, և սերտիֆիկատը պետք է վավեր լինի ու համապատասխանի hostname-ին՝ թողարկված հանրային CA-ի կամ Cloudflare-ի Origin CA-ի կողմից։ Միշտ ձգտեք Full (strict)-ի։ Սերվերի վրա տեղադրեք կա՛մ Let's Encrypt սերտիֆիկատ (certbot), կա՛մ անվճար Cloudflare Origin Certificate, հետո փոխեք ռեժիմը։ Cloudflare-ն առաջարկում է նաև Automatic ռեժիմ, որն ընտրում է ձեր origin-ի աջակցած ամենաուժեղ ռեժիմը, բայց Full (strict)-ը բացահայտ սահմանելն ավելի պարզ է։

1# nginx on the origin with a Cloudflare Origin Certificate
2server {
3    listen 443 ssl;
4    http2 on;
5    server_name example.com www.example.com;
6    ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
7    ssl_certificate_key /etc/ssl/cloudflare/example.com.key;
8    root /var/www/example/public;
9}

04HTTPS ամենուր, քեշավորում և performance

SSL/TLS > Edge Certificates բաժնում միացրեք Always Use HTTPS-ը, որը յուրաքանչյուր http:// հարցում redirect է անում edge-ում, և Minimum TLS Version-ը դրեք 1.2։ HSTS-ը միացրեք միայն այն բանից հետո, երբ ամբողջ կայքը և ներառված յուրաքանչյուր subdomain աշխատում են HTTPS-ով՝ սկսելով կարճ max-age-ից․ երբ բրաուզերներն այն քեշավորեն, կհրաժարվեն պարզ HTTP-ից։ Լռելյայն Cloudflare-ը ստատիկ ֆայլերը քեշավորում է ըստ ընդլայնման (պատկերներ, CSS, JS, ֆոնտեր) և HTML չի քեշավորում։ Cache Rules-ը թույլ է տալիս դա փոխել՝ հանրային HTML-ը քեշավորել կարճ ժամանակով, bypass անել այն ամենը, ինչ ունի session cookie, /admin, /api և /checkout, և սահմանել Edge և Browser TTL-ներ։ cf-cache-status header-ը ցույց է տալիս HIT, MISS, BYPASS կամ DYNAMIC։ Deploy-ից հետո purge արեք ըստ URL-ի, կամ ավելի լավ՝ օգտագործեք տարբերակավորված ֆայլանուններ, որպեսզի purge-ը հազվադեպ պետք լինի։ HTTP/3-ն ու Brotli-ն ընթացիկ պլաններում լռելյայն միացված են։

• Երբեք մի քեշավորեք էջեր, որոնք կախված են cookie-ներից կամ login վիճակից։
• Փոփոխությունները ստուգելու համար օգտագործեք Development Mode կամ purge․ մի անջատեք քեշավորումը գլոբալ։
• Խուսափեք Rocket Loader-ից և HTML minification-ի հնարքներից, որոնք կարող են կոտրել JavaScript հավելվածները․ նախ ստուգեք։

05Անվտանգություն՝ WAF, rate limiting, DDoS, origin-ի փակում

Ցանցային և HTTP flood-երից DDoS պաշտպանությունը ավտոմատ է յուրաքանչյուր պլանում proxied թրաֆիկի համար։ Managed WAF ruleset-ը (վճարովի պլաններում՝ ավելի լայն ruleset-ներով) արգելափակում է տարածված հարձակումները, օրինակ՝ SQL injection-ի օրինաչափությունները։ Custom rule-երը թույլ են տալիս արգելափակել կամ challenge անել ըստ երկրի, path-ի, user agent-ի կամ bot score-ի, օրինակ՝ managed challenge /wp-login.php-ի կամ /admin-ի վրա սպասվող երկրներից դուրս։ Rate limiting rule-երը սահմանափակում են մեկ IP-ից հարցումների քանակը զգայուն endpoint-ների վրա, ինչպիսիք են login-ը, OTP-ն և գաղտնաբառի վերականգնումը։ Bot Fight Mode-ն ավելացնում է բոտերից հիմնական պաշտպանություն։ Proxy-ն օգնում է միայն այն դեպքում, եթե հարձակվողները չեն կարող անմիջապես հասնել origin-ին․ firewall-ով փակեք սերվերը, որպեսզի 80 և 443 պորտերն ընդունեն միայն Cloudflare-ի հրապարակված IP միջակայքերը (կամ օգտագործեք Cloudflare Tunnel, որին բաց inbound պորտեր պետք չեն), և SSH-ը սահմանափակեք բանալիներով և վստահելի IP-ներով։ Under Attack Mode-ը վթարային անջատիչ է, որը challenge է անում յուրաքանչյուր այցելուի։

1# ufw: allow web traffic only from Cloudflare (ranges from cloudflare.com/ips)
2for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
3  sudo ufw allow proto tcp from "$ip" to any port 80,443
4done
5sudo ufw status numbered

06Այցելուի իրական IP-ն origin-ում

Proxy-ի հետևում յուրաքանչյուր հարցում ձեր սերվերին հասնում է Cloudflare-ի IP-ից։ Արդյունքում լոգերը, rate limiting-ը, fail2ban-ը և fraud-ի ստուգումները այցելուի փոխարեն տեսնում են Cloudflare-ը և կարող են նույնիսկ արգելափակել հենց Cloudflare-ին։ Cloudflare-ը սկզբնական հասցեն ուղարկում է CF-Connecting-IP header-ով (և X-Forwarded-For-ով)։ realip մոդուլով nginx-ին ասեք վստահել այդ header-ին միայն այն դեպքում, երբ հարցումը գալիս է Cloudflare-ի միջակայքերից։ Այդ ժամանակ $remote_addr-ն ամենուր դառնում է այցելուի IP-ն։ nginx-ի հետևում գտնվող Laravel կամ Node հավելվածներում կարգավորեք նաև trusted proxies, որպեսզի framework-ը կարդա client-ի ճիշտ IP-ն և scheme-ը։ Երբեք մի վստահեք header-ին կամայական աղբյուրներից, այլապես ցանկացած մեկը կարող է կեղծել իր IP-ն։

1# /etc/nginx/conf.d/cloudflare-realip.conf (list all current ranges)
2set_real_ip_from 173.245.48.0/20;
3set_real_ip_from 103.21.244.0/22;
4set_real_ip_from 2400:cb00::/32;
5# ... remaining ranges from https://www.cloudflare.com/ips/
6real_ip_header CF-Connecting-IP;

0752x սխալների և redirect loop-երի լուծում

Երբ Cloudflare-ը սխալի էջ է ցույց տալիս, խնդիրը գրեթե միշտ Cloudflare-ի և ձեր origin-ի միջև է։ 521 Web server is down՝ origin-ը մերժել է կապը․ nginx-ը կանգնել է, կամ firewall-ն արգելափակում է Cloudflare-ի IP-ները։ 522 Connection timed out՝ Cloudflare-ը չի կարողացել ավարտել TCP կապը․ սերվերը ծանրաբեռնված է, DNS-ում սխալ IP է, կամ firewall-ը գցում է փաթեթները։ 524՝ կապը հաջողվել է, բայց հավելվածը պատասխանելու համար մոտ 125 վայրկյանից (proxy-ի ստանդարտ timeout) ավելի է ծախսել․ երկար աշխատանքը տեղափոխեք հերթեր (queue)։ 525 SSL handshake failed՝ origin-ը 443-ում TLS չի խոսում կամ այդ hostname-ի համար սերտիֆիկատ չունի (SNI)։ 526 Invalid SSL certificate՝ Full (strict)-ում origin-ի սերտիֆիկատը ժամկետանց է, self-signed է կամ այլ անվան համար է։ Too many redirects՝ սովորաբար Flexible ռեժիմ գումարած origin, որը HTTP-ն redirect է անում HTTPS-ի․ անցեք Full (strict)-ի։ Ստուգեք origin-ի լոգերը և origin-ը թեստավորեք ուղղակիորեն։

1# Test the origin directly, bypassing Cloudflare
2curl -svI https://example.com/ --resolve example.com:443:203.0.113.10 2>&1 | grep -E "HTTP/|subject|expire|issuer"
3sudo systemctl status nginx
4sudo tail -n 50 /var/log/nginx/error.log

08Ինչ է կատարվում հարցման հետ Cloudflare-ի ներսում

Երբ այցելուն միանում է proxied hostname-ին, anycast-ը նրան ուղղում է մոտակա Cloudflare data center, որտեղ TLS-ն ավարտվում է edge սերտիֆիկատով։ Հետո հարցումն անցնում է մի շարք փուլերով՝ ֆիքսված հերթականությամբ։ Առաջինը ցանցային և HTTP DDoS mitigation-ն է։ Հետո անվտանգության կանոնները. IP access rule-եր, WAF custom rule-եր, rate limiting rule-եր և managed WAF ruleset-ներ, գումարած bot ստուգումներ։ Configuration rule-երը, redirect rule-երը և URL rewrite-երը ճշգրտում են հարցումը։ Եթե route-ին կցված են Workers, դրանք աշխատում են հաջորդը և կարող են պատասխանել կամ փոփոխել հարցումը։ Միայն դրանից հետո է cache-ը փնտրում cache key-ը։ Miss-ի դեպքում Origin Rules-ը կարող է փոխել host-ը, port-ը կամ SNI-ն, և հարցումը գնում է ձեր origin, հնարավոր է՝ նախ ռեգիոնալ շերտով։ Այս հերթականությունն իմանալը բացատրում է, օրինակ, թե ինչու WAF rule-ը արգելափակում է հարցում, որն ամեն դեպքում cache hit կլիներ։

• Անվտանգությունն աշխատում է cache-ից առաջ, ուստի արգելափակված հարցումները երբեք չեն ծախսում cache կամ origin։
• Dashboard-ում օգտագործեք Trace-ը՝ տեսնելու, թե որ կանոններն են համընկել տվյալ URL-ի համար։
• Workers-ն աշխատում են cache-ից առաջ. Worker-ի ներսում օգտագործեք Cache API-ն՝ նրա արդյունքը քեշավորելու համար։

09Cache key-եր, tiered cache և origin-ի cache header-ներ

Cache key-ը որոշում է, թե ինչն է համարվում նույն օբյեկտը։ Լռելյայն այն ներառում է scheme-ը, host-ը, path-ը և ամբողջ query string-ը, ուստի ?utm_source=x-ը ստեղծում է առանձին պատճեն. Cache Rule-ը կարող է անտեսել կամ դասավորել query string-երը, կամ key-ին ավելացնել header կամ cookie։ Cloudflare-ը լռելյայն հարգում է origin-ի Cache-Control-ը քեշավորվող բովանդակության համար. s-maxage-ը և max-age-ը սահմանում են edge-ի կյանքի տևողությունը, private-ը և no-store-ը արգելում են պահելը, իսկ պատասխանի Set-Cookie-ն սովորաբար կանխում է քեշավորումը։ Cache Rule-ի Edge TTL-ը կարող է վերագրել origin-ի header-ները, ինչը հզոր է և վտանգավոր։ Tiered Cache-ը ստիպում է ցածր շերտի data center-ներին հարցնել վերին շերտին՝ ձեր origin-ի փոխարեն, ինչը բարձրացնում է hit ratio-ն և պաշտպանում փոքր VPS-ը։ Purge-ի տարբերակներն են՝ մեկ URL, ամեն ինչ, իսկ որոշ պլաններում՝ tag, prefix կամ hostname purge։

1# Let the origin control edge vs browser caching
2location /blog/ {
3    add_header Cache-Control "public, max-age=60, s-maxage=600, stale-while-revalidate=300";
4}
5location /account/ {
6    add_header Cache-Control "private, no-store";
7}
8# Check: curl -sI https://example.com/blog/ | grep -iE "cf-cache-status|age|cache-control"

10Origin-ի փակում. Authenticated Origin Pulls և Tunnel

Firewall-ով միայն Cloudflare-ի IP range-երը թույլատրելը կանգնեցնում է պատահական scanner-ներին, բայց ցանկացած Cloudflare հաճախորդի տրաֆիկ նույնպես գալիս է այդ range-երից։ Կան երկու ավելի ուժեղ տարբերակ։ Authenticated Origin Pulls-ը օգտագործում է mutual TLS. Cloudflare-ը ձեր origin-ին միանալիս ներկայացնում է client սերտիֆիկատ, իսկ nginx-ը մերժում է ցանկացած TLS կապ առանց դրա։ Zone-level pull-երը օգտագործում են Cloudflare-ի թողարկած սերտիֆիկատ, per-hostname pull-երը թույլ են տալիս վերբեռնել ձերը, ինչն ավելի խիստ է, քանի որ այն օգտագործում է միայն ձեր zone-ը։ Cloudflare Tunnel-ը գնում է ավելի հեռու. փոքր daemon՝ cloudflared, աշխատում է ձեր սերվերում և բացում է ելքային կապեր դեպի Cloudflare, ուստի սերվերին ընդհանրապես պետք չեն հրապարակային մուտքային web port-եր։ Tunnel-ն աշխատում է նաև ներքին գործիքների համար՝ Cloudflare Access-ի հետ միասին, որը login է դնում հավելվածի առջև։ Գինը ևս մեկ agent է, որը պետք է մոնիթորինգ անել և թարմացնել։

1# nginx: accept only connections that present Cloudflare's client cert
2ssl_client_certificate /etc/ssl/cloudflare/authenticated_origin_pull_ca.pem;
3ssl_verify_client on;
4 
5# Or: no open ports, with Cloudflare Tunnel
6cloudflared tunnel login
7cloudflared tunnel create web-prod
8cloudflared tunnel route dns web-prod app.example.com
9cloudflared tunnel run web-prod

11Սահմանափակումներ և edge case-եր, որոնք պետք է հաշվի առնել

Պլատֆորմի մի քանի սահմանափակում ձևավորում է ճարտարապետությունը։ Proxy-ով վերբեռնումների request body-ի չափը սահմանափակված է ըստ պլանի (100 MB Free և Pro պլաններում), ուստի մեծ վերբեռնումները պետք է գնան ուղիղ object storage՝ presigned URL-ներով։ Proxy read timeout-ը 524 է տալիս, երբ origin-ը չափազանց երկար լռում է. ընթացիկ փաստաթղթերը նշում են մոտ երկու րոպե լռելյայն արժեք, որը կարելի է բարձրացնել միայն Enterprise-ում, ուստի երկար հաշվետվություններն ու import-ները պետք է լինեն background job-երում՝ polling-ով կամ webhook-ներով։ WebSocket-ները աջակցվում են, բայց երկարակյաց կապերը կարող են reset լինել Cloudflare-ի սպասարկման ժամանակ, ուստի client-ները պետք է վերամիանան։ Proxy են արվում միայն որոշակի port-եր (HTTPS-ի համար, օրինակ, 443, 2053, 2083, 2087, 2096 և 8443)։ Անվճար Universal սերտիֆիկատը ծածկում է apex-ը և subdomain-ի մեկ մակարդակ, ուստի ավելի խորը անունները, ինչպես a.b.example.com, պահանջում են advanced սերտիֆիկատ։ Դիզայնի վրա կանգ առնելուց առաջ ստուգեք պլանի ընթացիկ սահմանափակումները։