AWS Client VPN vai bastion peeratun VPC:n saavuttamiseen

Yksi Client VPN -endpoint voi tavoittaa VPC:n, joka on peer-yhteydessä sen liitettyyn VPC:hen, eikä sinun tarvitse tehdä siitä laillista bastionin avulla. Valinta, joka kannattaa tehdä, on se, missä liikenne vaihtaa omistajaa: endpoint-reitti, joka laskeutuu liitoksen aliverkkoon ja ylittää peering-yhteyden, vai peering-VPC:ssä oleva isäntä, joka päättää istunnon. Molemmat polut toimivat ja ne epäonnistuvat eri kohdissa, joten päätös koskee omistajuutta ja auditointia, ei sitä mitä AWS sallii. Näin valitsen niiden välillä, ja ne neljä merkintää, jotka saavat reititetyn polun toimimaan.

Kaksi polkua, yksi endpoint, eri omistajat

Reititetyllä polulla asiakkaan liikenne saapuu endpointille, käännetään Client VPN -verkkorajapinnan osoitteeksi liitoksen aliverkossa ja poistuu siitä aliverkosta A:sta B:hen kulkevan peering-yhteyden kautta. VPC B ei päätä yhtään VPN-istuntoa; se näkee tavallista liikennettä VPC:stä A, minkä vuoksi sen paluureitti osoittaa VPC:hen A eikä asiakaspooliin.

Bastion-polkua pitkin asiakas saavuttaa ensin isännän. Bastion A:ssa jättää viimeisen hypyn ylittämään peering-yhteyden, joten säilytät peering-työn ja lisäät istunnon. Bastion B:ssä tarvitsee myös polun asiakkaasta, ja kun se polku on sama endpoint-reitti, sinulla on reititetty suunnitelma plus yksi hyppy. Bastion poistaa työtä vain silloin, kun se on jo olemassa, jo hyväksytty, ja sen takana oleva asia tarvitsee istuntorajan eikä verkkorajaa.

Neljä merkintää saavat reititetyn polun toimimaan

AWS dokumentoi tämän skenaarion Client VPN how-it-works -sivulla, ja käytännössä se tiivistyy neljään merkintään, jotka omistaa kaksi tai kolme tiimiä. Alueet ovat havainnollisia; peering-alueen on oltava yksilöllinen ja paluualueen on vastattava suunnitelmaasi.

Reitti ja lupa ovat erillisiä kontrolleja. Oikea endpoint-reitti ilman vastaavaa valtuutussääntöä ei anna asiakkaalle mitään; valtuutussääntö kohteelle, jota endpoint ei voi reitittää, antaa sille mustan aukon. Molempien on nimettävä sama alue.

Endpoint-reitti osoittaa endpointin oman VPC:n aliverkkoon, ei koskaan peering-yhteyteen. VPC:n reittitaulut osoittavat peering-yhteyteen, eivät koskaan instanssiin tai rajapintaan. Arvon kopioiminen niiden välillä tallentuu valittamatta eikä reititä mitään.

Koska liitoksen aliverkko kääntää asiakkaan lähteen, B:n on reititettävä takaisin VPC:hen A, ei asiakaspooliin. Asiakasalueen lähettäminen peering-yhteyden yli näyttää symmetriseltä, läpäisee katselmoinnin ja epäonnistuu hiljaa, koska B ei koskaan näe pakettia, jonka lähde on asiakas.

Turvaryhmät ja viimeinen metri lupaa

Reititys tuo paketit B:hen; B päättää edelleen. Saman alueen aktiiviselle peering-yhteydelle B:n turvaryhmä voi viitata Client VPN -liitokseen sovellettuun ryhmään, mikä pitää säännön kapeana ja kestää osoitemuutokset. Jos ryhmäviittaus ei ole mahdollinen, salli liitoksen aliverkon alue nimenomaisesti sen sijaan että laajennat 0.0.0.0/0:aan, mikä muuttaa reititysvirheen selittämättömäksi aikakatkaisuksi.

Tarkista sitten se, mihin reititys ei koskaan koske: molempien aliverkkojen verkon ACL:t, sovelluksen sallittujen lista tai tokenin yleisö, ja DNS. Peering ei kopioi yksityisiä isännöityjä vyöhykkeitä, joten kannettavassa voi olla toimiva reitti osoitteeseen, jota se ei pysty selvittämään, eikä peering-yhteys lisää sertifikaattiin luottamusta. Osoita endpoint resolveriin, joka vastaa B:stä, ja vahvista sitten, että yksityinen nimi ja sertifikaatti täsmäävät.

