strongSwan EC2:ssa: anna VPC:n reitittää työkuorma

Tunneli on pystyssä, yhdyskäytävän instanssi voi pingata etäverkkoa, eikä vieressä oleva sovellusinstanssi tavoita mitään. Mikään ei ole rikki. Onnistunut testi alkoi VPN-isännästä, eikä se koskaan kysynyt, voisiko kyseinen isäntä kuljettaa toista lähdeosoitetta saman IPsec-suhteen läpi. Tämä ohje sulkee tämän aukon neljässä vaiheessa, siinä järjestyksessä, joka pitää jokaisen vian näkyvänä.

Kirjoita neljä osoitetta ensin muistiin

Jokainen alla oleva vaihe viittaa niihin, joten täytä ne omalle tilillesi ennen kuin kosket reititystaulukkoon.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Esimerkki olettaa hyväksytyn, toimivan käytäntöpohjaisen IPsec-yhteyden ja lähteen säilyttävän kulun. Tämä ei ole NATattu etäkäyttöasiakas, joka lainaa yhden määritetyn osoitteen, ja tämä ero ratkaisee, täytyykö valitsimia muuttaa.

Vaihe 1: anna työkuorman aliverkolle reitti

Reititystaulukko, joka on tosiasiallisesti liitetty työkuorman aliverkkoon, tarvitsee polun etäetuliitteelle, joka osoittaa yhdyskäytävän verkkoliitäntään. Instanssin sisään asennettu vierasreitti ei ole merkintä kyseisessä AWS:n reititystaulukossa, eikä mikään määrä strongSwan-määrityksiä luo sellaista.

AWS:n ohjeet laitteen kautta reitittämiseen kuvaavat verkkoliitäntäkohteet ja edelleenlähettävän instanssin lähde-/kohdevalvontavaatimuksen. Rajaa tämä valvontamuutos yhdyskäytävän rooliin ja jätä tavalliset sovellusinstanssit rauhaan.

Älä korvaa VPC:n paikallista reittiä äläkä jokaista olemassa olevaa merkintää tehdäksesi tilaa yhdelle hyväksytylle verkolle. Tarkastele, mikä on liitetty ja aktiivinen, sen sijaan mitä konsolisivu näyttää reititystaulukosta, jota kukaan ei käytä. Kaksi samannäköistä taulukkoa voivat olla eri tavoin liitettyjä. Ratkaiseva on se, johon työkuorman aliverkko on kytketty.

Vaihe 2: ota edelleenlähetys käyttöön vieraassa

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Ytimen on välitettävä ja isännän palomuurin on sallittava läpikulku. Lisää aiotut edelleenlähetyssäännöt työkuorman ja etäetuliitteiden osalta sen sijaan, että hyväksyt kaiken, ja varmista, että yhdyskäytävän aliverkko säilyttää käyttökelpoisen siirtoreitin omalle liikenteelleen.

Tietoturvaryhmät ovat paikka, jossa tämä vaihe yleensä pysähtyy. Välityslaite ei peri suoran instanssien välisen viestinnän tietoturvaryhmäviittauskäyttäytymistä, joten hallitun Client VPN -esimerkin kopioitu sääntö ei välttämättä koskaan täsmää. Tarkista tietoturvaryhmä ja aliverkon ACL todellisella polulla, molempiin suuntiin.

Vaihe 3: laajenna valitsimet todellisiin lähteisiin

Käytäntö, joka kattaa AWS:n puolella vain 10.60.1.10/32, selittää yhdyskäytävästä alkaneen onnistumisen kattamatta 10.60.2.20. Reitti etäkohteeseen ei laajenna liikenteen valitsinta, ja se on saman yllätyksen toinen puoli.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Jos sovittu suunnittelu suojaa koko VPC:n, molempien osapuolten on hyväksyttävä 10.60.0.0/16 ja 10.90.0.0/24. Jos se suojaa yhtä työkuormaa, käytä tuota kapeampaa etuliitettä tarkoituksella. Joka tapauksessa tarkista asennettu CHILD-SA-käytäntö, koska muokkaamasi määritys ja toisin rajaava vastapuoli eivät ole sama sopimus.

Etäsivuston on myös reititettävä säilytettyjen VPC-lähteiden vastaukset takaisin aiottuun IPsec-yhdyskäytävään. Säilytä tuettu NAT-poikkeus suojatulle liikenteelle, kun muita lähde-NAT-sääntöjä on olemassa; hyväksymättömän työkuorman kääntäminen sallituksi isäntäosoitteeksi on toinen identiteettisopimus, ei oikotie haluamaasi pääsyyn.

Vaihe 4: varmista ja peruuta tarvittaessa

Testaa työkuormasta itsestään uudella sallitulla sovellustoiminnolla ja toista sitten kohteella, joka pitäisi sulkea pois. Kirjaa ylös lähdeosoite, jonka etäpalvelu näkee, ja paluupolku, jota se käyttää. Yhdyskäytävän ping tai vihreä IKE-tila ei ole se testi.

Jos työkuorma epäonnistuu edelleen yhdyskäytävän toimiessa, palaa vaiheissa taaksepäin järjestyksessä: valitsin, sitten edelleenlähetys ja tietoturvaryhmät, sitten liitetty reititystaulukko. Jokaisella on erillinen oire, ja arvaaminen ohittaa sen, joka on todella väärin.

Peruutus kääntää saman järjestyksen. Poista työkuorman aliverkon reitti viimeiseksi, kun olet palauttanut aiemmat valitsimet, jotta et jätä aliverkkoa osoittamaan yhdyskäytävään, joka ei enää suojaa sen lähteitä. Itse ylläpidetty palvelu voi palvella muutakin kuin yhdyskäytäväisäntää, kun nämä sopimukset pitävät, ja AWS:n hallinnoima Site-to-Site VPN on erilainen toimintamalli, jossa strongSwan voi sen sijaan olla asiakkaan yhdyskäytävän päässä.