AWS Client VPN of een bastion om een peering-VPC te bereiken

Eén Client VPN-endpoint kan een VPC bereiken die in peering is met de bijbehorende VPC, en je hebt geen bastion nodig om dat legitiem te maken. De keuze die de moeite waard is, is waar het verkeer van eigenaar wisselt: een endpoint-route die landt in het associatiesubnet en de peering-verbinding oversteekt, of een host in de peering-VPC die de sessie beëindigt. Beide paden werken en ze falen op verschillende plekken, dus de beslissing gaat over eigenaarschap en audit, niet over wat AWS toestaat. Hier is hoe ik tussen beide kies, en de vier vermeldingen die het gerouteerde pad laten werken.

Twee paden, één endpoint, verschillende eigenaren

Op het gerouteerde pad bereikt het clientverkeer het endpoint, wordt het vertaald naar het adres van de Client VPN-netwerkinterface in het associatiesubnet en verlaat het dat subnet via de peering-verbinding van A naar B. VPC B beëindigt geen VPN-sessie; het ziet gewoon verkeer uit VPC A, daarom wijst de retourroute naar VPC A en niet naar de clientpool.

Op het bastionpad bereikt de client eerst een host. Een bastion in A laat de laatste hop nog steeds de peering-verbinding oversteken, dus je behoudt het peering-werk en voegt een sessie toe. Een bastion in B heeft ook een pad van de client nodig, en wanneer dat pad dezelfde endpoint-route is, heb je het gerouteerde ontwerp plus één hop. Het bastion haalt alleen werk weg als het al bestaat, al is goedgekeurd, en het ding erachter een sessiegrens nodig heeft in plaats van een netwerkgrens.

Vier vermeldingen laten het gerouteerde pad werken

AWS documenteert dit scenario op de Client VPN how-it-works-pagina, en in de praktijk komt het neer op vier vermeldingen die twee of drie teams bezitten. De bereiken zijn illustratief; het peering-bereik moet uniek zijn en het retourbereik moet bij je plan passen.

Route en toestemming zijn aparte controles. Een correcte endpoint-route zonder bijpassende autorisatieregel geeft de client niets; een autorisatieregel voor een bestemming die het endpoint niet kan routeren geeft hem een zwart gat. Beide moeten hetzelfde bereik noemen.

De endpoint-route wijst naar een subnet in de eigen VPC van het endpoint, nooit naar de peering-verbinding. De VPC-routetabellen wijzen naar de peering-verbinding, nooit naar een instance of interface. Een waarde tussen beide kopiëren wordt zonder klacht opgeslagen en routeert niets.

Omdat het associatiesubnet de clientbron vertaalt, moet B terug routeren naar VPC A, niet naar de clientpool. Het clientbereik over de peering-verbinding sturen lijkt symmetrisch, doorstaat de review en faalt stil omdat B nooit een pakket met een clientbron ziet.

Beveiligingsgroepen en de laatste meter toestemming

Routering brengt pakketten in B; B beslist nog steeds. Voor een actieve peering-verbinding in dezelfde regio kan een beveiligingsgroep in B verwijzen naar de groep die op de Client VPN-associatie is toegepast, wat de regel smal houdt en adreswijzigingen overleeft. Waar een groepsreferentie niet haalbaar is, sta het bereik van het associatiesubnet expliciet toe in plaats van te verbreden naar 0.0.0.0/0, wat een routeringsfout verandert in een onverklaarde time-out.

Controleer daarna wat routering nooit aanraakt: netwerk-ACL's op beide subnetten, de allowlist of token-doelgroep van de applicatie, en DNS. Peering kopieert geen privé-gehoste zones, dus de laptop kan een werkende route naar een adres houden dat hij niet kan oplossen, en een peering-verbinding voegt geen vertrouwen toe aan een certificaat. Wijs het endpoint naar een resolver die voor B antwoordt en bevestig dan dat de privénaam en het certificaat overeenkomen.

Wanneer het bastion het eerlijke antwoord is

Ik houd drie triggers aan voor een bewuste keuze voor een bastion. De peering-VPC is van een team dat geen retourroute voor jouw bereik toevoegt of geen groepsreferentie accepteert. Toegang moet per sessie worden goedgekeurd of vastgelegd en de applicatie kan dat niet zelf dragen. Of de laatste hop moet binnen B blijven omdat de dienst alleen daar wordt opgelost en de TLS-identiteit aan een interne naam is vastgezet.

Niets daarvan omzeilt het feit dat peering niet transitief is. Niet-transitiviteit beperkt wat resources in B mogen doen: ze kunnen A niet als transit gebruiken naar een derde VPC waarmee A in peering is. Het heeft nooit betekend dat een VPN-gebruiker een direct gepeerde VPC niet kan bereiken, en een bastion dat is gebouwd om die verkeerde lezing te omzeilen is een host die zonder reden wordt gepatcht.

De omgekeerde fout kost op den duur meer: duw elk team door het ene bastion dat al bestaat, en ontdek dan dat de beveiligingsgroep, routetabel en het patchvenster de productieafhankelijkheid zijn. Schrijf op welke trigger de host dient, en haal hem uit gebruik wanneer de trigger verdwijnt.

Transit Gateway en meerdere associaties veranderen de rekensom

Als het endpoint rechtstreeks aan een Transit Gateway is gekoppeld in plaats van aan een subnet, verandert het model: clients worden niet meer vertaald naar een interfaceadres in een associatiesubnet, en de gateway-routetabellen moeten het clientbereik plus de koppeling naar de peering-VPC dragen. Dat is schoner op schaal, maar het werk verhuist van vier vermeldingen naar gateway-routetabellen.

Meerdere associaties vermenigvuldigen de controles. De endpoint-route is van het endpoint, maar elk associatiesubnet heeft een routetabel nodig met een echte peering-next-hop. Een sessie kan slagen via de ene associatie terwijl een andere geen retourpad heeft, dus test elke.

Verificatievolgorde die de breuk snel vindt

Voer deze in volgorde uit; elke stap kan slagen terwijl de volgende faalt, en een client-time-out zegt bijna nooit welke brak.

1. Los de applicatienaam op vanaf de client en controleer dat het adres binnen het peering-bereik ligt.
2. Maak verbinding en lees daarna het verbindingslog van het endpoint voor de associatie die de sessie beëindigde.
3. Bevestig op dat associatiesubnet dat de routetabel het peering-bereik naar een actieve peering-verbinding wijst.
4. Bevestig op het resourcesubnet in B een retourvermelding voor het interfacebereik en overeenkomende groepsregels.
5. Test één toegestane bewerking en één resource die onbereikbaar moet blijven; de tweede vangt resten van debuggen.
6. Maak opnieuw verbinding na elke wijziging van de split-tunnel-route, omdat een lopende tunnel geen nieuwe routeset opneemt.

Twee symptomen zijn het onthouden waard. Een SYN die B zonder antwoord bereikt, is bijna altijd de ontbrekende retourroute. Een verbinding die voltooit en dan wordt gereset, is meestal de groep, de ACL of de applicatie. Geen van beide verschijnt in het endpoint-log als oorzaak, dus houd de vier vermeldingen met een eigenaar naast elk.

Als geen van de drie triggers geldt, rond het gerouteerde pad af en leg die vier vermeldingen vast. Als er één geldt, houd het bastion alleen voor die grens en laat de endpoint-route voor diensten die geen sessie ervoor nodig hebben.