← Cloudflare One / cloudflare-one / troubleshooting / wan

IPsec

Tento návod vám pomůže diagnostikovat problémy s tunely IPsec (v dashboardu Cloudflare označovanými jako konektory), od počátečního navázání až po běžný provoz. Podle následujících částí určete svůj příznak a najděte odpovídající řešení.

• Stav tunelu zobrazuje Down a nikdy se nestane funkčním
• Tunelem neprochází žádný provoz
• Protokoly endpointu tunelu zobrazují chyby vyjednávání IKE nebo retransmise

Váš edge firewall možná blokuje provoz potřebný k navázání tunelu IPsec. Ověřte, že firewall povoluje:

• port UDP 500 (IKE)
• port UDP 4500 (IKE NAT-T)
• IP protokol 50 (ESP)

Vyjednávání IKE selže, pokud se parametry fáze 1 (IKE) nebo fáze 2 (IPsec) neshodují mezi endpointem vašeho tunelu a Cloudflare. Mezi běžné příznaky patří chyby „no proposal chosen“ v protokolech vašeho zařízení.

Ověřte, že vaše parametry odpovídají hodnotám podporovaným Cloudflare. Úplný seznam najdete v Podporované konfigurační parametry.

Selhání ověřování ve fázi 1 značí neshodu PSK. Řešení:

1. Přejděte na Connectory a vyberte svůj tunel.

   Přejděte na Connectory ↗

2. Vyberte Vygenerovat nový PSK.

3. Zkopírujte nový PSK přesně: nepřidávejte žádné mezery ani znaky navíc.

4. Aktualizujte endpoint svého tunelu pomocí nového PSK.

Cloudflare používá pro IKE ID formát FQDN. Pokud endpoint vašeho tunelu očekává jiný formát identity protistrany (například IP adresu), ověření selže i v případě, že je PSK správný.

Ujistěte se, že je endpoint vašeho tunelu nakonfigurován tak, aby přijímal identitu peer ve formátu FQDN. FQDN svého tunelu najdete v Connectory, vyberte svůj tunel a zkontrolujte jeho podrobnosti.

• Vyjednávání IKE se úspěšně dokončí
• Tunel zobrazuje Down nebo Degraded v dashboardu
• Provoz uživatelů může nadále procházet tunelem

Toto je nejběžnější problém s IPsec. Ochrana anti-replay očekává, že pakety od jednoho odesílatele budou přicházet v pořadí. Vzhledem k anycast architektuře Cloudflare provoz tunelu pochází z tisíců serverů, z nichž každý má vlastní čítač pořadí. To vede k tomu, že koncový bod tunelu zahazuje pakety jako doručené mimo pořadí.

Zakažte ochranu anti-replay na endpointu tunelu, nebo nastavte replay window na 0. Podrobné vysvětlení najdete v Ochrana anti-replay.

Stavové firewally (například Palo Alto Networks, Check Point, Cisco a Fortinet) zahazují výchozí Reply pakety kontroly stavu, protože v jejich tabulce relací neexistuje odpovídající požadavek ICMP.

Změňte typ kontroly stavu z Reply na Požadavek. Podrobné kroky najdete v Odstraňování problémů se stavem tunelu.

U jednosměrných kontrol stavu (health checks) odesílá Cloudflare sondy přes tunel, ale odpovědi se vracejí přes veřejný internet (direct server return). Pokud váš poskytovatel internetu blokuje pakety ICMP reply určené pro Cloudflare, kontroly stavu selžou, přestože provoz tunelu funguje normálně.

Pokud máte povolený egress provoz, zvažte přechod na obousměrné kontroly stavu, aby sonda i odpověď procházely tunelem. Podrobnosti o konfiguraci najdete v Odstraňování problémů se stavem tunelu.

Pokud používáte VPN založenou na zásadách (kde selektory provozu definují konkrétní prefixy místo 0.0.0.0/0), kontroly stavu typu Reply nefungují. Kontroly stavu Reply jsou adresované samy sobě na IP adresy Cloudflare, které leží mimo traffic selectors vašeho tunelu.

Místo toho použijte kontroly stavu ve stylu Request. Nakonfigurujte na koncovém bodu tunelu adresu loopback jako cíl kontroly stavu. Cíl musí být směrovatelný a pokrytý selektory provozu tunelu (šifrovací doménou). Další podrobnosti naleznete v Odstraňování problémů se stavem tunelu.

• Tunel se střídá mezi funkčním a nefunkčním stavem
• Občasná ztráta paketů na tunelu
• Provoz funguje po určitou dobu a poté se zastaví bez jakýchkoli změn konfigurace

Anycast architektura Cloudflare znamená, že pakety přicházejí z mnoha serverů s odlišnými čítači pořadí. Ochrana proti replay útokům to interpretuje jako replay útok a pakety občas zahazuje.

Zakažte ochranu anti-replay na endpointu tunelu, nebo nastavte replay window na 0. Podrobné vysvětlení najdete v Ochrana anti-replay.

Když endpoint tunelu zahájí rekeying IPsec, nové Security Associations (SA) se musí rozšířit po celé síti Cloudflare. Zpoždění šíření rekeyingu bylo výrazně omezeno a ve většině nasazení je vzácné. V některých konfiguracích však může během rekeyingu stále dojít ke krátkodobému zhoršení stavu tunelu.

Cloudflare rekey nikdy sama nezahajuje, pouze na něj reaguje. Všechny pokusy o rekey musí vycházet z vašeho tunel endpointu. Pokud vaše zařízení během rekey obdrží odpověď TEMPORARY_FAILURE, nastavte Dead Peer Detection (DPD) s akcí "restart", aby zařízení relaci IKE obnovilo automaticky. Bez restartu DPD se zařízení může zaseknout ve smyčce neúspěšných pokusů o rekey.

Chcete-li minimalizovat dopad rekeys, prodlužte životnost SA na endpointu tunelu, čímž snížíte frekvenci rekeys. Běžné hodnoty jsou 8-24 hodin pro IKE SA a 1-8 hodin pro IPsec SA. Více informací najdete v Odstraňování problémů se stavem tunelu.

Pakety, které přesahují MTU tunelu, jsou fragmentovány nebo zahazovány, což způsobuje občasné výpadky připojení. Ověřte, že je MTU nastaveno správně: obvykle 1476 pro tunely GRE a 1400-1450 pro tunely IPsec. Podrobný postup najdete v MTU a MSS.

Pomocí protokolů IPsec můžete sledovat aktivitu tunelu během fáze výměny klíčů při vyjednávání IPsec. Nakonfigurujte úlohu Logpush, která tyto protokoly přeposílá do preferované úložné služby k analýze.

1. Přejděte na Logpush stránce.

   Přejděte na Logpush ↗

2. Vyberte Vytvoření úlohy Logpush.

3. Vyberte Protokoly IPsec jako svou datovou sadu.

Viz Dokumentace Logpush pro další informace o funkcích, včetně dostupná pole v datové sadě.

Další informace najdete v úplné dokumentaci Cloudflare WAN.