กำหนดการวันนี้ (7 ชม.)

เตรียมเครื่องก่อนเริ่ม Workshop (macOS)

ชุดไฟล์ workshop (cloudflare-workshop-mac.zip) แจกพร้อมสไลด์ —
แตกแล้วรัน ./setup.sh ติดตั้งส่วนที่ขาด แล้ว ./check-env.sh
ทุกบรรทัด ✓ = พร้อมทำ WS1–WS6 ทั้งเล่ม

Cloudflare คืออะไร?

เครือข่าย edge ระดับโลกที่ทำหน้าที่ reverse proxy ให้เว็บของคุณ

• ผู้ใช้เข้าเว็บผ่านเครือข่าย Cloudflare → Cloudflare ดึงข้อมูลจาก server ต้นทางให้
• ทำให้ เร็วขึ้น (CDN + cache) และ ปลอดภัยขึ้น (ซ่อน IP, กรอง bot/DDoS)
• ตัวเลขปี 2026: 335+ เมือง · 100+ ประเทศ · ความจุ 500+ Tbps
  ให้บริการประมาณ 20% ของเว็บทั้งโลก

ใช้งาน แผนฟรี ได้ครบทุกฟีเจอร์ที่เราเรียนวันนี้

Before / After — มี Cloudflare ต่างกันอย่างไร

CDN ทำงานอย่างไร?

1. ผู้ใช้ขอหน้าเว็บ → ไปที่ edge ที่ ใกล้ตัวที่สุด (กรุงเทพฯ มี node)
2. ถ้าเป็นไฟล์ static (รูป, CSS, JS) ที่มีคนขอแล้ว → ตอบจาก cache ทันที
3. ถ้าเป็นหน้า dynamic → ไปดึงจากต้นทาง แล้ว ส่งต่อผ่านเส้นทางที่เร็วกว่า

ผลลัพธ์

• ลด TTFB (Time To First Byte) และ latency
• ลดโหลดที่ server ต้นทาง
• ผู้ใช้ไทยเปิดเว็บเร็วขึ้นชัดเจนแม้ server อยู่ต่างประเทศ

ภัยคุกคาม: DDoS ที่เพิ่มขึ้นทุกปี

• Amazon เคยล่ม 15–45 นาที (2013) เสียประมาณ 5.3 ล้านดอลลาร์
• ปัจจุบันมีบริการ DDoS-as-a-Service เริ่มต้นเพียง $5 — โจมตีเว็บคนอื่นง่ายเหมือนสั่งกาแฟ
• ชนิดการโจมตี
  • Layer 3/4: TCP / UDP / ACK flood — ท่วมทรัพยากรเครือข่าย
  • Layer 7: slow attack — ยิงหน้าหนัก ๆ ให้ app ของคุณทำงานตาย

Cloudflare ดูดซับการโจมตีที่ edge ก่อนถึงคุณ — ไม่จำกัดปริมาณ (unmetered DDoS mitigation) แม้แผนฟรี

สมัครบัญชี Cloudflare (ทำจริงร่วมกัน)

1. เปิด dash.cloudflare.com/sign-up → สมัครด้วยอีเมล (ฟรี)
2. Add a domain → กรอกโดเมนของคุณ → เลือกแผน Free
3. Cloudflare สแกน DNS records เดิมให้อัตโนมัติ
4. ระบบจะให้ nameservers คู่ใหม่ เช่น xxx.ns.cloudflare.com
5. ไปที่ผู้ให้บริการโดเมน (registrar) → เปลี่ยน NS ตามที่กำหนด
6. รอสถานะเปลี่ยนเป็น Active (นาทีถึงไม่กี่ชั่วโมง)

เตรียม: อีเมล + โดเมน 1 ชื่อที่แก้ NS ได้

DNS เบื้องต้น + สถานะ Proxy

ที่ DNS → Records จะเห็นทุก record มีสถานะเมฆ 2 แบบ

