Dve lokálne VPN adresy: dvaja partneri Azure, nie jeden
Druhá lokálna VPN adresa je ďalší partner, nie druhá hodnota poľa. Jedna brána lokálnej siete a jedno pripojenie na zariadenie, potom spočítajte tunely.
Diagram má v pobočke dve internetové linky a jednu bránu VPN v Azure, takže brána lokálnej siete dostane obe verejné adresy. Vyzerá to upravene a nefunguje to tak, ako diagram naznačuje. Každé lokálne VPN zariadenie je samostatný partnerský vzťah a návrh Microsoftu pre viac zariadení dáva každému vlastný prostriedok brány lokálnej siete a vlastné pripojenie. Pridanie druhej adresy k jednému prostriedku nevytvorí druhého partnera. Vytvorí prostriedok, ktorý správne nepopisuje ani jedno zo zariadení.
Mýtus: jedna brána, dve adresy
Brána lokálnej siete je opis vzdialeného partnera: jeden verejný koncový bod a privátne prefixy za ním. Neexistuje podporovaný spôsob, ako tomuto prostriedku dať význam „ktorékoľvek z týchto dvoch zariadení“.
Rovnaké zmätenie ide aj opačným smerom, kde sa dve verejné IP adresy Azure čítajú ako dôkaz, že existujú dve brány Azure.
Spočítajte objekty, potom tunely
Vezmite dve nezávisle prevádzkované lokálne zariadenia, každé s vlastnou verejnou adresou a prístupom k tým istým privátnym sieťam, plus jednu bránu Azure založenú na smerovaní v režime aktívny-aktívny. Brána Azure má dve aktívne inštancie s oddelenými verejnými IP adresami. Každé lokálne zariadenie sa pripája k obom inštanciám. To je úplná sieť a počet objektov z nej vyplýva, nie z diagramu.
Aritmetika je dosť krátka na to, aby sa vložila do návrhového dokumentu:
2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh
Jeden prostriedok pripojenia môže niesť viac ako jeden podkladový tunel, takže štyri tunely neznamenajú štyri brány virtuálnej siete. Dve verejné IP adresy Azure tiež nie sú tie isté objekty ako dve brány lokálnej siete, ktoré opisujú vzdialené pracovisko.
Čo pridáva aktívny-aktívny režim na strane Azure
Aktívny-aktívny režim mení bránu Azure z jednej aktívnej inštancie na dve, každú s vlastnou verejnou IP adresou, a práve to vôbec umožňuje úplnú sieť. Nezdvojnásobuje priepustnosť jedného toku. Neodstraňuje ani potrebu, aby lokálna strana podporovala viaccestné smerovanie s rovnakými nákladmi, ak obe zariadenia preposielajú súčasne. Pred zriadením čohokoľvek potvrďte režim brány, SKU a schopnosti vzdialeného zariadenia.
Brána v pasívnom pohotovostnom režime je úplne platný návrh; len dáva iný počet tunelov.
BGP sprístupňuje obe cesty
Pre návrh s viacerými zariadeniami obe lokálne zariadenia prevádzkujú BGP. Každému dajte jedinečnú adresu partnera BGP a inzerujte rovnaké zamýšľané privátne prefixy cez príslušné cesty. Privátne prefixy identifikujú chránené siete, zatiaľ čo verejné adresy identifikujú, kde sa končia šifrované nosné pripojenia. Zámena týchto dvoch vedie k návrhu, v ktorom sú všetky tunely aktívne a trasy nesprávne.
Naplánujte spätné smerovanie a akúkoľvek stavovú kontrolu, ktorá musí zniesť ktorúkoľvek z dvoch ciest. Zdravá relácia IKE na každom koncovom bode nedokazuje, že pracovná záťaž môže použiť každú inzerovanú trasu.
Výber podľa toku nie je združovanie šírky pásma
Azure vyberá cestu pre každý tok pomocou hashu cez adresy a porty toku. V ustálenom stave pakety daného toku TCP alebo UDP zvyčajne idú rovnakým tunelom a lokálna strana môže pre spätný smer zvoliť iný tunel. Preto dve zariadenia a štyri tunely zlepšujú dostupnosť, nie rýchlosť jedného prenosu. Keď predajná prezentácia sľubuje agregáciu, opisuje inú funkciu alebo nedorozumenie.
Testujte s paralelnými tokmi, ak chcete vidieť šírenie ciest, a s jediným tokom, ak chcete vidieť limit.
Akú redundanciu ste vlastne odstránili
Dve WAN adresy na jednom zariadení zlepšujú možnosti prístupovej linky, ale zdieľajú napájanie, softvér a poruchový stav tohto zariadenia. Nie sú to isté ako dve zariadenia a žiadna konfigurácia na strane Azure to nezmení. Namiesto odvodzovania redundancie z počtu adries postupujte podľa výrobcom podporovaného návrhu s dvoma WAN alebo clusterom. Potom to otestujte: odoberajte po jednej ceste a potvrďte zostávajúce trasy a skutočnú výmenu aplikácie v oboch smeroch.
Očakávajte oneskorenia detekcie a konvergencie a očakávajte, že niektoré existujúce relácie sa skončia.