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

Tunnel health checks

Cloudflare průběžně sleduje, zda je každý tunel propojující vaši síť s Cloudflare dostupný a funguje správně. Jakmile se stav tunelu zhorší, Cloudflare automaticky přesměruje provoz na alternativní cestu, aniž by byl nutný jakýkoli zásah z vaší strany. Toto sledování probíhá pomocí sond kontroly stavu tunelu.

Sonda kontroly stavu tunelu se skládá z ICMP (Internet Control Message Protocol) ↗ datový obsah zapouzdřený v protokolu testovaného tunelu. Pokud je testovaným tunelem například tunel IPsec (Internet Protocol Security), ICMP paket ↗ je zašifrován uvnitř paketu Encapsulating Security Payload (ESP) tunelu.

Sonda kontroly stavu tunelu putuje od Cloudflare k originu tunelu a poté se odpověď vrací zpět do Cloudflare. Cloudflare podle této odpovědi určuje výsledek sondy a vypočítává stav tunelu (podrobněji to popisují následující části).

Cloudflare WAN používá dva typy kontrol stavu:

Kontroly stavu tunelu sledují stav tunelů, které směrují provoz z Cloudflare do vaší origin sítě. Cloudflare WAN se na základě těchto kontrol rozhoduje, jak provoz nasměrovat na nejlepší dostupné trasy. Během onboardingu zadejte endpointy tunelu nebo cíle kontroly stavu tunelu, na které budou mířit sondy tunelu vycházející z globální sítě Cloudflare.

K výsledkům kontrol stavu tunelu (health check) máte přístup prostřednictvím rozhraní API. Cloudflare agreguje tyto výsledky z jednotlivých výsledků kontrol stavu ze serverů Cloudflare.

Kontroly stavu endpointů ověřují konektivitu mezi distribuovanými datacentry Cloudflare a sítí vašeho originu. Na rozdíl od kontrol stavu tunelu mají sondy endpointů poskytovat celkový přehled o stavu internetového připojení mezi Cloudflare a vaší sítí. Procházejí dostupnými tunely, ale neovlivňují výběr tunelu ani logiku řízení provozu.

Servery globální sítě Cloudflare provádějí kontroly stavu endpointů mimo síťové namespace zákazníka a obvykle cílí na endpointy za hraničním routerem, na kterém tunel končí. Během onboardingu zadáte IP adresy, podle kterých se kontroly stavu endpointů nakonfigurují.

Sonda kontroly stavu tunelu má následující atributy.

Sonda kontroly stavu tunelu ověřuje, zda se Cloudflare dokáže přes tunel úspěšně připojit ke konkrétní adrese nebo endpointu. Cílem je adresa, u které chcete ověřit dostupnost. Je volitelný a výchozí hodnoty se liší podle směru kontroly stavu (viz Směr pro další informace).

Sonda kontroly stavu tunelu může mít dva možné směry: jednosměrný a obousměrný.

Jednosměrná sonda kontroly stavu zůstává zapouzdřená jedním směrem a k originu se dostává tunelem (od Cloudflare k originu). Odpověď se do Cloudflare vrací nezapouzdřená a je směrována mimo tunel podle standardního internetového směrování ↗.

Cíl se ve výchozím nastavení nastaví na veřejně směrovatelný origin určený jako customer_endpoint na tunelu, pokud existuje. V opačném případě můžete použít vlastní cíl.

Obousměrná sonda zůstává zapouzdřená v obou směrech. Sonda přichází přes tunel a odpověď také odchází zapouzdřená přes tunel. Odpověď ICMP z vašeho routeru určená pro anycast IP adresu v síti Cloudflare dorazí do nejbližšího datacentra Cloudflare a skončí na jednom ze serverů pomocí technologie Equal-Cost Multi-Path (ECMP), což zajišťuje, že odpověď projde nejefektivnější cestou.

Výchozí adresování paketů

Cloudflare ve výchozím nastavení směruje tyto pakety na stranu Cloudflare adresy rozhraní nastavené na tunelu a jako zdroj používá klientskou stranu tunelu. Pokud je například adresa rozhraní 10.100.0.8/31, Cloudflare určí cílovou adresu paketu pro 10.100.0.9 a získává ji z 10.100.0.8.

Rozsahy adres rozhraní