• Proxied (เมฆส้ม) — traffic วิ่งผ่าน Cloudflare = ได้ CDN + โล่ + ซ่อน IP
• DNS only (เมฆเทา) — แค่ชี้ชื่อ ไม่ผ่าน Cloudflare

ตรวจสอบว่าใช้งานแล้วจริง

dig +short ตัวอย่าง.com        # ได้ IP ของ Cloudflare (104.x / 172.x) = proxied แล้ว
curl -sI https://ตัวอย่าง.com  | grep -i 'server\|cf-ray'
# เห็น server: cloudflare และ cf-ray: ... = ผ่าน Cloudflare แล้ว

SSL/TLS — โหมดการเข้ารหัส 3 แบบ

ที่ SSL/TLS → Overview

• ใบรับรอง edge ออกให้ ฟรีอัตโนมัติ (อาจใช้เวลาถึง 24 ชม. หลังเปิดโดเมน)
• เปิด Always Use HTTPS + สร้าง redirect http → https
• เปิด HSTS บังคับให้เบราว์เซอร์จำว่าต้องใช้ HTTPS เสมอ
• ทดสอบความแน่นหนาที่ ssllabs.com/ssltest

WS1 — ต่อโดเมน + เปิดเมฆส้ม (30 นาที)

1. สมัคร + Add domain + แผน Free (ตามสไลด์ก่อนหน้า)
2. ที่ registrar: เปลี่ยน Nameservers เป็นคู่ที่ Cloudflare กำหนด
3. DNS → Records: เพิ่ม A ชื่อ ws → ค่าใด ๆ ก่อน → กดเมฆให้เป็น Proxied
4. รอสถานะ Active แล้วพิสูจน์:

dig +short ws.โดเมนคุณ          # ได้ IP 104.x/172.x ของ Cloudflare
curl -sI https://ws.โดเมนคุณ | grep -i 'server\|cf-ray'

ผ่านเมื่อ: เห็น server: cloudflare + cf-ray — traffic วิ่งผ่าน edge แล้ว
(สถานะ 5xx ตอนนี้ปกติ — origin ยังเป็นค่าทดสอบ เดี๋ยว WS3 แก้ด้วย tunnel)

WS2 — HTTPS Everywhere + ทดสอบ SSL (25 นาที)

1. SSL/TLS → Overview: ตั้ง Full (strict)
2. Edge Certificates: เปิด Always Use HTTPS
3. Rules → Redirect Rules: http → https (Status 301)
4. Edge Certificates → HSTS: Enable
5. ทดสอบ (ใช้ hostname ws. จาก WS1) + วัดเกรด:

curl -sI http://ws.โดเมนคุณ | head -3     # 301 → https
curl -sI https://ws.โดเมนคุณ | grep -i strict-transport

→ ssllabs.com/ssltest ใส่ ws.โดเมนคุณ มุ่งเกรด A
(https ยังไม่ตอบ = ใบรับรองใหม่รอ 15–30 นาที · HSTS เช็คซ้ำหลัง WS3)
Bonus: โฟลเดอร์ ws2-ssl/ มี nginx ใช้ใบ Origin CA (สำหรับ origin ที่มี public IP จริง)

ปัญหาที่ Tunnel มาแก้

จะเปิดเว็บ/บริการจากเครื่องที่อยู่ หลัง NAT (บ้าน, ออฟฟิศ, โรงงาน) ปกติต้อง…

• ขอ Public IP + เปิด port forward 80/443 → เสี่ยงโดนสแกน-โจมตี
• ทำ dynamic DNS + ต่ออายุ cert เอง
• ใช้ SSH tunnel / VPN — ต้องดูแล key และ session

Cloudflare Tunnel กลับทางคิด: ไม่ต้องเปิดพอร์ตไว้รับเลยสักพอร์ต

