Proč virtuální počítač s VPN zařízením v Azure ztrácí zpáteční cestu
VPN zařízení ve virtuálním počítači Azure potřebuje, aby se UDR, příznak předávání na síťové kartě a zásada hosta shodovaly. Sledujte jeden požadavek pobočky skrz všechny tři.
Virtuální počítač Azure s VPN zařízením leží uvnitř dvou nezávislých rozhodovacích systémů. Azure rozhoduje, kudy paket opouští podsíť, pomocí směrovacích tabulek a nastavení předávání na síťové kartě. Vlastní operační systém zařízení rozhoduje, zda předá dešifrovaný paket dál. Tunel, který se bezchybně zvedne, může na druhém systému stále selhat, a právě tam většina těchto nasazení skončí.
Tři vlastníci jedné cesty
Vezměte pobočkovou síť 192.168.50.0/24 a podsíť pracovního zatížení 10.0.10.0/24, přičemž zařízení je na 10.0.0.4 ve své vlastní podsíti. Jeden požadavek se dotkne tří samostatných konfigurací.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Každý řádek ve většině organizací vlastní jiný tým, a proto tato závada obvykle dorazí jako tři tikety místo jednoho.
Trasa, která ukazuje na zařízení
Přidružte směrovací tabulku k podsíti pracovního zatížení a dejte pobočkovému prefixu další skok typu Virtual appliance s 10.0.0.4 jako adresou. Použijte dostupnou privátní adresu zařízení, nikdy jeho veřejný vstupní bod VPN. Další skok musí být adresa, kterou podsíť pracovního zatížení už umí dosáhnout. Zbytek směrování pracovního zatížení nechte být, pokud jste se vědomě nerozhodli nahradit výchozí trasu.
Držte zařízení ve vlastní podsíti a ujistěte se, že trasa, která posílá pobočkový provoz na zařízení, nezachytí i vlastní odchozí cestu zařízení. Taková smyčka vypadá jako zdravý tunel s nulou odpovědí, což je velmi nepříjemná věc k ladění ve 2 hodiny ráno.
Příznak síťové karty, na který všichni zapomínají
Azure má nastavení předávání IP pro každou síťovou kartu a ve výchozím stavu je vypnuté. Existuje proto, že karta, která předává, dostává pakety adresované něčemu jinému, a tiché zahazování je bezpečný výchozí stav pro všechny ostatní.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true ho zapne pro jedno rozhraní. Pokyny Microsoftu k předávání na síťové kartě vyžadují toto nastavení na každé připojené kartě, která předává provoz, takže zařízení s jednou kartou ho stále potřebuje nastavené na této kartě.
Příznak není trasa ani pravidlo firewallu. Zapnutím získáte oprávnění a nic dalšího.
Co host udělá s dešifrovaným paketem
Když tunel skončí, vlastní síťový zásobník zařízení udělá další rozhodnutí. Na hostu Linux je předávání IPv4 nastavením za běhu a sysctl -w net.ipv4.ip_forward=1 vydrží do dalšího startu. Uložte ho natrvalo do souboru /etc/sysctl.d/ místo toho. Zařízení od výrobce má svůj ekvivalent a linuxové instrukce vložené do platformy výrobce obvykle nedělají vůbec nic.
Zásada firewallu hosta je opět oddělená, stejně jako skupina zabezpečení sítě pracovního zatížení. Povolení UDP 500 a 4500 na veřejnou adresu virtuálního počítače chrání tunel; neříká nic o tom, zda se dešifrovaný požadavek pobočky může dostat na port pracovního zatížení.
Sledujte jeden požadavek a jeho odpověď
Vyberte jeden povolený tok a projděte ho od začátku do konce. Pobočka potřebuje trasu pro 10.0.10.0/24 přes připojení k lokalitě, zařízení potřebuje cestu doručení do podsítě pracovního zatížení a podsíť pracovního zatížení potřebuje zpáteční trasu k pobočce.
Rozhodněte brzy, zda návrh zachová zdrojovou adresu pobočky, nebo ji překládá. NAT mění to, co pracovní zatížení vidí, takže jeho přístupová pravidla mají popisovat model, který jste skutečně zvolili, a ne odhadovanou adresu brány.
Úspěšné navázání spojení dokazuje jeden článek toho řetězu. Cesta je úplná, když se odpověď vrací přes stejné zařízení a vlastní zásada pracovního zatížení to dovolí.