Két nyilvános IP egyetlen Azure VPN VM-en: melyik mit tesz

Két nyilvános IP egyetlen Azure VPN VM-en olyan elvárást kelt, amely ritkán teljesül: az a cím, amelyhez az ügyfelek csatlakoznak, ugyanaz lesz, amelyet a webhelyek látnak. Három független döntés adja ezt az eredményt, és közülük csak az első szól az alagút figyelőjéről. A második a vendég forrása, amelyet a továbbított ügyfélforgalomhoz használunk, a harmadik pedig az Azure kimenő módszere, amely erre a forrásra vonatkozik. Módosítson egyet, és a másik kettő marad, ahol volt, ezért döntsön mindegyikről kifejezetten.

1. döntés: hol végződik az alagút

Az Azure nyilvános IP-je a NIC privát IP-konfigurációjához kapcsolódik; ez nem olyan cím, amelyet a vendég operációs rendszerben ad hozzá. Olvassa el a leképezést, ne feltételezze: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Melyik privát címet adja vissza a lekérdezés, a vendégnek valójában azt kell használnia.

Egy NIC több IP-konfigurációt is hordozhat, így két nyilvános cím nem igényel két NIC-et. Ha a tervezés mégis két NIC-et használ, mindegyik hozza a saját vendég-útvonalait és következő ugrásait, és ezzel egy útválasztási döntést adott hozzá ahelyett, hogy egyszerűsített volna.

Kifejezett helyi kötéssel rendelkező szolgáltatás esetén a vendég valódi privát címéhez kössön, soha ne a nyilvános helyőrzőhöz. Az összes címet elfogadó figyelő minden IP-konfiguráción keresztül fogad forgalmat, amely eléri, ezért hálózati biztonsági csoporttal és a gazdagép tűzfalával korlátozza a belépést, ne remélje, hogy a kötési sorrend dönt.

2. döntés: milyen forrást használ a továbbított ügyfél

Miután az átjáró visszafejtette az ügyfél kérését, a továbbított csomag más, mint amely a VPN-figyelőhöz érkezett. A vendégnek engedélyezett továbbításra, a forgalmat engedélyező tűzfalszabályra és a felhőtervezés által engedélyezett forráscímre van szüksége. Ha lefordítja az ügyfél belső címét, az Azure azt a lefordított forrást értékeli, nem az ügyfél belső címét.

A szűk SNAT-szabály választhat vendég-privát forrást, de nem írhatja felül a későbbi Azure-fordítást. Válassza az SNAT-ot, ha ügyfelenkénti elszámoltathatóságra van szüksége a VM-en belül; hagyja ki, ha az alhálózat kimenő tervezése már stabil nyilvános forrást ad, és egy második fordítás csak állapotot adna hozzá.

3. döntés: melyik Azure kimenő módszer nyer

A Microsoft dokumentáljaa kimenő forgalom elsőbbségi sorrendjét: az eszközhöz vagy átjáróhoz vezető alkalmazható útvonal elsőbbséget élvez, és az alhálózat NAT Gateway-kapcsolata elsőbbséget élvez az adott útvonalon egy példányszintű nyilvános IP-vel szemben. Ez a sorrend az oka annak, hogy a 10.20.0.5-re történő fordítás nem bizonyítja, hogy egy webhely 198.51.100.20-t fog látni. Olvassa el együtt az effektív útvonaltáblát, a NAT Gateway-hozzárendelést és a NIC nyilvános IP-jét, mielőtt elfogadja a kimenő tervezést.

Tartsaaz Azure NIC továbbítási beállításátkülön a Linux továbbításától. A felhőjelző engedélyezi azokat a csomagokat, amelyek forrása vagy célja nincs a NIC-hez rendelve; nem kapcsolja be a net.ipv4.ip_forward beállítást, és a vendég beállítása nem ad felhőengedélyt.

Az alagút socketnek saját forrásdöntése van

A WireGuard Address beállítása a wg-quick alatt címet rendel a WireGuard interfészhez; ez nem külső UDP-kötési utasítás. A titkosított socket forrása az útvonaltáblát követi, ezért egy házirend-útvonal vagy egy második alapértelmezett útvonal elmozdíthatja anélkül, hogy az interfész címéhez nyúlna.OpenVPN: a local opció és az UDP multihome ugyanígy viselkedik: a figyelőre és annak válaszaira vonatkoznak, nem minden továbbított ügyfél internetes forrására.

Őrizze meg az alagutat hordozó alréteg-útvonalat, és erősítse meg, hogy az ügyfél továbbra is hitelesített válaszokat kap a várt belépési elrendezésből. Ne támaszkodjon a címlista sorrendjére állandó forrásválasztási házirendként, mert a NIC-hez hozzáadott következő cím megváltoztathatja, melyik nyer.

Mit fogadjon el, és milyen sorrendben

Három eredményt fogadjon el külön. Először egy külső ügyfél eléri a tervezett VPN-belépést. Másodszor egy új, engedélyezett kérés attól a VPN-ügyféltől a dokumentált internetkilépésen távozik. Harmadszor a nem szándékolt figyelő- és továbbítási útvonalak elutasítva maradnak. Rögzítse a nyilvános-privát leképezéseket és minden döntés vendég- és felhőgazdáit ugyanazon a helyen.

A sikeres alagút csak az első részt bizonyítja. Tesztelje a kilépést új folyammal, mert a gyorsítótárazott kapcsolat még sokáig használhatja a régi forrást az útvonal megváltozása után.