Post

CZE | Cloudflare: průvodce konfigurací. Tunely a dynamická DNS

CZE | Cloudflare: průvodce konfigurací. Tunely a dynamická DNS

This article is in Czech. Don’t worry, there’s English version too!

Uvažujete o využití služeb Cloudflare, ale nejste si jisti, co vám mohou přinést? Tento článek vám pomůže se v nabídce Cloudflare zorientovat. Zaměříme se především na dvě klíčové služby - tunelování a DNS. Probereme jejich výhody i potenciální úskalí, abyste se mohli informovaně rozhodnout, zda jsou pro vás tyto služby vhodné.

Cloudflare nabízí řešení, která mohou výrazně zjednodušit a zabezpečit provoz vašich webových služeb. Ať už provozujete osobní blog, firemní web nebo komplexní online aplikaci, Cloudflare má co nabídnout. Pojďme se podívat, jak by vám mohlo pomoci.

Motivace

I když je možné provozovat webové služby bez Cloudflare, jeho využití může přinést větší pohodlí a bezpečnost. Jednou z nejzajímavějších funkcí jsou reverzní tunely pro HTTPS provoz. Toto řešení navazuje spojení přímo z vašeho serveru na Cloudflare, čímž se odstraní řada mezičlánků mezi vaším webovým serverem a internetem. Na cílovém serveru pak zůstávají jen dvě hlavní komponenty - služba cloudflared a váš webový server. Cloudflare navíc nabízí praktickou možnost přístupu k SSH přes webové rozhraní.

Nyní, když jsme si vysvětlili, proč by vás Cloudflare mohlo zajímat, pojďme se podívat na konkrétní výhody. Využitím služeb Cloudflare můžete eliminovat řadu běžných problémů spojených s provozem webových služeb:

Odpadá

  • Potřeba veřejné IP adresy
  • No-ip a dynamická DNS (ale zase potřebujeme vlastní top level doménu, což je pro .cz asi 150CZK/rok). Dynamická DNS se dá zařídit také, ale pro HTTP(S) není nutná, protože provoz jde přes reverzní tunel
  • Správa vlastních subdomén se přesouvá od registrátora na cloudflare
  • Konfigurace přesměrování portů na routeru (přesměrování portu na IP, přidělení IP skrz DHCP konkrétnímu stroji na základě MAC)
  • Nginx Proxy manager (NPM), který má prakticky stejnou konfiguraci, jako cloudflare tunely
  • Tvorba a obnova HTTPS certifikátů (Let’s encrypt) u NPM
  • Případné povolení některých portů ve firewallu na cílovém serveru

Další benefity

  • Jednodušší a centralizovaná konfigurace
  • IP adresa serveru (domácího routeru) zůstává skrytá, provoz browseru jde na servery cloudflare
  • Cachování obsahu
  • Přístup k SSH přes web pro nouzové situace

Nevýhody

Přestože výhody Cloudflare jsou značné, je důležité zvážit i potenciální nevýhody. Každé řešení má své limity a Cloudflare není výjimkou:

  • Vlastní doména a s tím spojený roční poplatek (150CZK pro doménu .cz)
  • Cloudflare nenabízí zdarma nějaké podprobnější statistiky přístupů, nejsou rozdělené ani na cílové domény
  • Prostředník, kterému dávate potenciálně přístup do vnitřní sítě a musíte mu věřit a závislost na něm - sázíte vše na jednu kartu
  • Nutná platba částky 0 USD kreditkou (to není vtip)
  • Omezená velikost uploadovaného souboru na 100MB (?)
  • Měnící se podmínky použití, třeba nejspíš vypadlo Limitation on Serving Non-HTML Content
  • Nejspíš to nenahradí VPN (ale vše není prozkoumáno)
  • Pro NextCloud se může hodit i lokální přístup (jinak jde ven přes HTTPS na server cloudflare a pak skrz tunel dovnitř)
  • Nejasné platební podmínky (a pár afér s tím spojených)

Konfigurace před Cloudflare:

