Wêrom EC2 jo AWS Client VPN-laptop net berikke kin
Client VPN oerset IPv4-klantboarnen nei de interface fan it einpunt. Dêrom wurket it antwurd, mar in nije ferbining fanôf EC2 net.
In laptop dy't fia AWS Client VPN ferbûn is, berikt in EC2-applikaasje sûnder swierrichheden. Dan besykje jo it omkearde, fanôf EC2 nei it adres dat de klant krigen hat, en de ferbining hinget of wurdt wegere. Dy asymmetry is selden in ûntbrekkende befeiligingsgroepregel. Op in Client VPN-einpunt dat oan VPC-subnetten keppele is, oerset AWS IPv4-klantboarnen nei de netwurkinterface fan it einpunt, sadat der gjin ynkommend VPC-adres is dat jo laptop fertsjintwurdiget.
Begjin mei wat de opname sjen lit
Meitsje in opname op de EC2-host wylst de klant ferbynt, en lês it boarneadres dat de applikaasje eins sjocht. As it de einpuntinterface oan de VPC-kant is en net in adres út de klantpool, is de oersetting befêstige foardat jo ien regel feroarje.
De klantpool is in tawizingsberik, gjin subnet mei in weromrûte. It is dat ûnderskie dêr't de measte fan dizze ûndersiken ferkeard gean.
De oersetting dy't de asymmetry ferklearret
Trije streamen wurde mei elkoar betize, en mar ien fan har is dejinge dy't minsken testen.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
De beskriuwing fan de Client VPN-komponinten seit dúdlik dat IPv4-klantboarnen nei de einpuntinterface oerset wurde, wat genôch is om te sjen wêrom't de middelste rigel neat hat om mei te ferliken.
In nije ferbining hat in rûte, in adresoplossingsstap en in autorisaasjebeslissing nedich. Oersetstatus fan in oar syn sesje leveret net ien fan de trije.
Wêrom't in antwurd gjin nije ferbining is
In TCP-antwurd wurdt tsjin in besteande yngong ferlike, dêrom wurket de weromweis sûnder hokker ynkommende regel dan ek. In nij SYN fan de EC2-host hat gjin yngong om tsjin te ferliken, dus it wurdt in gewoane útgeande poging nei in bestimming dêr't de VPC net wit hoe't er dêr komme moat.
Dêrom is it ek misliedend om dit te beskriuwen as ferkear dat mar ien kant út giet. Weromferkear streamt trochgeand yn dizze sesjes. It ûntbrekkende part is it begjin.
Wat in sesje dy't wurkje moat noch altyd brekt
Befeiligingsgroepen, netwurk-ACL's en de eigen firewall fan de laptop binne allegear fan belang foar de ferbiningen dy't slagje moatte. In mislearre ping seit it minst, om't ICMP-belied faak apart is fan it TCP-belied dat jo oanbelanget.
Skriuw dy regels tsjin de oersette boarne, net it klantadres. Regels dy't fêstsette binne oan it adres dat nea op it net ferskynt, binne de meast foarkommende selsfertrochde flater yn dit ûntwerp.
Wannear't de VPC echt it petear begjinne moat
As in tsjinst in wurkstasjon berjochtsje moat, kear de rjochting om en lit de klant in oanhâldend útgeand kanaal hâlde dêr't de tsjinst op antwurdet. As in hiel ôflizzend netwurk fan de VPC ôf berikber wêze moat, kies dan in arsjitektuer dy't syn prefiksen en tagongbelied publisearret ynstee fan oan te nimmen dat Client VPN dat al docht. Tagong fan klant nei klant is in tredde, smeller gefal mei syn eigen rûte- en autorisaasje-objekten. Gjint fan dizze is in kontrôlefakje op it besteande einpunt.
Hâld ek it berik fan de IPv4-ferklearring earlik. De hjoeddeiske AWS-dokumintaasje skiedt IPv6, dêr't dy oersetting net jildt, en oare oanslútmodellen dy't oars routearje.
Test yn trije beneamde stappen: de klant iepenet in tastiene sesje, de VPC-tsjinst antwurdet op dy sesje, en in VPC-host iepenet in nije sesje nei de klant. Dat de earste twa slagje wylst de tredde mislearret, is de ferwachte foarm fan dit ûntwerp, gjin defekt om mei firewallregels efternei te gean.