Milloin bastion on rehellinen vastaus

Pidän kolmea liipaisinta bastionin tarkoitukselliselle valinnalle. Peering-VPC kuuluu tiimille, joka ei lisää paluureittiä alueellesi tai ei hyväksy ryhmäviittausta. Pääsy on hyväksyttävä tai tallennettava istuntokohtaisesti, eikä sovellus voi kantaa sitä itse. Tai viimeisen hypyn on pysyttävä B:n sisällä, koska palvelu selvitetään vain siellä ja sen TLS-identiteetti on kiinnitetty sisäiseen nimeen.

Mikään tästä ei ole kiertotie sille, että peering ei ole transitiivinen. Ei-transitiivisuus rajoittaa sitä, mitä B:n resurssit saavat tehdä: ne eivät voi käyttää A:ta transitina kolmanteen VPC:hen, jonka kanssa A on peer-yhteydessä. Se ei koskaan tarkoittanut, ettei VPN-käyttäjä voi tavoittaa suoraan peering-VPC:tä, ja bastion, joka on rakennettu kiertämään tämä väärinkäsitys, on isäntä, jota paikataan syyttä.

Vastakkainen virhe maksaa ajan myötä enemmän: työnnä jokainen tiimi jo olemassa olevan yhden bastionin läpi ja huomaa sitten, että sen turvaryhmä, reittitaulu ja paikkausikkuna ovat tuotannon riippuvuus. Kirjoita ylös, mitä liipaisinta isäntä palvelee, ja poista se käytöstä, kun liipaisin poistuu.

Transit Gateway ja useat liitokset muuttavat aritmetiikkaa

Jos endpoint on liitetty suoraan Transit Gatewayhin aliverkon sijaan, malli muuttuu: asiakkaita ei enää käännetä liitoksen aliverkon rajapintaosoitteeksi, ja yhdyskäytävän reittitaulujen on kannettava asiakasalue plus liityntä, joka johtaa peering-VPC:hen. Se on siistimpää mittakaavassa, mutta työ siirtyy neljästä merkinnästä yhdyskäytävän reittitauluihin.

Useat liitokset kertovat tarkistukset. Endpoint-reitti kuuluu endpointille, mutta jokainen liitoksen aliverkko tarvitsee reittitaulun, jossa on todellinen peering-seuraava hyppy. Istunto voi onnistua yhden liitoksen kautta, kun toisella ei ole paluupolkua, joten testaa jokainen.

Tarkistusjärjestys, joka löytää katkoksen nopeasti

Suorita nämä järjestyksessä; jokainen vaihe voi mennä läpi, kun seuraava epäonnistuu, eikä asiakkaan aikakatkaisu kerro lähes koskaan, mikä niistä hajosi.

1. Selvitä sovelluksen nimi asiakkaasta ja tarkista, että osoite on peering-alueen sisällä.
2. Yhdistä ja lue sitten endpointin yhteysloki liitokselle, joka päätti istunnon.
3. Vahvista kyseisessä liitoksen aliverkossa, että reittitaulu osoittaa peering-alueen aktiiviseen peering-yhteyteen.
4. Vahvista B:n resurssialiverkossa rajapinta-alueen paluumerkintä ja vastaavat ryhmäsäännöt.
5. Testaa yhtä sallittua toimintoa ja yhtä resurssia, jonka on pysyttävä tavoittamattomana; toinen nappaa virheenkorjauksen jäänteet.
6. Yhdistä uudelleen jokaisen split-tunnel-reittimuutoksen jälkeen, koska käynnissä oleva tunneli ei ota uutta reittijoukkoa.

Kaksi oiretta kannattaa painaa mieleen. SYN, joka saapuu B:hen ilman vastausta, on lähes aina puuttuva paluureitti. Yhteys, joka valmistuu ja nollautuu sitten, on yleensä ryhmä, ACL tai sovellus. Kumpikaan ei näy endpointin lokissa syynä, joten pidä neljä merkintää ja omistaja jokaisen vieressä.

Jos mikään kolmesta liipaisimesta ei pidä, viimeistele reititetty polku ja kirjaa ne neljä merkintää. Jos yksi pitää, pidä bastion vain sitä rajaa varten ja jätä endpoint-reitti palveluille, jotka eivät tarvitse istuntoa eteensä.