Pole adresy rozhraní používá buď /30 nebo /31 Rozsah CIDR:

• /31 rozsah: IP adresa, kterou zadáte, patří straně Cloudflare, druhá IP adresa patří straně klienta. Pokud je například adresa rozhraní 10.100.0.8/31, poté 10.100.0.8 je strana Cloudflare a 10.100.0.9 je strana klienta.
• /30 rozsah: IP adresa, kterou zadáte, patří straně Cloudflare, druhá IP adresa (kromě broadcastové adresy a identifikátoru sítě) patří straně klienta. Pokud je například adresa rozhraní 10.100.0.9/30, poté 10.100.0.9 je strana Cloudflare a 10.100.0.10 je strana klienta.

Můžete také nakonfigurovat obousměrnou kontrolu stavu s vlastním veřejným cílem, což je doporučený postup pro nastavení tunelu Azure Active Standby.

Tyto pakety proudí do Cloudflare a z Cloudflare přes tunely, které jste nakonfigurovali, aby poskytovaly plnou viditelnost cesty provozu mezi sítí Cloudflare a vašimi pobočkami. Pro příjem paketů kontroly stavu u tunelů IPsec musíte nakonfigurovat traffic selectors.

Viz Přidejte tunely kde zjistíte, jak nakonfigurovat obousměrné nebo jednosměrné kontroly stavu.

U zákazníků používajících starší systém kontroly stavu s rozsahem veřejných IP adres Cloudflare doporučuje:

• Konfigurace cílové IP adresy kontroly stavu tunelu na adresu v rámci 172.64.240.252/30 rozsahem předpony.
• Použití trasy založené na zásadách, která odpovídá paketům se zdrojovou IP adresou totožnou s nakonfigurovaným cílem kontroly stavu tunelu (například 172.64.240.253/32), a směrujte je zpět do Cloudflare přes tunel.

Sonda kontroly stavu tunelu může mít dva možné typy: request a reply. U obou typů závisí zdrojová a cílová adresa na směru. Více informací najdete v Přidejte tunely kde zjistíte, jak toto nastavení změnit.

U kontroly stavu typu request je payload sondy požadavkem ICMP.

U jednosměrné sondy je zdrojovou adresou strana tunelu patřící Cloudflare (veřejně směrovatelná adresa) a cílem je router na straně originu (rovněž veřejně směrovatelný). Router na straně originu sondu přijme, vytvoří odpověď ICMP s opačným zdrojem a cílem a odešle ji mimo tunel.

U obousměrné sondy je zdrojovou adresou adresa rozhraní na straně tunelu patřící Cloudflare (privátně směrovatelná adresa) a cílovou adresou je adresa rozhraní tunelu (rovněž privátně směrovatelná). Router na straně originu sondu přijme, vytvoří odpověď ICMP s opačným zdrojem a cílem a odešle ji do tunelu.

U kontroly stavu typu reply je payload sondy odpovědí ICMP.

U jednosměrné sondy je cílovou adresou strana tunelu patřící Cloudflare (veřejně směrovatelná adresa) a zdrojem je router na straně originu (rovněž veřejně směrovatelný). Router na straně originu sondu přijme a beze změny ji odešle zpět jako odpověď mimo tunel.

U obousměrné sondy je cílovou adresou adresa rozhraní na straně tunelu patřící Cloudflare (privátně směrovatelná adresa) a zdrojovou adresou je adresa rozhraní tunelu (rovněž privátně směrovatelná). Router na straně originu přijme paket sondy a odešle jej beze změny zpět jako odpověď do tunelu, protože cíl je směrován přes tunel.

flowchart TB
accTitle: Bidirectional request style
accDescr: Shows the flow of a bidirectional request-style tunnel health check probe and response between Cloudflare and the origin.
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_request([ICMP Echo Request])
   bare_echo_request --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_request([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_request --> Internet([Internet])
   Internet --- encapsulated_echo_request_2([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_request_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_request([ICMP Echo Request])
   received_bare_echo_request --> origin(Origin)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo Reply])
   bare_echo_reply --- origin_tunnel_2(Tunnel)
   origin_tunnel_2 --- encapsulated_echo_reply([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply --- Internet_2([Internet])
   Internet_2 --> encapsulated_echo_reply_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply_2 --> tunnel_2[Tunnel]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo Reply])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: Bidirectional reply style
accDescr: Shows the flow of a bidirectional reply-style tunnel health check probe and response between Cloudflare and the origin.
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(Origin)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo Reply])
   bare_echo_reply --- origin_tunnel_2(Tunnel)
   origin_tunnel_2 --- encapsulated_echo_reply([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply --- Internet_2([Internet])
   Internet_2 --> encapsulated_echo_reply_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_reply_2 --> tunnel_2[Tunnel]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo Reply])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: Unidirectional echo request
