INTEGRITY Dokumentace

Přineste si do Cloudflare vlastní IP adresní prostor

Úvod

Cloudflare přináší zabezpečení a výkon digitálnímu prostředí našich zákazníků. Jednou z vlastností proxy služeb je ale to, že interakce na webu směřující do Cloudflare (například dotazy DNS nebo požadavky na poskytovatele SaaS) se navenek jeví jako pocházející z IP prostoru Cloudflare. To může některým podnikům přinášet komplikace.

Partneři nebo jiné vztahy B2B mohou například využívat veřejný IP prostor vlastněný zákazníkem k ověřování a přiřazování v rámci různých transakcí. Mohou se přitom dívat na přeloženou adresu veřejného hostname (například www.example.com) a očekávat, že tato IP adresa odpovídá konkrétnímu rozsahu nebo adrese, o níž je známo, že patří zákazníkovi.

Bring Your Own IP (BYOIP) umožňuje podnikům přinést si vlastní IP rozsah do Cloudflare, a získat tak zabezpečení a výkon platformy Cloudflare, přičemž navenek stále vystupují pod svým vlastním veřejným IP rozsahem. Tento diagram referenční architektury ukazuje různé způsoby, jak mohou zákazníci přenést svůj IP rozsah do sítě Cloudflare, a přínosy, které tím získají.

První scénář BYOIP: proxy služby Cloudflare

Výchozím chováním, pokud je proveden dotaz DNS na hostname proxovaný přes Cloudflare, je vrátit jednu z výchozí anycast IP adresy ↗. Provoz se poté urychlí, ochrání a, pokud jej neobslouží mezipaměť Cloudflare, odešle na origin server zákazníka.

Na diagramu níže provoz místo výchozího chování prochází přes platformu aplikačních služeb Cloudflare, avšak DNS dotazy vrací IP adresu, kterou vlastní zákazník, přičemž zároveň využívá výhod anycast sítě Cloudflare.

V tomto příkladu se používají dva odlišné rozsahy sítí:

Obrázek 1: Cloudflare inzeruje rozsah IP adres zákazníka a přesměrovává ho na IP adresu origin serveru.
Obrázek 1: Cloudflare inzeruje rozsah IP adres zákazníka a přesměrovává ho na IP adresu origin serveru.
  1. Aby mohl Cloudflare odpovídat na DNS dotazy adresami z prostoru zákazníka, musí zákazník poskytnout Cloudflare plnou moc (Letter of Agency, LOA), aby bylo možné tyto adresy zprovoznit a inzerovat. Tento adresní prostor (v příkladu 152.3.15.0/24) musí být vyhrazen pro konfiguraci Cloudflare a nesmí být použit nikde v prostředí zákazníka.
  2. Konfigurace DNS Cloudflare pro origin server www.abc.com je nakonfigurováno s IP adresou 152.3.14.10/32.
  3. DNS dotaz na www.abc.com je proveden.
  4. Cloudflare vrací adresu z prostoru zákazníka, který byl dříve nakonfigurován z prostoru BYOIP poskytnutého zákazníkem. V tomto případě byla odpovědí 152.2.15.200, která je součástí /24 prefixu 152.2.15.0/24.
  5. Eyeball odešle požadavek na 152.2.15.200 který je směrován na Cloudflare.
  6. Cloudflare proxuje připojení pomocí SNI (www.abc.com) ke zjištění skutečné IP adresy původního serveru, 152.3.14.10. Požadavek se poté směruje přes proxy služby Cloudflare, jako je ochrana před útoky DDoS, Web Application Firewall a Bot Management.
  7. Úspěšné požadavky jsou odesílány na origin (pokud nejsou obslouženy z cache) na 152.3.14.10 se zdrojovou IP adresou patřící do sítě Cloudflare.

Druhý scénář BYOIP: ochrana sítě před útoky DDoS

Cloudflare je známý svými službami pro zmírňování DDoS útoků, které chrání veřejné weby a API. Stejné technologie lze využít i k ochraně celých sítí. Technologie Cloudflare Magic Transit nabízí cloudovou službu ochrany sítě před útoky DDoS pro veřejný IP prostor našich zákazníků.

Obrázek 2: Ochranu proti útokům DDoS lze umístit před rozsah BYOIP a před vaši tunelovanou síť Cloudflare.
Obrázek 2: Ochranu proti útokům DDoS lze umístit před rozsah BYOIP a před vaši tunelovanou síť Cloudflare.
  1. Aby mohl Cloudflare přitahovat provoz určený pro síťové prefixy zákazníka, musí zákazník poskytnout Cloudflare plnou moc (Letter of Agency, LOA), aby bylo možné síťové prefixy zprovoznit a inzerovat.
  2. Po zřízení bude Cloudflare inzerovat prefixy zákazníka do internetu, čímž nasměruje provoz určený pro tyto sítě do sítě Cloudflare.
  3. Veškerý provoz určený pro tyto prefixy je směrován do Cloudflare.
  4. Provoz DDoS zmírňuje Cloudflare a legitimní provoz je směrován zpět do sítí zákazníka přes tunely, nebo prostřednictvím Cloudflare Network Interconnect (CNI) do prostředí zákazníka.

Podrobnější informace o možnostech Magic Transit naleznete v Referenční architektura Magic Transit.