Abychom lépe pochopili, jak Cloudflare zjednodušuje správu webových služeb, pojďme se nejprve podívat na typickou konfiguraci bez použití Cloudflare

  • DNS:
    • registrace domény (volitelná, může být přes no-ip.com doména druhého řádu)
    • pokud se mění IP adresa, tak navíc dynamická DNS (třeba no-ip.com, ale umí jen tři domény a ne doménu prvního řádu, vyžaduje každý měsíc obnovu)
  • Router:
    • přesměrování vnějšího portu (https/443) na nějaké PC. To znamená u DHCP nastavení pevné adresy pro PC na základě MAC adresy a nastavení pravidla pro přesměrování.
  • Server:
    • u dockeru/podmana chceme, aby se port 443 hosta přesměroval na port 443 kontejneru s nginx proxy managerem
    • v nginx proxy manageru musíme pro každou subdoménu vygenerovat a přiřadit HTTPs certifikát
    • v nginx proxy manageru musíme nakonfigurovat na základě domény, že má dojít k přesměrování do příslušného kontejneru
    • u některých služeb (nextcloud) musíme nastavit přepis protokolu z http na https?

Konfigurace s Clouflare

Nyní, když jsme si ukázali, jak vypadá tradiční nastavení, podívejme se, jak se situace změní při použití Cloudflare

  • DNS
    • Registraci domény se nevyhneme, od registrátora musíme správu přesunout ke cloudflare (změna nameserveru).
    • Přes Cloudflare spravujeme A,AAAA,CNAME záznamy. U tunelů se vytváří automaticky.
    • Dynamická DNS nás nemusí zajímat (ale může se hodit pro SSH přístup) a přes Cloudflare se dá řešit také
  • Tunel(y)
    • Tunely se konfigurují prakticky stejně jak Nginx Proxy Manager a DNS updatují automaticky
  • Router
    • Pro HTTPS nevyžaduje nic (ale může se hodit přesměrovat SSH)
  • Server
    • místo nginx proxy manageru máme cloudflared s konfigurací přes web a certifikát máme automaticky
    • skriptík pro zjištění IP adresy v případě, že nemáme dynamickou DNS a chceme se připojit přes SSH
1
2
3
4
<?php
$ip = shell_exec("curl -s ifconfig.me/ip");
echo "Public IP is: " . $ip;
?>

Jak rozchodit Cloudflare tunely

Prvním kroky jsou

  • registrace vlastní domény
    • pokud registrujeme českou doménu, je na potvoru ve whois databázi vidět adresa osoby, na kterou je doména registrovaná. Tohle lze vyřešit u cz.nic/mojeid po desítkách minut ověřování identity mezi emailem, mobilem (SMS), bankovní identitou, datovou schránkou, mobilní aplikací mojeid, nebem, peklem a kdo ví čím ještě až se dosáhne potřebné důvěryhodnosti. Good luck & have fun.
  • registrace u cloudflare
  • přesun správy vlastní domény na cloudflare (v mém případě z forpsi). Cloudflare dá k dispozici jmené servery (jarred.ns.cloudflare.com, sload.ns.cloudflare.com), u forpsi je pak nutné změnit jmenné servery, dát nové NSSID, vypsat příslušné servery. PAVEL-PERINA zřejmně korespoduje s loginem u mojeid. Změna může prý trvat asi den.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
whois pavelp.cz
%  (c) 2006-2021 CZ.NIC, z.s.p.o.

domain:       pavelp.cz
registrant:   PAVEL-PERINA
nsset:        CF-JARRED-SLOAN
registrar:    REG-INTERNET-CZ
registered:   02.04.2023 23:41:04
changed:      03.04.2023 00:24:46
expire:       02.04.2024

contact:      PAVEL-PERINA
name:         Pavel Peřina
registrar:    REG-MOJEID
created:      21.12.2022 11:41:23
changed:      03.04.2023 11:34:29

nsset:        CF-JARRED-SLOAN
nserver:      jarred.ns.cloudflare.com
nserver:      sloan.ns.cloudflare.com
tech-c:       PAVEL-PERINA
registrar:    REG-INTERNET-CZ
created:      03.04.2023 00:24:44

Tuším, že v průběhu následujících kroků je třeba zaplatit nulovou částku kreditní kartou, možná kvůli vynucení ztráty anonymity. V hlavním menu Cloudflare (ne u konkrétní domény) vlezem do sekce Zero trust –> Access –> Tunnels a přidáme nový tunel. Zde pojmenovaný třeba Fedora. V druhém kroku “Configure Fedora” nám to napíše nějaký příkaz s docela dlouhým tokenem. Např:

