AWS Client VPN vagy Site-to-Site: ellenőrizze, ki nyitja a kapcsolatot

Négy ellenőrzés dönt erről, és egyik sem a protokoll neve. Ki nyitja a kapcsolatot, mit hitelesít az AWS, hogyan kapcsolódik a kapcsolat a hálózatához, és milyen forgalomirányítás és szabályzat jár vele. Válaszoljon ezekre sorrendben, és a termékválasztás általában magától megszületik; válaszoljon rájuk, miután már megvásárolt egy tervet, és végül egy olyan alagutat véd, amely a probléma rossz felét oldja meg. A négy közül egyik sem kéri, hogy rejtjelezést válasszon, ezért a protokollal kezdődő terv általában annak a jele, hogy a követelményeket soha nem írták le.

Minden ellenőrzést a tényleges végpontra, ügyfélre és arra a címcsaládra vonatkoztatva végezzen el, amelyet használni kíván, ne a kategóriára. A felügyelt VPN-termékek különböznek azoktól az OpenVPN- és IPsec-építőelemektől, amelyekhez hasonlítanak.

Először, ki nyitja a kapcsolatot

Ha az, aminek hozzáférésre van szüksége, laptop, telefon vagy egyetlen rendszergazda munkaállomása, a kapcsolat távoli eszközön indul, és a terv távoli ügyfélhozzáférés. Ha az, aminek hozzáférésre van szüksége, egy útválasztó mögötti gépekkel teli fióktelep, a kapcsolat azon az útválasztón indul, és a terv átjáró-átjáró közötti kapcsolat. Ez az az ellenőrzés, amely a legtöbb esetet eldönti, és ezt szokták kihagyni, amikor egy szállítói előadás már a rejtjelezés köré keretezte a beszélgetést.

Álljon meg itt, ha nem tudja megnevezni azt az összetevőt, amely kezdeményez. Az a terv, amely egyetlen alagúttal próbálja kiszolgálni mindkét esetet, általában egy átjárónak álcázott ügyfélmunkamenettel végződik.

Kérdésként másodszor: mit hitelesít az AWS

A Client VPN esetében az AWS a beállított ügyfél- vagy felhasználói identitást hitelesíti: tanúsítványokat, egy címtárat vagy összevont identitást, a beállítástól függően. A Site-to-Site VPN esetében az AWS az átjáró partneridentitását hitelesíti. Ez a különbség nem kozmetikai. Az egyik modell felhasználók hozzáadásával és hitelesítő adataik visszavonásával skálázódik; a másik azzal, hogy megbízik mindabban, ami egyetlen átjáró mögött áll.

Az átjáró hitelesítése nem hitelesíti a mögötte lévő minden munkatársat vagy alkalmazást, ezért tartsa meg az alkalmazásidentitásokat és az erőforrás szintű hozzáférést akkor is, amikor maga az alagút megbízható. Egy olyan fióktelepet, amelynek útválasztója érvényes partneridentitással rendelkezik, nem szabad automatikusan úgy olvasni, mintha az épület minden íróasztala jogosult lenne.

Harmadszor, hogyan kapcsolódik a kapcsolat

A Client VPN VPC-alhálózati társításokon vagy támogatott közvetlen Transit Gateway-csatlakozáson keresztül kapcsolódik. A Site-to-Site VPN egy AWS VPN-célhoz kapcsolódik, jellemzően virtuális magánátjáróhoz vagy Transit Gateway-hez. A Client VPN architektúraútmutató dokumentálja a Transit Gateway lehetőségét, és annak léte nem változtat egy laptop-munkamenetet fióktelepi átjáróvá, és nem távolítja el a fent leírt ügyfél-hitelesítést és -jogosultságkezelést.

Ellenőrizze, hogy a fiókja és a régiója valójában melyik csatlakozást támogatja, mielőtt útvonalakat tervezne köré, majd ellenőrizze, kié az a csatlakozás. Az a lehetőség, amely szerepel a dokumentációban, de olyan hálózaton ül, amelyet nem tud beállítani, nem lehetőség.

Negyedszer, milyen forgalomirányítás és szabályzat jár vele

A Client VPN ügyfélkapcsolat-kezelést és engedélyezési szabályokat hoz az Ön által engedélyezett célhálózatokhoz. Egy csatlakozott felhasználónak továbbra is szüksége van a tervezett végponti útvonalra, az azt engedélyező szabályra és arra a hozzáférésre, amelyet maga az erőforrás megkövetel. A Site-to-Site VPN az ügyfélátjáró által képviselt hálózatok között irányít forgalmat, a tervtől függően támogatott statikus útvonalakkal vagy BGP-vel, így a fióktelepi útválasztó mögötti egyes gépeknek nem kell külön ügyfélbejelentkezniük.

Ne következtessen nem támogatott viselkedésre a kategóriából egyik irányban sem. A távoli hozzáférésű VPN-ek nem képtelenek általánosságban visszforgalmat szállítani vagy átjárós elrendezéseket támogatni, és az IPsec-et nem blokkolja automatikusan a NAT — az AWS dokumentálja a NAT-átjárást és az ügyfélátjáró követelményeit, és a valódi korlát a támogatott átjárókonfiguráció. Ellenőrizze a végpontja korlátait, mielőtt ügyfelek felé indított kapcsolatokat követelne meg, vagy LAN-t továbbítana egy munkamenet mögül. Ugyanez az óvatosság érvényes a címcsaládokra: az IPv4 felett működő végpont nem jelent IPv6-útvonalat, ezért erősítse meg azt a családot, amelyről az ügyfele vagy átjárója valójában tárgyalni fog.

A Site-to-Site VPN kapcsolatonként két alagutat ad, és ez a redundancia tervezési feladat, nem pedig olyan funkció, amelyet feltételezni lehet. Az ügyfélátjáró működtetését, az útvonal-átkapcsolást és a tesztlefedettséget mind meg kell tervezni; egy laptop-munkamenet összehasonlítása egy absztrakt VPN-kiszolgálóval semmit sem bizonyít egyikről sem.

Ahol a két terv találkozik

A szolgáltatások nem zárják ki egymást, és a szokásos termelési forma mindkettőt használja: a munkatársak Client VPN-en, a fióktelepi hálózatok Site-to-Site-on, kifejezett útvonalakkal és hozzáférési szabályzattal azok között a célok között, amelyeknek beszélniük kell. A táblázat a négy ellenőrzés összefoglalója, nem pedig az elvégzésük helyettese.

Egy dolgot egyik termék sem helyettesít: a TLS-t egy olyan alkalmazás felé, amelynek titkosítási követelménye túlmutat a VPN-végponton. Ha a megfelelőségi hatóköre az alkalmazásnál végződik, az alagút szállítás, a tanúsítvány pedig továbbra is az ellenőrzés.

Írja le a négy választ a tervátvizsgálás előtt, mindegyiket egy sorban. Amikor kettő ellentmond egymásnak — mondjuk egy felhasználó által hitelesített ügyfélterv és egy fióktelep méretű forgalomirányítási igény —, az az ellentmondás a megállapítás, és olcsóbb most látni, mint az átállás idején.