← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-wan / reference

Tunely GRE a IPsec

Cloudflare WAN směruje provoz mezi globální sítí Cloudflare a sítí vašeho originu tak, že vaše původní pakety zabalí do vnějšího paketu: tomuto procesu se říká zapouzdření. Vnější paket pak přenáší váš provoz přes internet do cíle, kde se rozbalí (dekapsuluje) a doručí.

Cloudflare WAN používá dva zapouzdřovací protokoly: Generic Routing Encapsulation (GRE) a IPsec. GRE je bezstavový a jednodušší na konfiguraci, ale provoz nešifruje. IPsec provoz šifruje a ověřuje zdroj, takže poskytuje silnější zabezpečení. Oba protokoly vytvářejí tunely, tedy logická spojení typu bod-bod mezi Cloudflare a vaší sítí. Cloudflare vytváří koncové body tunelu na serverech globální sítě ve vašem síťovém namespace, zatímco vy vytváříte koncové body tunelu na routerech ve svém datovém centru.

Aby bylo možné zohlednit dodatečná data hlavičky vzniklá zapouzdřením, musíte upravit maximální velikost segmentu (MSS) tak, aby odpovídala standardní směrovatelné maximální přenosové jednotce (MTU) internetu, která činí 1500 bajtů.

Pokyny viz Nastavit maximální velikost segmentu.

Tento diagram znázorňuje tok provozu v síti Cloudflare WAN.

sequenceDiagram
accTitle: Tunnels and encapsulation
accDescr: This diagram shows the flow of traffic with Cloudflare WAN.
participant A as Client machine
participant B as Cloudflare Cloudflare WAN
participant C as Origin router
A->>B: Payload <br> Protocol <br> IP header
Note left of A: Ingress <br> traffic
B->>C: Payload <br> Protocol <br> IP header <br> GRE <br> IP header
C->>A: IP header <br> Protocol <br> Payload
Note right of C: Egress <br> traffic

Tradiční tunely propojují dva pevné koncové body, jedno zařízení na každé straně. Cloudflare WAN používá jiný model: anycast IP adresy pro endpointy tunelů Cloudflare. V modelu anycast může provoz přijmout kterýkoli server v libovolném datovém centru Cloudflare, přičemž musí být schopen zapouzdřit a rozbalit pakety pro libovolný tunel. To znamená, že váš tunel není vázán na jediný server Cloudflare: provoz zpracovává to datové centrum, které je zdroji nejblíže.

To funguje s Tunely GRE, protože protokol GRE je bezstavový. Cloudflare zpracovává každý paket nezávisle, aniž by bylo nutné jakékoli vyjednávání nebo koordinace mezi koncovými body tunelu. Koncové body tunelu jsou vázány na IP adresy, nikoli na konkrétní zařízení. Libovolné zařízení, které dokáže odstranit vnější hlavičky a následně směrovat vnitřní paket, dokáže zpracovat jakýkoli paket GRE odeslaný tunelem.

Pro U tunelů IPsec router zákazníka vyjednává vytvoření tunelu IPsec se Cloudflare pomocí Protokol Internet Key Exchange (IKE). Protokol IPsec je stavový (vyžaduje sdílené klíče a parametry relace), proto počáteční vyjednávání zajišťuje jeden server Cloudflare, který následně předá podrobnosti tunelu (výběry provozu, klíče atd.) všem datovým centrům Cloudflare. Výsledkem je, že provoz daného tunelu IPsec může zpracovávat kterýkoli server Cloudflare, přestože vyjednávání provedl pouze jeden z nich.

Anycast architektura Cloudflare poskytuje cestu k vašemu tunelu z každého serveru v každém datacentru globální sítě Cloudflare. Následující obrázek tuto architekturu znázorňuje.

flowchart LR
accTitle: Anycast tunnel
accDescr: Multiple servers in data center preparing packets to send through anycast tunnel.

a(User)

