Miért veszíti el a visszautat az Azure-beli VPN-eszköz VM
Az Azure VM-ben futó VPN-eszköznek össze kell hangolnia az UDR-t, a hálózati kártya továbbítási jelzőjét és a vendég házirendjét. Kövessen végig egy fióki kérést mindhármon.
Egy VPN-eszközt futtató Azure VM két független döntési rendszeren belül helyezkedik el. Az Azure dönti el, hogy egy csomag melyik alhálózatból lép ki, útvonaltáblák és a hálózati kártya továbbítási beállítása segítségével. Az eszköz saját operációs rendszere dönti el, hogy továbbítja-e a visszafejtett csomagot. Egy tökéletesen felépülő alagút mégis elbukhat a második rendszeren, és itt áll meg az ilyen telepítések többsége.
Egy útvonal három gazdája
Vegyen egy fiókhálózatot 192.168.50.0/24 és egy számítási alhálózatot 10.0.10.0/24, az eszköz pedig a 10.0.0.4 címen van a saját alhálózatában. Egyetlen kérés három külön beállítást érint.
| 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 |
A legtöbb szervezetnél minden sort más csapat birtokol, ezért ez a hiba általában egy helyett három jegy formájában érkezik.
Az útvonal, amely az eszközre mutat
Rendeljen útvonaltáblát a számítási alhálózathoz, és adjon a fiók előtagjának Virtual appliance típusú következő ugrást a 10.0.0.4 címmel. Az eszköz elérhető magáncímét használja, soha ne a nyilvános VPN belépési pontját. A következő ugrásnak olyan címnek kell lennie, amelyet a számítási alhálózat már el tud érni. A számítási feladat többi útvonalát hagyja békén, hacsak nem döntött szándékosan az alapértelmezett útvonal lecseréléséről.
Tartsa az eszközt a saját alhálózatában, és győződjön meg róla, hogy a fiókforgalmat az eszközhöz küldő útvonal nem kapja el az eszköz saját kimenő útvonalát is. Egy ilyen hurok egészséges alagútnak látszik nulla válasszal, és ezt nagyon kellemetlen hajnali 2-kor hibakeresni.
A hálózati kártya jelzője, amelyet mindenki elfelejt
Az Azure-ban hálózati kártyánként van IP-továbbítási beállítás, és az alapértelmezés szerint ki van kapcsolva. Azért létezik, mert a továbbító kártya olyan csomagokat kap, amelyek valami másnak vannak címezve, és ezek csendes eldobása a biztonságos alapértelmezés mindenki más számára.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true bekapcsolja egyetlen interfészre. A Microsoft hálózati kártya továbbításáról szóló útmutatója megköveteli a beállítást minden csatlakoztatott kártyán, amely forgalmat továbbít, tehát az egykártyás eszköznek is be kell állítania ezen a kártyán.
A jelző nem útvonal és nem tűzfalszabály. Bekapcsolása engedélyt ad, és semmi mást.
Mit tesz a vendég a visszafejtett csomaggal
Amikor az alagút véget ér, az eszköz saját verme hozza meg a következő döntést. Linux vendégen az IPv4-továbbítás futásidejű beállítás, és sysctl -w net.ipv4.ip_forward=1 a következő indításig tart. Őrizze meg inkább egy fájlban a /etc/sysctl.d/ könyvtár alatt. Egy gyártói eszköznek megvan a maga megfelelője, és a gyártói platformba beillesztett Linux-utasítások általában semmit sem tesznek.
A vendég tűzfalszabályzata megint külön van, és a számítási feladat hálózati biztonsági csoportja is. Az UDP 500 és 4500 engedélyezése a VM nyilvános címére védi az alagutat; semmit nem mond arról, hogy egy visszafejtett fióki kérés elérhet-e egy számítási feladat portját.
Kövessen egy kérést és a válaszát
Válasszon egy engedélyezett folyamot, és kövesse végig. A fióknak útvonalra van szüksége a 10.0.10.0/24 céljához a helyszínkapcsolaton át, az eszköznek szállítási útvonalra van szüksége a számítási alhálózathoz, a számítási alhálózatnak pedig visszaútra a fiók felé.
Döntse el korán, hogy a terv megőrzi-e a fiók forráscímét, vagy lefordítja. A NAT megváltoztatja, mit lát a számítási feladat, ezért a hozzáférési szabályainak azt a modellt kell leírniuk, amelyet valóban választott, nem egy feltételezett átjárócímet.
Egy sikeres kézfogás a lánc egyik szemét bizonyítja. Az útvonal akkor teljes, ha a válasz ugyanazon az eszközön keresztül tér vissza, és a számítási feladat saját házirendje ezt engedi.