AWS Client VPN vagy bastion egy peering VPC eléréséhez

Egyetlen Client VPN endpoint el tud érni egy VPC-t, amely peering kapcsolatban áll a hozzá tartozó VPC-vel, és ehhez nem kell bastion ahhoz, hogy ez legitim legyen. Az a döntés éri meg, hogy hol vált gazdát a forgalom: egy endpoint-útvonal, amely az association alhálózatban landol és átlép a peering kapcsolaton, vagy egy host a peerelt VPC-ben, amely lezárja a munkamenetet. Mindkét útvonal működik, és más helyen hibázik, tehát a döntés a tulajdonról és az auditról szól, nem arról, mit enged meg az AWS. Íme, hogyan választok köztük, és a négy bejegyzés, amely működőképessé teszi az útvonalazott utat.

Két út, egy endpoint, különböző tulajdonosok

Az útvonalazott úton az ügyfél forgalma eléri az endpointot, lefordítódik a Client VPN hálózati interfész címére az association alhálózatban, és elhagyja azt az alhálózatot az A-ból B-be vezető peering kapcsolaton. A VPC B nem zár le VPN munkamenetet; közönséges forgalmat lát a VPC A-ból, ezért a visszaútvonala a VPC A-ra mutat, nem az ügyfélkészletre.

A bastion úton az ügyfél először egy hostot ér el. Az A-ban lévő bastion továbbra is átengedi az utolsó ugrást a peering kapcsolaton, így megmarad a peering munka, és hozzáadódik egy munkamenet. A B-ben lévő bastionnak is kell útvonal az ügyféltől, és ha ez az útvonal ugyanaz az endpoint-útvonal, akkor az útvonalazott terv plusz egy ugrás. A bastion csak akkor vesz le munkát, ha már létezik, már jóváhagyott, és a mögötte lévő dolog munkamenet-határt igényel, nem hálózati határt.

Négy bejegyzés teszi működőképessé az útvonalazott utat

Az AWS ezt a forgatókönyvet a Client VPN how-it-works oldalon dokumentálja, és a gyakorlatban négy bejegyzésre szűkül, amelyeket két vagy három csapat birtokol. A tartományok szemléltetőek; a peerelt tartománynak egyedinek kell lennie, a visszatartománynak pedig illeszkednie kell a tervéhez.

Az útvonal és az engedély külön kontrollok. A helyes endpoint-útvonal megfelelő engedélyezési szabály nélkül semmit sem ad az ügyfélnek; egy olyan cél engedélyezési szabálya, amelyet az endpoint nem tud útvonalazni, fekete lyukat ad neki. Mindkettőnek ugyanazt a tartományt kell megneveznie.

Az endpoint-útvonal az endpoint saját VPC-jének egy alhálózatára mutat, soha nem a peering kapcsolatra. A VPC útvonaltáblák a peering kapcsolatra mutatnak, soha nem egy instance-re vagy interfészre. Egy érték átmásolása a kettő között panasz nélkül mentődik, és semmit nem útvonalaz.

Mivel az association alhálózat lefordítja az ügyfél forrását, a B-nek vissza kell útvonalaznia a VPC A-ba, nem az ügyfélkészletbe. Az ügyféltartomány átküldése a peering kapcsolaton szimmetrikusnak tűnik, átmegy a felülvizsgálaton, és csendben meghiúsul, mert a B soha nem lát ügyfél forrású csomagot.

Biztonsági csoportok és az engedély utolsó métere

Az útvonalazás beviszi a csomagokat a B-be; a B még mindig dönt. Egy azonos régióban lévő aktív peering kapcsolat esetén a B-ben lévő biztonsági csoport hivatkozhat a Client VPN associationre alkalmazott csoportra, ami szűken tartja a szabályt és túléli a címváltozásokat. Ahol a csoporthivatkozás nem járható, engedélyezze kifejezetten az association alhálózat tartományát ahelyett, hogy 0.0.0.0/0-ra szélesítené, ami egy útvonalazási hibát megmagyarázhatatlan időtúllépéssé változtat.

Ezután ellenőrizze, amit az útvonalazás soha nem érint: a hálózati ACL-eket mindkét alhálózaton, az alkalmazás engedélyezési listáját vagy a token közönségét, és a DNS-t. A peering nem másolja a privát hosztolt zónákat, ezért a laptop működő útvonalat tarthat egy olyan címre, amelyet nem tud feloldani, és a peering kapcsolat nem ad bizalmat a tanúsítványhoz. Irányítsa az endpointot egy olyan feloldóra, amely a B nevében válaszol, majd erősítse meg, hogy a privát név és a tanúsítvány megegyezik.