accDescr: Shows the flow of a unidirectional echo request health check from Cloudflare to the origin and back.
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Request])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Request >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Request])
   received_bare_echo_reply --> origin(Origin)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([Internet])
   Internet_2 --> cloudflare

flowchart TB
accTitle: Unidirectional echo reply
accDescr: Shows the flow of a unidirectional echo reply health check from Cloudflare to the origin and back.
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo Reply])
   bare_echo_probe --> tunnel[Tunnel]
   tunnel --- encapsulated_echo_probe([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe --> Internet([Internet])
   Internet --- encapsulated_echo_probe_2([Tunnel Protocol < ICMP Echo Reply >])
   encapsulated_echo_probe_2 --> origin_tunnel(Tunnel)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo Reply])
   received_bare_echo_reply --> origin(Origin)
   origin --- received_bare_echo_reply_2([ICMP Echo Reply])
   received_bare_echo_reply_2 --> Internet_2([Internet])
   Internet_2 --> cloudflare

Každé datové centrum Cloudflare nakonfigurované pro zpracování vašeho provozu odesílá kontrolní sondy stavu tunelu. Frekvence, s jakou Cloudflare tyto sondy odesílá, se liší podle tunelu a lokality. Tuto frekvenci můžete upravit pro jednotlivý tunel úpravou health_check míru s API nebo dashboard. Rychlost můžete nastavit jako nízká, mid, nebo vysoká, s mid je výchozí.

Skutečný vzorec pro výpočet rychlosti zohledňuje počet serverů v datovém centru Cloudflare, případně u dynamicky vytvářených namespace počet serverů, na kterých je zákaznický namespace zřízen. Rychlost je dynamická a závisí na velikosti sítě Cloudflare.

Když se pokus o sondu nezdaří pro funkční tunel, každý server, který selhání zjistí, rychle provede až dvě další sondy, aby získal přesný výsledek. Cloudflare postupuje stejně, pokud byl tunel nedostupný a sondy začnou opět vracet úspěch. Protože servery globální sítě Cloudflare odesílají sondy až každou sekundu, vaše síť bude přijímat několik set paketů kontroly stavu za sekundu. Každé datacentrum Cloudflare odešle v rámci jedné sondy pouze jeden paket kontroly stavu, což představuje poměrně zanedbatelné množství provozu.

Existují tři stavy zdraví tunelu: funkční, degradovaný a nedostupný.

Funkční tunely mají přednost před degradovanými tunely a degradované tunely mají přednost před tunely, které jsou nedostupné.

Cloudflare WAN směruje provoz do tunelů podle priorit, které nastavíte při přiřadit priority tras tunelu během onboardingu. Trasy tunelu s nižšími hodnotami mají přednost před trasami s vyššími hodnotami.

• Pokud za posledních pět minut selže alespoň 0.1 % kontrol stavu tunelu (s minimálně dvěma selháními), Cloudflare WAN považuje spoj za ztrátový a nastaví stav tunelu na degraded (za předpokladu, že tunel není ve stavu down).
• Cloudflare WAN vyžaduje dvě selhání, takže ztráta jediného paketu sama o sobě penalizaci nevyvolá.
• Cloudflare WAN poté okamžitě nastaví stav tunelu na degradovaný a uplatní penalizaci priority.

• Pokud selžou všechny kontroly stavu z alespoň tří vzorků za poslední jednu sekundu, Cloudflare WAN okamžitě převede tunel ze stavu healthy nebo degraded do stavu down a uplatní prioritní penalizaci na trasy vedené tímto tunelem.
• Určení stavu nedostupný má přednost před určením stavu degradovaný. Tunel proto může být vždy jen v jednom z těchto stavů: nedostupný, degradovaný nebo funkční.

Když Cloudflare WAN identifikuje trasu, která není zdravá, uplatní tyto penalizace:

