Két helyszíni VPN-cím: két Azure-peer, nem egy

Az ábrán két internetkapcsolat van a fióktelepen és egy Azure VPN-átjáró, így a helyi hálózati átjáró mindkét nyilvános címet megkapja. Rendben néz ki, és nem úgy működik, ahogy az ábra sugallja. Minden helyszíni VPN-eszköz külön peer-kapcsolat, és a Microsoft többeszközös terve mindegyiknek saját helyi hálózati átjáró-erőforrást és saját kapcsolatot ad. Egy második cím hozzáadása egyetlen erőforráshoz nem hoz létre második peert. Olyan erőforrást hoz létre, amely egyik eszközt sem írja le megfelelően.

A mítosz: egy átjáró, két cím

A helyi hálózati átjáró egy távoli peer leírása: egy nyilvános végpont és a mögötte lévő privát előtagok. Nincs támogatott mód arra, hogy ez az erőforrás «a két készülék bármelyike» jelentéssel bírjon.

Ugyanez a zavar a másik irányban is megjelenik, ahol két nyilvános Azure IP-t a két Azure-átjáró létezésének bizonyítékaként olvasnak.

Számolja meg az objektumokat, aztán az alagutakat

Vegyen két egymástól függetlenül üzemeltetett helyszíni eszközt, mindegyiket saját nyilvános címével és hozzáférésével ugyanazokhoz a privát hálózatokhoz, plusz egy útvonalalapú Azure-átjárót aktív-aktív módban. Az Azure-átjárónak két aktív példánya van külön nyilvános IP-vel. Minden helyszíni eszköz mindkét példányhoz kapcsolódik. Ez a teljes háló, és az objektumok száma ebből következik, nem az ábrából.

Az aritmetika elég rövid ahhoz, hogy beillessze a tervezési dokumentumba:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Egy kapcsolat-erőforrás egynél több mögöttes alagutat hordozhat, így négy alagút nem jelent négy virtuális hálózati átjárót. Két nyilvános Azure IP sem ugyanazok az objektumok, mint a távoli helyet leíró két helyi hálózati átjáró.

Mit ad hozzá az aktív-aktív az Azure oldalán

Az aktív-aktív az Azure-átjárót egy aktív példányból kettőre változtatja, mindegyiket saját nyilvános IP-vel, és ez teszi egyáltalán lehetővé a teljes hálót. Nem duplázza meg egyetlen folyam áteresztőképességét. Nem szünteti meg azt sem, hogy a helyszíni oldalnak támogatnia kell az egyenlő költségű többutas útválasztást, ha mindkét eszköz egyszerre továbbít. Az erőforrások létrehozása előtt erősítse meg az átjáró módját, az SKU-t és a távoli eszköz képességeit.

A passzív készenléti átjáró teljesen érvényes terv; csak más alagútszámot eredményez.

A BGP mindkét utat használhatóvá teszi

A többeszközös tervhez mindkét helyszíni eszköz BGP-t futtat. Adjon mindegyiknek egyedi BGP-peer-címet, és hirdesse ugyanazokat a tervezett privát előtagokat a megfelelő utakon. A privát előtagok azonosítják a védett hálózatokat, míg a nyilvános címek azt, hogy hol végződnek a titkosított hordozókapcsolatok. A kettő összekeverése olyan tervet ad, amelyben minden alagút fel van, és az útvonalak hibásak.

Tervezze meg a visszaútválasztást és minden olyan állapotalapú ellenőrzést, amelynek el kell viselnie bármelyik utat. Egy egészséges IKE-munkamenet minden végponton nem bizonyítja, hogy egy munkaterhelés minden hirdetett útvonalat használhat.

A folyamalapú kiválasztás nem sávszélesség-összevonás

Az Azure folyamonként választ útvonalat a folyam címzése és portjai feletti hash segítségével. Állandósult állapotban egy adott TCP- vagy UDP-folyam csomagjai általában ugyanazt az alagutat használják, és a helyszíni oldal a visszirányhoz másik alagutat választhat. Ezért két eszköz és négy alagút a rendelkezésre állást javítja, nem egy átvitel sebességét. Amikor egy szállítói dia összevonást ígér, az egy másik funkciót vagy félreértést ír le.

Teszteljen párhuzamos folyamokkal, ha látni akarja az utak szétoszlását, és egyetlen folyammal, ha a határt akarja látni.

Milyen redundanciát távolított el valójában

Két WAN-cím egy eszközön javítja a hozzáférési kapcsolat lehetőségeit, miközben megosztja az eszköz tápellátását, szoftverét és hibaállapotát. Nem ugyanaz, mint két eszköz, és semmilyen Azure-oldali konfiguráció nem változtat ezen. Kövesse a szállító által támogatott két WAN-os vagy klaszter-tervet ahelyett, hogy a címek számából következtetne a redundanciára. Aztán tesztelje: távolítson el egyszerre egy utat, és erősítse meg a fennmaradó útvonalakat, valamint egy valódi alkalmazáscserét mindkét irányban.

Számítson felderítési és konvergenciakésésekre, és arra, hogy bizonyos meglévő munkamenetek véget érnek.