• connector ทำการเชื่อมต่อ ขาออก (outbound) ไปหา Cloudflare
• ผู้ใช้เข้า hostname ปกติ → Cloudflare ส่งผ่าน tunnel เข้ามาหาคุณ
• ฟรี ไม่จำกัด bandwidth ไม่ต้องมี public IP

สถาปัตยกรรม Tunnel

ผู้ใช้ ──HTTPS──▶ Cloudflare Edge ──tunnel (QUIC)──▶ cloudflared ──▶ localhost:8080
                                                        (เครื่องคุณ)

• cloudflared = daemon ตัวเดียวที่ต้องรันบนเครื่องคุณ
• สร้าง outbound connections หลายเส้นไป edge (โปรโตคอล QUIC เป็นค่าเริ่มต้น)
• บน edge ผูกกับ hostname ของโดเมนคุณ → เข้าเป็น HTTPS ปกติ
• ใบรับรองจัดการโดย Cloudflare ทั้งหมด — ต้นทางไม่ต้องมี cert

2 วิธีจัดการ Tunnel

วันนี้เน้นแบบ token (remotely-managed) — lab ทั้งหมดใช้วิธีนี้

ติดตั้ง cloudflared (บน Mac)

macOS — Homebrew (ใช้ตัวนี้ใน WS4)

brew install cloudflared

Docker (WS3 ใช้ image ทางการ — ไม่ต้องติดตั้งอะไรเพิ่ม)

docker run --rm cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TOKEN>

ตรวจว่าติดตั้งสำเร็จ: cloudflared --version

ทุกอย่างอยู่ในสคริปต์ ./setup.sh ของชุด workshop —
รันครั้งเดียวจบ + ./check-env.sh ยืนยันความพร้อม
(กลับไปทำบน Windows ได้: winget Cloudflare.cloudflared หรือ WSL2)

สร้าง Tunnel บน Dashboard

1. dash.cloudflare.com → เลือกโดเมน → Zero Trust (เปิดครั้งแรกให้ตั้งชื่อทีม)
2. Networks → Tunnels → Create a tunnel
3. เลือกชนิด Cloudflared → ตั้งชื่อ tunnel เช่น my-first-tunnel
4. Dashboard แสดง token พร้อมคำสั่งติดตั้งสำเร็จรูปทุกแพลตฟอร์ม
   (คัดลอกคำสั่งของ Docker / macOS / Linux มาใช้ได้เลย)
5. รันคำสั่งบนเครื่องคุณ → สถานะ connector เปลี่ยนเป็น HEALTHY

Public Hostname = Ingress Rule

ที่หน้า tunnel → Public Hostname → Add

บันทึกแล้วเปิด https://app.ตัวอย่าง.com — เว็บข้างในบ้านคุณโผล่ออกมาเป็น HTTPS โดยไม่เปิดพอร์ตเดียว

WS3 — Tunnel ด้วย Docker Compose (45 นาที)

ไฟล์ docker-compose.yml (ชุดจริงที่ racksync ใช้งาน + nginx ตัวอย่าง)

services:
  cloudflared:
    container_name: cloudflared-tunnel
    image: cloudflare/cloudflared:latest
    command: tunnel --no-autoupdate run
             --protocol quic --token ${CLOUDFLARED_TOKEN}
    volumes:
      - /etc/localtime:/etc/localtime:ro
    networks: [racksync]
    restart: always
networks:
  racksync:
    driver: bridge

WS3 (ต่อ) — ขั้นตอน (ไฟล์อยู่ใน ws3-tunnel-docker/)

1. สร้าง tunnel บน dashboard → คัดลอก token
2. cp .env.example .env แล้ววาง token:

CLOUDFLARED_TOKEN=eyJh...   # token จากข้อ 1

3. รันและดู log

docker compose up -d
docker compose logs -f
# รอจนเห็น Registered tunnel connection → กลับไปดู dashboard = HEALTHY

4. เพิ่ม Public Hostname: subdomain ws3 + Service HTTP → URL web (nginx ใน network เดียวกัน)
5. เปิดเว็บผ่าน https://ws3.โดเมนคุณ → เห็นหน้า "WS3 Test Page"