• Degradovaný: Přidat 500,000 na prioritu.
• Nedostupný: Přidat 1,000,000 na prioritu.

Hodnoty penalizací za selhání jsou záměrně extrémní, aby vždy převýšily hodnoty priority přiřazené během konfigurace směrování.

Namísto úplného odebrání trasy zachovává použití penalizace redundanci a ponechává zákazníkům s jediným tunelem více možností. Penalizace se uplatní i v případě, že je nezdravých více tunelů.

V případě výpadku datového centra Cloudflare globální síť Cloudflare vaše prefixy neinzeruje a Cloudflare směruje vaše pakety do dalšího nejbližšího datového centra. Stav systému globální sítě Cloudflare a dashboardu zjistíte na Cloudflare System Status ↗.

Jakmile je tunel ve stavu nedostupný, servery globální sítě dále vysílají sondy podle dříve popsaného intervalu. Když se sonda vrátí jako funkční, server globální sítě, který funkční paket přijal, okamžitě odešle další dvě sondy. Pokud se obě sondy vrátí jako funkční, Cloudflare WAN nastaví stav tunelu na degradovaný (protože tři po sobě jdoucí úspěšné sondy už nesplňují podmínku pro stav nedostupný).

Tunely ve stavu degradovaný přejdou do stavu funkční, jakmile míra selhání za posledních 30 sond klesne pod 0.1%. Tento přechod může trvat až 30 minut.

Systém kontrol stavu tunelů v Cloudflare WAN umožňuje tunelu rychlý přechod ze stavu funkční do stavu degradovaný nebo nedostupný, zatímco opačný přechod, ze stavu degradovaný nebo nedostupný zpět do stavu funkční, probíhá pomaleji. Toto chování se nazývá hystereze a brání změnám směrování způsobeným flappingem a dalšími přerušovanými výpadky sítě.

Uvažujme dva tunely a jejich přiřazené priority směrování. Pamatujte, že nižší hodnoty trasy mají vyšší prioritu.

• Tunnel 1, priorita trasy 100
• Tunnel 2, priorita trasy 200

Pokud jsou oba tunely ve stavu healthy, priorita směrování nasměruje provoz výhradně do Tunnel 1, protože jeho priorita trasy ve výši 100 je vyšší než u Tunnelu 2. Tunnel 2 nepřijímá žádný provoz, kromě sond kontroly stavu tunelu. Kontroly stavu endpointů probíhají pouze přes Tunnel 1 do jejich cíle uvnitř zdrojové sítě.

Pokud se spojení mezi Tunnel 1 a Cloudflare stane nepoužitelným, servery globální sítě Cloudflare zjistí selhání při dalším health check testu a okamžitě provedou další dva testy (za předpokladu, že byl tunel původně funkční).

Když server globální sítě neobdrží od těchto dvou dodatečných sond správné odpovědi ICMP, označí Tunnel 1 jako nedostupný a sníží jeho prioritu na 1,000,100. Priorita se poté přesune na Tunnel 2 a Cloudflare WAN okamžitě přesměruje pakety přicházející na daný server globální sítě na Tunnel 2.

Předpokládejme, že se vyřeší problém s konektivitou, kvůli kterému přešel Tunel 1 do stavu down. Při příštím intervalu kontroly stavu obdrží vydávající server globální sítě úspěšnou sondu a okamžitě odešle další dvě sondy, aby ověřil stav tunelu.

Pokud všechny tři sondy vrátí úspěšný výsledek, Cloudflare WAN převede tunel ze stavu down do stavu degraded. V rámci tohoto přechodu Cloudflare sníží prioritní penalizaci této trasy tak, aby se její priorita rovnala 500,100. Protože Tunel 2 má prioritu 200, provoz nadále prochází přes Tunnel 2.

Servery globální sítě nadále sondují Tunnel 1. Jakmile míra selhání kontroly stavu klesne pod 0.1 % po dobu pěti minut, Cloudflare WAN nastaví stav tunelu na zdravý. Cloudflare poté plně obnoví prioritu směrování tunelu Tunnel 1 na 100, a řízení provozu vrátí datový tok zpět na Tunnel 1.

Nápovědu k řešení problémů se stavem tunelu najdete v Odstraňování problémů se stavem tunelu.