subgraph 1
direction LR
b(Cloudflare global <br> network server)
c(Cloudflare global <br> network server)
d(Cloudflare global <br> network server)
e(Cloudflare global <br> network server)
f(Cloudflare global <br> network server)
g(Cloudflare global <br> network server)
h(Cloudflare global <br> network server)
end

subgraph 2
i("Acme router <br> 198.51.100.1")
j("FTP server <br> (203.0.113.100)")
end

subgraph 3
x("Acme router <br> 198.51.100.1")
z("FTP server <br> (203.0.113.100)")
end

a --> 1== Cloudflare anycast GRE <br> single endpoint ==>i --> j

1== Cloudflare anycast IPsec <br> single endpoint ==>x --> z

IPsec ↗ je skupina protokolů, které společně vytvářejí šifrovaná spojení mezi zařízeními. Pomáhá chránit data, která odesíláte přes veřejné sítě. Organizace IPsec často používají k vytváření virtuálních privátních sítí (VPN) a funguje tak, že šifruje IP pakety a ověřuje zdroj, ze kterého pakety pocházejí.

Informace o nastavení tunelu IPsec najdete v Konfigurace koncových bodů tunelu. Další informace o konfiguračních parametrech, které Cloudflare WAN používá k vytvoření tunelu IPsec, najdete dále v textu.

Cloudflare WAN naváže tunel IPsec v následujících fázích:

• Initial Exchange (IKE_SA_INIT): partneři IKE si vyjednají parametry pro IKE Security Association (SA) a vytvoří sdílené tajemství pro odvození klíčů, a pokud je to relevantní, signalizují podporu postkvantové výměny klíčů pomocí RFC 9370 ↗. Když ochrana proti downgradu je povoleno, Cloudflare také odešle IKE_SA_INIT_FULL_TRANSCRIPT_AUTH oznámení během této výměny, aby signalizovaly podporu úplné autentizace transcriptu. Po této výměně mají peerové zabezpečený komunikační kanál, ale ještě se vzájemně neautentizovali.
• Intermediate Exchange (IKE_INTERMEDIATE): pokud oba partneři podporují RFC 9370, provedou další výměnu klíčů pomocí ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism), postkvantové výměny klíčů specifikované v draft-ietf-ipsecme-ikev2-mlkem ↗. Tím se vytvoří hybridní sdílený klíč kombinací klíče odvozeného z klasického Diffie-Hellmana (navázaného během IKE_SA_INIT) s postkvantovým ML-KEM na ochranu proti harvest-now, decrypt-later ↗ útoky.
• Auth Exchange (IKE_AUTH): pomocí klíčů vytvořených z obou IKE_SA_INIT a IKE_INTERMEDIATE výměny se protějšky IKE vzájemně ověří. Po ověření naváží bezpečnostní asociaci IKE (SA). Poté protějšky vyjednají a naváží tunel IPsec, označovaný jako Child SA.
• Rekeying: Periodicky, nebo prostřednictvím manuálního zásahu, lze u SA IKE provést výměnu klíčů (rekey) a vygenerovat tak nové SA s novými klíči pro danou relaci. Tato výměna klíčů (rekey) se provádí jak pro SA IKE (obnovení řídicí roviny), tak pro Child SA (obnovení datové roviny). Pokud se používá hybridní výměna (RFC 9370), proces výměny klíčů (rekey) pro SA IKE opět provede paralelní klasickou (DH) a postkvantovou (ML-KEM) výměnu, aby byla i nadále zajištěna odolnost vůči kvantovým počítačům.

Stručně řečeno, IKEv2 vytvoří IKE SA, která používá určité kryptografické transformace. Tuto IKE SA pak použije k vytvoření Child SA, jež používá vlastní kryptografické transformace. Následující konfigurační část popisuje, které z těchto transformací Cloudflare WAN v současnosti podporuje pro IKE SA a Child SA.