1
docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJh...

Token zkopírujeme do souboru ~/docker/.env jako řádek

1
CF_TOKEN=eyJh....

A do ~/docker/docker-compose.yml, který začíná

1
2
version: "3.5"
services:

přidáme

1
2
3
4
5
6
7
8
  # Cloudflared
  cloudflared:
    container_name: cloudflared
    image: docker.io/cloudflare/cloudflared:latest
    restart: unless-stopped
    environment:
      - TUNNEL_TOKEN=${CF_TOKEN}
    command: tunnel --no-autoupdate run

A restartujeme docker/podman-compose.

Dále je konfigurace velmi podobná konfiguraci DNS a Nginx Proxy Manageru. Pokud máme náhodou danné subdomény v DNS musíme je smazat, tunel je vytvoří znovu.

Přidáme (příklad)

SubdomainDomainPathTypeURL
ncpavelp.cz HTTPnextcloud-app
wwwpavelp.cz HTTPnginx
sshpavelp.cz SSHmarten.local :22

Tím máme https://nc.pavelp.cz/ přesměrováno do kontejneru s názvem nextcloud-app na HTTP port, https://www.pavelp.cz/ do kontejneru s názvem nginx. SSH je složitější, na to je v sekci Zero Trust –> Access –> Applications vytvořit SSH aplikaci a to zpřístupní SSH přes web (https://ssh.pavelp.cz/). Výstup je nasměrovaný na PC v lokální síti, zde je možné použít statickou IP adresu, třeba 192.168.0.164 a nebo AVAHI a hostname v doméně .local, což funguje i při změně síťového rozhraní (ethernet <-> wifi).

Pro web tohle stačí. U Nextcloudu je hádám nutné změnit ještě něco v jeho PHP konfigu (rewrite HTTP na HTTPS a akceptované domény nebo tak něco). O tom pojednává budoucí článek Konfigurace Nextcloudu

Dodatek: Dynamická DNS

Všechny služby nicméně neběží jen přes Cloudflare (třeba SSH), takže je zde ještě pro pohodlnost dynamický update DNS. Na to slouží další kontejner.

Na stránce pro správu domény získáme API token (overview, vpravo Get New API Token) a následně mu dáme název třeba cloudflare-ddns a práva pro všechny zóny (nebo vybranou doménu). Token přidáme do souboru .env jako CF_API_TOKEN.

   
ZoneZone SettingsRead
ZoneZoneRead
ZoneDNSEdit
1
2
3
4
5
6
7
8
9
10
11
12
  # https://github.com/oznu/docker-cloudflare-ddns
  cloudflare-ddns:
    container_name: cloudflare-ddns
    image: docker.io/favonia/cloudflare-ddns:latest
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=100
      - CF_API_TOKEN=${CF_API_TOKEN}
      - DOMAINS=pavelp.cz
      - PROXIED=false
      - IP6_PROVIDER=none

Tím se nám automaticky updatuje DNS záznam pro pavelp.cz, když se změní veřejná IP adresa routeru.

Bonus: update kontejnerů

1
2
3
4
5
6
7
8
9
10
11
12
$ cat ~/bin/podman-images-update.sh

#!/usr/bin/dash

# This script updates podman images and removes old ones
# PavelP, 2023-06-02

cd ~/docker
systemctl --user stop podman-compose.service
podman-compose pull
podman image prune --force
systemctl --user start podman-compose.service

Závěr

Doufám, že tento post vám pomohl lépe porozumět možnostem a výhodám použití služeb Cloudflare pro dynamické DNS a tunely. Ačkoliv to může vyžadovat trochu práce na konfiguraci a přizpůsobení vašemu prostředí, výhody v podobě snížení složitosti, zvýšení bezpečnosti a zjednodušení správy mohou stát za to.

Přestože jsou zde také nějaké nevýhody, jako je potenciální nedůvěra v poskytovatele třetí strany nebo možnost měnících se podmínek použití, tyto faktory je třeba zvážit a rozhodnout se, zda pro vás výhody převažují nad těmito riziky.

Děkuji za přečtení.

Zdroje

This post is licensed under CC BY 4.0 by the author.