AWS Client VPN of in bastion om in pearde VPC te berikken
Beide paden wurkje, mar se brekke op ferskillende plakken. Ferlykje endpoint-rûtes, weromrouting en de trije gefallen wêr't in bastion de earlike grins is.
Ien Client VPN-endpoint kin in VPC berikke dy't peard is mei syn byhearrende VPC, en jo hawwe gjin bastion nedich om dat legit te meitsjen. De kar dy't de muoite wurdich is, is wêr't it ferkear fan hân feroaret: in endpoint-rûte dy't yn it assosjaasje-subnet lânet en de peering-ferbining oerstekt, of in host yn 'e pearde VPC dy't de sesje einiget. Beide paden wurkje en se mislearje op ferskillende plakken, dus de beslissing giet oer eigendom en audyt, net oer wat AWS tastiet. Hjir is hoe't ik tusken harren kies, en de fjouwer yngongen dy't it rûtearre paad wurkje litte.
Twa paden, ien endpoint, ferskillende eigners
Op it rûtearre paad berikt it kliïntferkear it endpoint, wurdt it oerset nei it adres fan 'e Client VPN-netwurkinterface yn it assosjaasje-subnet, en ferlit it dat subnet oer de peering-ferbining fan A nei B. VPC B einiget gjin VPN-sesje; it sjocht gewoan ferkear fan VPC A, dêrom wiist syn weromrûte nei VPC A, net nei de kliïntpool.
Op it bastionpaad berikt de kliïnt earst in host. In bastion yn A lit de lêste hop noch altyd de peering-ferbining oerstekke, dus jo hâlde it peering-wurk en foegje in sesje ta. In bastion yn B hat ek in paad fan 'e kliïnt nedich, en as dat paad deselde endpoint-rûte is, hawwe jo it rûtearre ûntwerp plus in hop. It bastion hellet allinnich wurk fuort as it al bestiet, al goedkard is, en it ding derachter in sesjegrins nedich hat yn stee fan in netwurkgrins.
Fjouwer yngongen litte it rûtearre paad wurkje
AWS dokumintearret dit senario op 'e Client VPN how-it-works-side, en yn 'e praktyk komt it del op fjouwer yngongen dy't twa of trije teams hawwe. De berikten binne yllustratyf; it pearde berik moat unyk wêze en it weromberik moat by jo plan passe.
| Control | What it must say |
|---|---|
| Endpoint route | 10.70.0.0/16 targets the association subnet |
| Authorization rule | The approved group may reach 10.70.0.0/16 |
| VPC A association-subnet table | 10.70.0.0/16 targets the peering connection |
| VPC B resource-subnet table | VPC A's range targets the same peering connection |
Rûte en tastimming binne aparte kontrôles. In krekte endpoint-rûte sûnder byhearrende autorisaasjeregel jout de kliïnt neat; in autorisaasjeregel foar in bestimming dy't it endpoint net rûtearje kin, jout it in swart gat. Beide moatte itselde berik neame.
De endpoint-rûte wiist nei in subnet yn 'e eigen VPC fan it endpoint, nea nei de peering-ferbining. De VPC-rûtetabellen wize nei de peering-ferbining, nea nei in instance of in interface. In wearde tusken beide kopiearje wurdt sûnder klacht bewarre en rûtearret neat.
Om't it assosjaasje-subnet de kliïntboarne oerset, moat B werom rûtearje nei VPC A, net nei de kliïntpool. It kliïntberik oer de peering-ferbining stjoere liket symmetrysk, komt troch de beoardieling en mislearret stil, om't B nea in pakket mei in kliïntboarne sjocht.
Feiligensgroepen en de lêste meter tastimming
Routing krijt pakketten yn B; B beslist noch. Foar in aktive peering-ferbining yn deselde regio kin in feiligensgroep yn B ferwize nei de groep dy't op 'e Client VPN-assosjaasje tapast is, wat de regel smel hâldt en adresferoarings oerlibbet. Wêr't in groepferwizing net mooglik is, tastean it berik fan it assosjaasje-subnet eksplisyt yn stee fan út te wreidzjen nei 0.0.0.0/0, wat in routingflater yn in ûnferklearre timeout feroaret.
Kontrolearje dan wat routing nea oanrekket: netwurk-ACL's op beide subnets, de allow-list fan 'e applikaasje of it publyk fan it token, en DNS. Peering kopiearret gjin privee hostede sônes, dus de laptop kin in wurkjende rûte hâlde nei in adres dat er net oplosse kin, en in peering-ferbining foeget gjin fertrouwen ta oan in sertifikaat. Wys it endpoint nei in resolver dy't foar B antwurdet, en befêstigje dan dat de privee namme en it sertifikaat oerienkomme.
Wannear't it bastion it earlike antwurd is
Ik hâld trije triggers foar it mei opsetsin kiezen fan in bastion. De pearde VPC is fan in team dat gjin weromrûte foar jo berik tafoegje sil of gjin groepferwizing akseptearje sil. Tagong moat per sesje goedkard of fêstlein wurde en de applikaasje kin dat net sels drage. Of de lêste hop moat binnen B bliuwe om't de tsjinst allinnich dêr oplost en syn TLS-identiteit oan in ynterne namme fêstset is.
Neat fan dit is in omwei om it feit dat peering net transityf is. Net-transitiviteit beheint wat boarnen yn B dwaan meie: se kinne A net as transit brûke nei in tredde VPC dêr't A mei peard is. It hat nea betsjut dat in VPN-brûker in direkt pearde VPC net berikke kin, en in bastion dat boud is om dy ferkearde lêzing te omgean is in host om sûnder reden te patchen.
De omkearde flater kostet oer tiid mear: triuw elk team troch it iene bastion dat al bestiet, en ûntdek dan dat syn feiligensgroep, rûtetabel en patchfinster de produksje-ôfhinklikens binne. Skriuw op hokker trigger de host tsjinnet, en nim him út tsjinst as de trigger fuort is.
Transit Gateway en ferskate assosjaasjes feroarje de rekken
As it endpoint direkt oan in Transit Gateway ferbûn is yn stee fan oan in subnet, feroaret it model: kliïnten wurde net mear oerset nei in interface-adres yn in assosjaasje-subnet, en de gateway-rûtetabellen moatte it kliïntberik plus de oansluting drage dy't nei de pearde VPC liedt. Dat is skjinner op skaal, mar it wurk ferpleatst fan fjouwer yngongen nei gateway-rûtetabellen.
Ferskate assosjaasjes fermannichfâldigje de kontrôles. De endpoint-rûte is fan it endpoint, dochs hat elk assosjaasje-subnet in rûtetabel mei in echte peering-folgjende hop nedich. In sesje kin troch ien assosjaasje slagje wylst in oare gjin werompaad hat, dus test elke.
Kontrôlefolchoarder dy't it brek fluch fynt
Fier dizze yn folchoarder út; elke stap kin slagje wylst de folgjende mislearret, en in kliïnt-timeout seit hast nea hokker bruts.
- Los de applikaasjenamme fan 'e kliïnt op en kontrolearje dat it adres binnen it pearde berik leit.
- Ferbyn, en lês dan it endpoint-ferbiningslog foar de assosjaasje dy't de sesje einige.
- Op dat assosjaasje-subnet befêstigje dat de rûtetabel it pearde berik nei in aktive peering-ferbining wiist.
- Op it boarnesubnet yn B befêstigje in weromyngong foar it interface-berik en byhearrende groepsregels.
- Test ien tastiene operaasje en ien boarne dy't ûnberikber bliuwe moat; de twadde fangt restanten fan debugging.
- Ferbyn opnij nei elke split-tunnel-rûteferoaring, om't in rinnende tunnel gjin nije rûteset opnimt.
Twa symptomen binne it ûnthâlden wurdich. In SYN dy't B berikt sûnder antwurd is hast altyd de miste weromrûte. In ferbining dy't foltôget en dan weromset wurdt is meastentiids de groep, de ACL of de applikaasje. Gjin fan beide ferskynt yn it endpoint-log as oarsaak, dus hâld de fjouwer yngongen mei in eigner njonken elk.
As gjin fan 'e trije triggers jildt, meitsje it rûtearre paad ôf en registrearje dy fjouwer yngongen. As ien jildt, hâld it bastion allinnich foar dy grins en lit de endpoint-rûte foar tsjinsten dy't gjin sesje foar har nedich hawwe.