Cloud VPN k VM na GCP: použijte interní IP, ne NAT IP

Koncový bod brány, interní adresa VM a externí adresa NAT jedna ku jedné plní tři různé úlohy. Zkontrolujte, kterou z nich vaše trasa používá.

Když se místní síť dostane do VPC přes Cloud VPN, cílem služby v Compute Engine je obvykle interní adresa VM. Externí IPv4 adresa není druhá adresa, kterou byste mohli dosadit do stejné privátní trasy. Většina zmatku v této oblasti pramení z toho, že se tři adresy se třemi úlohami považují za zaměnitelné, proto začněte tím, že pojmenujete, kterou daný paket používá.

Tři adresy, tři úlohy

Pojmenujte všechny tři, než začnete kteroukoli ladit, protože odpověď mění objekt, který budete zkoumat dál.

AddressJob
Cloud VPN endpointwhere the IPsec peers meet
Internal IPthe address your route and firewall must name
External IPv4the platform's inbound mapping, not a guest address

První patří tunelu. Druhá patří vašemu návrhu trasy a firewallu. Třetí patří příchozímu přístupu z internetu a je mapovaná, ne připojená. Návrh, který funguje pro jednu z nich, nic neříká o zbylých dvou.

Proč externí adresa není druhé rozhraní

Průvodce adresováním je autoritou pro to, jak se v Compute Engine liší interní a externí dostupnost. Externí IPv4 adresa v Compute Engine je mapování jedna ku jedné na jediné interní NIC instance, takže host nikdy nevidí druhé rozhraní ani druhou adresu na tomto NIC. Co VM hlásí zevnitř, je stále jedna primární interní adresa.

Proto jsou privátní klient směrující provoz tunelem k 10.24.1.7 a klient cílící na externí adresu VM na různých cestách. Otevření pravidla firewallu pro veřejnou adresu nic nemění na trase ve VPC, která musí nést provoz tunelu, a úprava trasy v hostu nepřesouvá mapování platformy. Vyberte adresu, kterou vaše trasa pojmenovává, a pak kontrolujte jen objekty, které ji řídí. Tato disciplína odstraňuje většinu hádání z této cesty odstraňování problémů.

Projděte cestu s gcloud

Začněte u instance a přečtěte obě adresy ze stejného objektu, abyste věděli, o které vaše dokumentace mluví:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Potom potvrďte směrování a oprávnění, na kterých cesta skutečně závisí:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Přečtěte si inzerované a naučené rozsahy tunelu, trasu ve VPC pro podsíť pracovní zátěže a pravidlo firewallu, které povoluje místní zdroj. Tyto tři se musí shodovat, než je posluchač v hostu vůbec relevantní.

Pak zkontrolujte hosta: naslouchá služba na interní adrese a vede její zpětná cesta znovu přes VPC? Posluchač vázaný pouze na veřejnou adresu v tomto testu selže, i když je každý objekt na straně cloudu správný.

Veřejný prefix je jiná otázka

Nic z výše uvedeného neznamená, že každá adresa přenášená uvnitř VPN musí být RFC1918. Vzdálená síť může být legitimně číslována z veřejného prostoru, pokud platforma podporuje směrování a operátor má pravomoc nad adresou. To je běžná volba návrhu.

Není to totéž jako zacházet s běžnou externí NAT adresou, jako by to byla další interní adresa podsítě. Jedno je prefix, který směrujete; druhé je mapování, které platforma uplatňuje na příchozí přístup.

Externí IPv6 a speciálně navržená uspořádání adres mají vlastní sémantiku. Pokud váš plán závisí na některém z nich, přečtěte si dokumentaci platformy k této funkci, místo abyste zobecňovali z případu IPv4. Mapování IPv4 je běžný případ, ne jediný, a výjimky mají každá svá pravidla.

Překrývající se rozsahy jsou jiný problém

Překrývající se privátní rozsahy jsou skutečný důvod, proč lidé sahají po veřejné adrese, a je to špatná páka. Změna cíle na NAT adresu VM překryv neřeší; mění, pro kterou adresu paket tvrdí, že je, aniž by definovala, jak funguje zpětná cesta.

Vyřešte překryv záměrně: přečíslujte, použijte podporovaný návrh překladu nebo směrujte přes síť, kde se prefixy nesrážejí. Každé z toho je návrh s vlastníkem. NAT adresa není návrh.

Dokumentujte obě pole odděleně

Zaznamenejte protějšek tunelu a cíl pracovní zátěže jako dvě samostatná pole runbooku, každé s trasou a pravidlem firewallu, které ho podporuje. Tunel IPsec, který se zvedne, vám řekne jen to, že se strany shodly; neříká nic o tom, na které adrese je pracovní zátěž dostupná, ani o tom, zda je její privátní trasa úplná.

Ověřte skutečným klientem na druhé straně: přeložte jméno, potvrďte, že vrací interní adresu, připojte se a zkontrolujte zpětný provoz. Dokumentace k IP adresám Compute Engine je referencí pro rozlišení interní a externí, které je použito výše.

Související články