Zvolte si z následujících konfiguračních parametrů, které Cloudflare WAN podporuje, podle toho, co podporuje váš appliance.

Následující dodavatelé třetích stran byli otestováni a ověřeni z hlediska interoperability s Cloudflare IPsec pro postkvantovou dohodu o klíči:

Cloudflare průběžně testuje a ověřuje další zařízení třetích stran. Pokud se vám podařilo úspěšně nakonfigurovat post-kvantový IPsec s dodavatelem, který zde není uveden, kontaktujte tým spravující váš účet.

Cloudflare WAN podporuje pro IPsec následující typy IKE ID:

Cloudflare navíc podporuje typ IKE ID ID_IPV4_ADDR pokud jsou splněny obě následující podmínky:

1. Nastavíte u tunelu IPsec customer_endpoint hodnota.
2. Kombinace cloudflare_endpoint a customer_endpoint je jedinečné mezi tunely IPsec zákazníka.

Ačkoli Cloudflare podporuje jak VPN založené na trasách, tak VPN založené na zásadách, doporučujeme VPN založené na trasách.

Pokud VPN založené na trasách nepřipadají v úvahu a musíte použít VPN založené na zásadách, mějte na paměti následující omezení:

• Cloudflare podporuje pouze jednu sadu traffic selectors na jednu Child SA.
• Zásada musí pokrývat kontroly stavu typu reply, tedy musí odpovídat výběrům provozu (traffic selectors), jinak je Cloudflare zahodí stejně jako jakýkoli jiný provoz z tunelu IPsec, který neodpovídá žádné zásadě.
• Jeden tunel IPsec může obsahovat přibližně 100 Child SA. Počet různých zásad na jeden tunel je tak v praxi omezený.

Původní návrh ověřování protokolu IKEv2 zajišťuje, že každý endpoint podepisuje pouze vlastní odchozí zprávy, nikoli celý přepis handshake. Kvantově schopný on-path útočník ↗ toho může využít k vytvoření „rozděleného pohledu“ na handshake a přimět koncové body ke snížení úrovně postkvantového připojení zpět na klasickou kryptografii, přestože obě strany podporují postkvantovou výměnu klíčů.

Chcete-li tento problém vyřešit, Cloudflare podporuje IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗ rozšíření IKEv2. Když je zapnuté, obě strany IKEv2 při autentizační výměně podepisují celý přepis handshake, nikoli jen své vlastní zprávy. Útočník tak nemůže nepozorovaně snížit úroveň zabezpečení připojení.

Jak to funguje:

• Když je feature flag zapnutý, Cloudflare (vystupující jako IKE responder) bezpodmínečně zahrne IKE_SA_INIT_FULL_TRANSCRIPT_AUTH oznámení ve svém IKE_SA_INIT odpověď.
• Pokud iniciátor rozšíření také podporuje, obě strany použijí ověření pomocí úplného přepisu (transcript), což zlepšuje ochranu proti downgrade útokům.
• Pokud iniciátor rozšíření nepodporuje, handshake pokračuje standardním ověřením IKEv2. Aby byla ochrana proti downgrade útokům účinná, musí rozšíření podporovat obě strany.

Požadavky:

• Váš iniciátor IKEv2 musí podporovat IKE_SA_INIT_FULL_TRANSCRIPT_AUTH oznámení definované v draft-ietf-ipsecme-ikev2-downgrade-prevention ↗.

Nápověda k řešení problémů s tunelem:

• Odstraňování problémů se stavem tunelu: Diagnostikujte a opravte selhání kontrol stavu
• Odstraňování problémů pomocí protokolů IPsec: Použijte Logpush k analýze problémů s navazováním spojení (handshake) IPsec

Nápověda k řešení problémů s tunelem:

• Odstraňování problémů se stavem tunelu: Diagnostikujte a opravte selhání kontrol stavu
• Odstraňování problémů pomocí protokolů IPsec: Použijte Logpush k analýze problémů s navazováním spojení (handshake) IPsec