Helyi alhálózat hozzáadása egy AWS VPN-hez: VGW vagy Transit Gateway

Egy meglévő Site-to-Site VPN a 10.60.0.0/16 tartományt viszi, ugyanazon helyi átjáró mögött új szolgáltatási hálózat jelenik meg 10.70.0.0/16-ként, és valaki azt kérdezi, kell-e proxy. Általában nem: egy irányított útvonal átviheti a prefixet, de csak akkor, ha három dolog összeillik, és hogy melyik három, az a már futtatott AWS-architektúrától függ. Egy virtuális privát átjárónak egy útvonaltábla-határa van; a transit gateway hozzáad egy másodikat. Helyes hirdetés és rossz tábla olyan munkamenetet ad, amely egészségesnek látszik, és semmit nem szállít.

Hirdessen olyan prefixet, amelyet az átjáró valóban ki tud szállítani

A helyi átjárónak az új hálózat felé vezető útvonalra van szüksége, mielőtt bármely hirdetésnek értelme lenne. A 10.70.0.0/16 BGP-n keresztüli hirdetése megmondja az AWS-nek, hova küldje az adott tartomány csomagjait; nem hozza létre azt a helyi továbbítási útvonalat, amely a tartományt a másik végén elérhetővé teszi. Erősítse meg, hogy az átjárónak van a prefixhez útvonala, amely a azt tartó eszközre mutat, és hogy az eszköz konfigurálva van ezekre a címekre válaszolni. Az exportszabály és az elfogadott prefixkorlátok a következő korlát, mert a munkamenet által kiszűrt prefix egyáltalán nem érkezik meg az AWS-hez.

Tartsa szándékosnak az összesítéseket és a pontosabb útvonalakat. A két irányból érkező átfedő útvonalak tervezési döntés, nem később felfedezendő részlet.

Első útvonal: a virtuális privát átjáró határa

Virtuális privát átjáró esetén az AWS VPN útvonalkezelési dokumentációja két elosztási módot ír le, a statikus útvonalakat és a BGP-hirdetéseket, és mindkettő azon alhálózati útvonaltáblától függ, amelyet az alkalmazás valóban használ. A propagáció kényelmes, ha az egész tartományt Ön irányítja, az explicit útvonal pedig könnyebben átgondolható, ha a célt a célpont mellett szeretné látni. Mindkét esetben ugyanaz az ellenőrzés: tartalmaz-e az adott alkalmazás-alhálózat táblája működő útvonalat a VPN célpontjához az új prefixhez, és nyer-e bármi pontosabbal szemben?

Egy egészséges BGP-munkamenet bizonyítja, hogy a csatorna létezik. Nem mond semmit arról, hogy egy adott alhálózati tábla átvette-e az útvonalat.

Második útvonal: a transit gateway hozzáad egy táblát

A transit gateway két részre bontja ezt az egy kérdést. A VPC-alhálózatnak el kell küldenie a célt a transit gateway csatlakozójára, majd a transit gateway útvonaltáblájának ki kell választania a VPN csatlakozóját ugyanahhoz a prefixhez. A hozzárendelési és propagációs döntések határozzák meg, mely csatlakoztatott hálózatok kapják meg az útvonalat, így egy prefixet a VPN helyesen hirdethet, és mégsem érkezik meg soha abba a VPC-be, amelynek táblája soha nem volt a megfelelő útvonaltáblához rendelve.

A gyakori hiba egy útvonal, amely az egyik táblában létezik, a másikban nem, miközben minden csapat meg van győződve arról, hogy a saját oldala helyes. Ha összehasonlítja a két architektúrát, ez a plusz határ a teljes különbség: több hely, ahol utánanézhet, és pontosabb ellenőrzés afölött, ki kapja meg az útvonalat.

Az útvonalak propagációja sem adja meg a prefixet minden csatlakozónak. Azokra a táblákra osztja el, amelyek fogadására konfigurálva vannak.

A visszaútvonal önálló szabályozási döntés

A beérkező forgalom csak a csere fele. Az új helyi hálózatnak visszaútvonalra van szüksége az AWS forrás-prefixekhez a megfelelő átjárón keresztül, és a két vég biztonsági szabályának engedélyeznie kell ezt a forrás-cél párt. Ha az alagút forgalomválasztókkal tárgyal védelmi tartományt, az új prefixnek azon belül kell lennie, különben a csomag eldobásra kerül, mielőtt bármely útvonaltáblát megnéznének.

A címátfedés a másik csapda. Az elkülönülő, egyértelműen birtokolt tartományok egyszerűen tartják ezt; az átfedő tartományok fordítást vagy újratervezést jelentenek, és egyik sem ugyanannak a receptnek a felcserélhető változata.

Teszteljen forrással az új hálózatban és céllal az alkalmazás-alhálózatban, majd ismételje meg a másik irányban. Az egyirányú teszt egyetlen irányt bizonyít.

Amikor a proxy valóban a jobb határ

A proxy akkor érdemli meg a helyét, ha a követelmény szűk szolgáltatási felület, ha az alkalmazás már ezt az architektúrát várja, vagy ha a hálózati útvonal nem tehető alkalmassá a prefix továbbítására olyan fordítás nélkül, amelyet nem szeretne. Nem tartalék megoldás egy olyan útvonaltábla-bejegyzéshez, amelyet senki nem ellenőrzött.

Ebben a sorrendben döntsön: helyi továbbítás, hirdetés, táblahatár, visszaútvonal-szabály. Javítsa ki az elsőt, amelyik elbukik, és csak utána kérdezze meg, hogy az irányított útvonal egyáltalán a helyes válasz-e.