WS4 — Tunnel แบบ config.yml บน Mac (30 นาที)

สไตล์คุม ingress rules ด้วยไฟล์ (version control ได้) — คำสั่งเดียวกันทั้งเล่ม:

cloudflared tunnel login                        # เปิดเบราว์เซอร์เลือกโดเมน
cloudflared tunnel create ws4-demo              # ได้ UUID + credentials json
cloudflared tunnel route dns ws4-demo ws4.โดเมนคุณ
cloudflared tunnel run --config ws4-tunnel-local/config.yml

config.yml ในชุด workshop:

tunnel: <UUID>
credentials-file: ~/.cloudflared/<UUID>.json
ingress:
  - hostname: ws4.โดเมนคุณ
    service: http://localhost:8080
  - service: http_status:404   # catch-all บังคับเสมอ

โมเดลเก่า: Castle and Moat (กำแพง + คูน้ำ)

        ┌────────  VPN / Network ที่เชื่อใจ  ────────┐
ผู้ใช้ ──▶  ข้ามในได้ = ไว้ใจทั้งก้อน  ──▶ ทุกทรัพยากรภายใน

• เข้าใน network ได้ = เข้าถึงเกือบทุกอย่าง (over-privileged)
• พนักงานทำงานนอกออฟฟิศ / ข้อมูลอยู่บน SaaS → กำแพงหมดความหมาย
• VPN ช้า แพง และเป็นเป้าโจมตีชั้นดี

ปัญหาเดิม: ผู้ใช้และข้อมูลไม่ได้อยู่ในกำแพงแล้ว

Zero Trust: "Never Trust, Always Verify"

หลักการเดียว: ไม่เชื่อใจอะไรโดยอัตโนมัติ — ตรวจทุก request ทุกครั้ง

ทุกการร้องขอเข้า network ต้องผ่าน:

• Authentication — ใคร (identity: อีเมล, SSO, device)
• Context — จากไหน, เครื่องไหน, กี่โมง, สถานะความปลอดภัย
• ให้สิทธิ์แบบ Least Privilege — เห็นเท่าที่จำเป็นเท่านั้น

ได้ 3 อย่าง: Protection · Visibility · Control
ครอบคลุม Devices, Data, Networks, Teams, People, Workload

Cloudflare Zero Trust = 3 ชิ้นสำคัญ

เดิมชื่อ Cloudflare for Teams — ผู้ใช้ทุกที่ อุปกรณ์ทุกชนิด เข้าถึงทุกแอปอย่างปลอดภัย

แผนฟรี: ผู้ใช้ 50 คนแรก $0 (เกินใหม่ ~$7/user/เดือน)
แอป SaaS สาธารณะ + แอปภายในทั้งหมด อยู่ในโมเดลเดียวกัน

Cloudflare Access — ใส่ประตูให้แอปใน 5 นาที

ที่ Zero Trust → Access → Applications → Add an application → Self-hosted

1. Application domain: ใส่ hostname เดียวกับ tunnel เมื่อกี้
   (app.ตัวอย่าง.com)
2. Login method เริ่มต้น: One-time PIN (OTP) ทางอีเมล — ไม่ต้องตั้ง IdP ก็ใช้ได้
   (ต่อได้กับ Google Workspace, Azure AD/Entra, GitHub, Okta ฯลฯ)
3. สร้าง Policy:
   • Action = Allow
   • Include = Emails → ใส่อีเมลตัวเอง

บันทึก → เปิดเว็บอีกครั้ง → เจอหน้า cloudflareaccess.com ขอ OTP

Access Policy คิดอย่างไร

Action: Allow / Block / Service Auth
Rules:  Include (อนุญาตถ้าตรง) / Require (ต้องผ่านเพิ่ม) / Exclude (ยกเว้น)
ตัวเช็ค: Emails, Email domain, Groups, Country, Device posture, IP, mTLS ...

