Een Client VPN-eindpunt kan 'n VPC bereik wat met sy geassosieerde VPC gepeer is, en jy het nie 'n bastion nodig om dit wettig te maak nie. Die keuse wat die moeite werd is, is waar die verkeer van hande verwissel: 'n eindpuntroete wat in die assosiasiesubnet beland en die peeringverbinding kruis, of 'n gasheer in die gepeerde VPC wat die sessie beëindig. Beide weë werk en hulle faal op verskillende plekke, so die besluit gaan oor eienaarskap en oudit, nie oor wat AWS toelaat nie. Hier is hoe ek tussen hulle kies, en die vier inskrywings wat die geroteerde weg laat werk.

Twee weë, een eindpunt, verskillende eienaars

Op die geroteerde weg bereik die kliëntverkeer die eindpunt, word dit vertaal na die adres van die Client VPN-netwerkkoppelvlak in die assosiasiesubnet, en verlaat dit daardie subnet oor die A-na-B-peeringverbinding. VPC B beëindig geen VPN-sessie nie; dit sien gewone verkeer van VPC A, en daarom wys sy terugroete na VPC A, nie na die kliëntpoel nie.

Op die bastionweg bereik die kliënt eers 'n gasheer. 'n Bastion in A laat die laaste hop steeds oor die peeringverbinding kruis, so jy behou die peeringwerk en voeg 'n sessie by. 'n Bastion in B het steeds 'n pad van die kliënt nodig, en wanneer daardie pad dieselfde eindpuntroete is, het jy die geroteerde ontwerp plus 'n hop. Die bastion verwyder net werk wanneer dit reeds bestaan, reeds goedkeuring het, en die ding daar agter 'n sessiegrens eerder as 'n netwerkgrens nodig het.

Vier inskrywings laat die geroteerde weg werk

AWS dokumenteer hierdie scenario op die Client VPN how-it-works-bladsy, en in die praktyk kom dit neer op vier inskrywings wat deur twee of drie spanne besit word. Reekse is ter illustrasie; die gepeerde reeks moet uniek wees en die terugreeks moet by jou plan pas.

ControlWhat it must say
Endpoint route10.70.0.0/16 targets the association subnet
Authorization ruleThe approved group may reach 10.70.0.0/16
VPC A association-subnet table10.70.0.0/16 targets the peering connection
VPC B resource-subnet tableVPC A's range targets the same peering connection

Roete en toestemming is aparte kontroles. 'n Korrekte eindpuntroete sonder 'n passende magtigingsreël gee die kliënt niks; 'n magtigingsreël vir 'n bestemming wat die eindpunt nie kan roeteer nie, gee dit 'n swart gat. Beide moet dieselfde reeks noem.

Die eindpuntroete wys na 'n subnet in die eindpunt se eie VPC, nooit na die peeringverbinding nie. Die VPC-roetetabelle wys na die peeringverbinding, nooit na 'n instansie of 'n koppelvlak nie. Om 'n waarde tussen die twee te kopieer, stoor sonder klagte en roeteer niks.

Omdat die assosiasiesubnet die kliëntbron vertaal, moet B terugroeteer na VPC A, nie na die kliëntpoel nie. Om die kliëntreeks oor die peeringverbinding te stuur, lyk simmetries, slaag die hersiening en faal stil, want B sien nooit 'n pakket met 'n kliëntbron nie.

Sekuriteitsgroepe en die laaste meter toestemming

Roetering kry pakkette in B; B besluit steeds. Vir 'n aktiewe peeringverbinding in dieselfde streek kan 'n sekuriteitsgroep in B verwys na die groep wat op die Client VPN-assosiasie toegepas is, wat die reël nou hou en adresveranderinge oorleef. Waar 'n groepsverwysing nie werkbaar is nie, laat die assosiasiesubnetreeks eksplisiet toe eerder as om na 0.0.0.0/0 te verbreed, wat 'n roeteringsfout in 'n onverklaarbare tydsverloop omskep.