Mikor a bastion az őszinte válasz

Három kiváltót tartok a bastion szándékos választásához. A peerelt VPC olyan csapaté, amely nem ad hozzá visszaútvonalat a tartományához, vagy nem fogad el csoporthivatkozást. A hozzáférést munkamenetenként jóvá kell hagyni vagy rögzíteni kell, és az alkalmazás ezt nem tudja maga hordozni. Vagy az utolsó ugrásnak a B-n belül kell maradnia, mert a szolgáltatás csak ott oldódik fel, és a TLS identitása belső névhez van rögzítve.

Ezek egyike sem kerülőútja annak, hogy a peering nem tranzitív. A nem tranzitivitás korlátozza, mit tehetnek a B erőforrásai: nem használhatják az A-t tranzitként egy harmadik VPC felé, amellyel az A peeringben van. Ez soha nem jelentette azt, hogy egy VPN-felhasználó nem érhet el egy közvetlenül peerelt VPC-t, és az a bastion, amelyet e félreértés megkerülésére építettek, ok nélkül foltozandó host.

A fordított hiba idővel többe kerül: toljon át minden csapatot az egyetlen már létező bastionon, majd fedezze fel, hogy annak biztonsági csoportja, útvonaltáblája és foltozási ablaka a termelési függőség. Írja le, melyik kiváltót szolgálja a host, és vonja vissza, amikor a kiváltó eltűnik.

A Transit Gateway és több association megváltoztatja a számítást

Ha az endpointot közvetlenül egy Transit Gatewayhez csatolják alhálózat helyett, a modell megváltozik: az ügyfelek már nem fordulnak le interfészcímre egy association alhálózatban, és az átjáró útvonaltábláinak hordozniuk kell az ügyféltartományt plusz a peerelt VPC-hez vezető csatolást. Ez nagy léptékben tisztább, de a munka négy bejegyzésből az átjáró útvonaltábláiba költözik.

Több association megsokszorozza az ellenőrzéseket. Az endpoint-útvonal az endpointé, mégis minden association alhálózatnak valódi peering következő ugrással rendelkező útvonaltáblára van szüksége. Egy munkamenet sikerülhet az egyik associationön keresztül, miközben a másiknak nincs visszaútja, ezért tesztelje mindegyiket.

Ellenőrzési sorrend, amely gyorsan megtalálja a törést

Futtassa ezeket sorrendben; minden lépés átmehet, miközben a következő meghiúsul, és az ügyfél időtúllépése szinte soha nem mondja meg, melyik tört el.

1. Oldja fel az alkalmazás nevét az ügyfélből, és ellenőrizze, hogy a cím a peerelt tartományon belül van.
2. Csatlakozzon, majd olvassa el az endpoint kapcsolati naplóját arra az associationre, amely lezárta a munkamenetet.
3. Azon az association alhálózaton erősítse meg, hogy az útvonaltábla a peerelt tartományt aktív peering kapcsolatra mutatja.
4. A B erőforrás-alhálózatán erősítse meg az interfésztartomány visszabejegyzését és a megfelelő csoportszabályokat.
5. Teszteljen egy engedélyezett műveletet és egy erőforrást, amelynek elérhetetlennek kell maradnia; a második elkapja a hibakeresési maradványokat.
6. Bármilyen split-tunnel útvonalváltozás után csatlakozzon újra, mert egy futó alagút nem vesz fel új útvonalkészletet.

Két tünetet érdemes megjegyezni. A B-be válasz nélkül érkező SYN szinte mindig a hiányzó visszaútvonal. A befejeződő, majd alaphelyzetbe álló kapcsolat általában a csoport, az ACL vagy az alkalmazás. Egyik sem jelenik meg az endpoint naplójában okként, ezért tartsa a négy bejegyzést tulajdonossal mindegyik mellett.

Ha a három kiváltó egyike sem áll fenn, fejezze be az útvonalazott utat, és rögzítse azt a négy bejegyzést. Ha egy fennáll, tartsa a bastiont csak arra a határra, és hagyja az endpoint-útvonalat azoknak a szolgáltatásoknak, amelyek elé nem kell munkamenet.