ตัวอย่างจริง:

• อนุญาตเฉพาะ @บริษัท.com + Require MFA
• อนุญาต vendors เข้าระบบ ERP เฉพาะ วัน-เวลาทำการ
• บล็อกการเข้าจากประเทศที่ไม่มีธุรกิจ

หลักคิด: ใคร (identity) + อะไร (context) → ประตูเดียวต่อหนึ่งแอป ไม่ใช่ประตูกลางของ network ทั้งหมด

WS5 — Access: ล็อกเว็บ tunnel ของคุณ (30 นาที)

1. ใช้ tunnel + public hostname จาก WS3
2. Access → Applications → Add → Self-hosted
   • Domain: app.โดเมนคุณ
3. Add policy: Allow + Include Emails = อีเมลของคุณ
4. เปิด incognito → https://app.โดเมนคุณ
   • ได้หน้าล็อกอิน OTP ของ Cloudflare Access
   • กรอกอีเมล → รับ PIN 6 หลัก → เข้าเว็บได้
5. พิสูจน์ว่า session ถูกต้อง: เปิดแท็บ incognito ใหม่ → ต้องยืนยันอีกครั้ง

สังเกต: แอปของคุณไม่เคยรู้จักระบบล็อกอินเลย — Access ทำงานที่ edge

Cloudflare Gateway — กรอง DNS ทั้งองค์กร

Gateway → Locations → Create ได้ endpoint เช่น ID พิเศษ .cloudflare-gateway.com

• ใส่ endpoint นี้ที่ router / DNS server / WARP client
• ทุก query วิ่งเข้า Cloudflare (ผ่าน DoH เข้ารหัส — ISP แอบดูไม่ได้)
• สร้าง DNS Policies: ชนิด Security / Content / Custom
  • บล็อก malware/phishing ทั้งหมด (Security)
  • บล็อก gambling/social ช่วงเวลาทำการ (Content)
• Dashboard แสดง Top Allowed / Top Blocked แบบเรียลไทม์

ชื่อตัวอย่างจากสไลด์จริง: network แรกชื่อ "Kaizen" policy แรกชื่อ "Nine to Five"

WS6 — Gateway Filter + เกม Troubleshooting (30 นาที)

A. กรอง DNS ทั้งเครื่อง Mac

1. Gateway → Locations → Create (my-mac) → ได้ IPv4 endpoint
2. Policies → DNS: Block โดเมนทดสอบ example-blocked.com
3. System Settings → Network → Wi-Fi → Details → DNS ใส่ IPv4 ของ Gateway
4. เคลียร์ cache แล้วทดสอบ:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
dig example-blocked.com +short   # 0.0.0.0 = โดนบล็อก 

B. เกม Troubleshooting — ผู้สอนหยอยอาการ (502 / 530 / DNS ตาย / ไม่ถามล็อกอิน)
ผู้เรียนแข่งวินิจฉัยชั้นไหน DNS → Edge → Tunnel → Service + พิสูจน์ด้วยคำสั่ง

เครื่องมือตรวจพื้นฐาน (Command Line)

# 1. DNS ตอบถูกไหม / proxied หรือยัง
dig +short app.ตัวอย่าง.com     # ต้องได้ IP ของ Cloudflare

# 2. ผ่าน Cloudflare จริงไหม
curl -sI https://app.ตัวอย่าง.com | grep -iE 'server|cf-ray|http/'

# 3. แยกว่าปัญหาอยู่ที่ edge หรือต้นทาง
curl -I http://localhost:8080   # ทดสอบ service ในเครื่องตรง ๆ

ลำดับคิด (แบบหมอ): DNS → Edge → Tunnel → Service ไล่จากนอกเข้าใน

รหัสข้อผิดพลาดที่ควรจำ

Tunnel Troubleshooting Checklist