Kontroleer dan wat roetering nooit raak nie: netwerk-ACL's op beide subnette, die toepassing se toelaatlys of token-gehoor, en DNS. Peering kopieer nie private gehoste sones nie, so die skootrekenaar kan 'n werkende roete na 'n adres hou wat hy nie kan oplos nie, en 'n peeringverbinding voeg geen vertroue aan 'n sertifikaat toe nie. Wys die eindpunt na 'n oplosser wat vir B antwoord, en bevestig dan dat die private naam en die sertifikaat ooreenstem.

Wanneer die bastion die eerlike antwoord is

Ek hou drie snellers vir die doelbewuste keuse van 'n bastion. Die gepeerde VPC behoort aan 'n span wat nie 'n terugroete vir jou reeks sal byvoeg nie of nie 'n groepsverwysing sal aanvaar nie. Toegang moet per sessie goedgekeur of aangeteken word en die toepassing kan dit nie self dra nie. Of die laaste hop moet binne B bly omdat die diens net daar oplos en sy TLS-identiteit aan 'n interne naam vasgepen is.

Niks daarvan is 'n ompad vir die feit dat peering nie-transitief is nie. Nie-transitiwiteit beperk wat hulpbronne in B mag doen: hulle kan nie A as deurgang na 'n derde VPC gebruik waarmee A gepeer is nie. Dit het nooit beteken dat 'n VPN-gebruiker nie 'n direk gepeerde VPC kan bereik nie, en 'n bastion wat gebou is om daardie verkeerde lees te omseil, is 'n gasheer om sonder rede te pleister.

Die omgekeerde fout kos oor tyd meer: dwing elke span deur die een bastion wat reeds bestaan, en ontdek dan dat sy sekuriteitsgroep, roetetabel en pleistervenster die produksie-afhanklikheid is. Skryf neer watter sneller die gasheer dien, en onttrek hom wanneer die sneller verdwyn.

Transit Gateway en verskeie assosiasies verander die rekenkunde

As die eindpunt direk aan 'n Transit Gateway gekoppel is eerder as aan 'n subnet, verander die model: kliënte word nie meer na 'n koppelvlakadres in 'n assosiasiesubnet vertaal nie, en die gateway-roetetabelle moet die kliëntreeks plus die koppeling na die gepeerde VPC dra. Dit is skoner op skaal, maar die werk skuif van vier inskrywings na gateway-roetetabelle.

Verskeie assosiasies vermenigvuldig die kontroles. Die eindpuntroete behoort aan die eindpunt, maar elke assosiasiesubnet het 'n roetetabel met 'n werklike peering-volgende hop nodig. 'n Sessie kan deur een assosiasie slaag terwyl 'n ander geen terugpad het nie, so toets elkeen.

Verifikasievolgorde wat die breek vinnig vind

Voer hierdie in volgorde uit; elke stap kan slaag terwyl die volgende faal, en 'n kliënt-tydsverloop sê byna nooit watter een gebreek het.

  1. Los die toepassingsnaam vanaf die kliënt op en kontroleer dat die adres binne die gepeerde reeks is.
  2. Verbind, en lees dan die eindpuntverbindingslog vir die assosiasie wat die sessie beëindig het.
  3. Op daardie assosiasiesubnet, bevestig dat die roetetabel die gepeerde reeks na 'n aktiewe peeringverbinding wys.
  4. Op die hulpbron-subnet in B, bevestig 'n teruginskrywing vir die koppelvlakreeks en passende groepreëls.
  5. Toets een toegelate bewerking en een hulpbron wat onbereikbaar moet bly; die tweede vang ontfoutingsreste.
  6. Herverbind na enige verandering aan die split-tunnel-roete, want 'n lopende tonnel sal nie 'n nuwe roetestel optel nie.

Twee simptome is die moeite werd om te memoriseer. 'n SYN wat B bereik sonder antwoord is byna altyd die ontbrekende terugroete. 'n Verbinding wat voltooi en dan terugstel, is gewoonlik die groep, die ACL of die toepassing. Nie een verskyn in die eindpuntlog as 'n oorsaak nie, so hou die vier inskrywings met 'n eienaar langs elkeen.

As nie een van die drie snellers geld nie, voltooi die geroteerde weg en teken daardie vier inskrywings aan. As een geld, hou die bastion net vir daardie grens en laat die eindpuntroete vir dienste wat nie 'n sessie voor hulle nodig het nie.

Verwante artikels