• สถานะบน dashboard: Networks → Tunnels ต้องเป็น HEALTHY
• docker compose logs -f มองหา
  • Registered tunnel connection = ปกติ
  • failed to connect to origin = ingress ผิด
  • token ผิด/หมดอายุ = ให้เชื่อมต่อไม่ได้เลย
• QUIC โดน network บล็อก (บางออฟฟิศ/ISP) → รองรับ fallback:

--protocol http2

• อัปเดต: --no-autoupdate ใน lab เพื่อคุมเวอร์ชัน (สภาพจริงปล่อย auto ได้)

ใช้ Dashboard วินิจฉัย

เคล็ดลับ: เปิด Logs ทิ้งไว้ตอนทำ lab — เห็น event ย้อนหลัง 24 ชม. (แผนฟรี)

กรณีศึกษา: Home Assistant 10,000+ บ้าน

hass-addons-cloudflared-tunnel — add-on โดย racksync

• ผู้ใช้ Home Assistant ทั่วโลกติดตั้ง 10,000+
• ปัญหาเดิมของผู้ใช้: อยากเข้าบ้านอัจฉริยะจากนอกบ้าน → เปิด port 8123 → โดนสแกนทุกวัน
• ทางแก้: cloudflared ใน container เดียว + token → บ้านทุกหลังเข้า ha.โดเมน ผ่าน HTTPS โดยไม่เปิดพอร์ต
• ต่อยอดจริง: ใส่ Access หน้า HA → ป้องกัน credential stuffing โดยไม่แก้โค้ด HA เลย

บทเรียน: Tunnel 1 ตัว + policy ไม่กี่บรรทัด = ผลิตภัณฑ์ที่คนใช้จริง

องค์กร 3 ขนาด ใช้ Zero Trust ต่างกันอย่างไร

รูปแบบเดียวกับที่เราทำใน lab — ต่างกันแค่ scale

Best Practices — สรุปที่ควรทำเสมอ

DNS/SSL

• SSL mode = Full (strict) เมื่อทำได้ + Always Use HTTPS + HSTS
• Origin ใช้ Origin CA certificate (อายุ 15 ปี ใช้เฉพาะกับ Cloudflare)

Tunnel

• Token เก็บใน .env — อย่า commit ลง git / หมุนเมื่อรั่วไหล
• ใช้ tunnel แล้ว ปิด port 80/443 ที่ firewall ให้สนิท — อย่าให้มีทางเข้าหลังบ้าน

Zero Trust

• ทุก admin panel / dashboard ใส่ Access ไว้ก่อนเสมอ
• Policy เขียนแบบ least privilege (Allow เฉพาะที่จำเป็น ไม่ใช่ Block ที่ไม่จำเป็น)
• เปิด log ดู Access + Gateway เป็นประจำ

สรุปวันนี้

1. Cloudflare CDN — edge 335+ เมือง เร่งเว็บ + โล่ DDoS แบบ unmetered
2. DNS/SSL — เมฆส้ม = proxied, ใช้ Full (strict) + HTTPS เสมอ
3. Tunnel — outbound ผ่าน QUIC ไม่เปิดพอร์ต คุมด้วย token ที่ dashboard
4. Zero Trust — Never trust always verify: Access (ประตูแอป) + Gateway (กรอง) + WARP
5. Troubleshooting — ไล่ DNS → Edge → Tunnel → Service + จำรหัส 530/502/525
6. Best Practices — least privilege, ปิด port, เก็บ token ปลอดภัย

แหล่งศึกษาต่อ

• เอกสารประกอบ: chapters.md (คู่มือผู้สอน/ทบทวน) + quiz.md (แบบทดสอบ)
• เอกสารทางการ
  • developers.cloudflare.com/tunnel — Cloudflare Tunnel
  • developers.cloudflare.com/cloudflare-one — Zero Trust/Access/Gateway
  • blog.cloudflare.com — สถิติเครือข่าย (500 Tbps, เม.ย. 2026)
• community.cloudflare.com — ถามตอบจากผู้ใช้ทั่วโลก