strongSwan EC2-s: lase VPC-l töökoormust marsruutida

Lüüsist töötav tunnel tõestab ainult lüüsi. Marsruudi töökoormuse alavõrk, luba edastamine külalisel, laienda selektoreid ja seejärel testi sealt.

Tunnel on üleval, lüüsi eksemplar saab kaugvõrku pingida, kuid kõrval olev rakenduse eksemplar ei jõua mitte kuhugi. Miski ei ole katki. Õnnestunud test algas VPN-hostist ega küsinud kunagi, kas see host suudab sama IPsec-suhte kaudu kanda teist lähteaadressi. See juhend sulgeb selle lõhe neljas sammus, sellises järjekorras, mis hoiab iga tõrke nähtavana.

Kirjuta kõigepealt üles neli aadressi

Iga alljärgnev samm viitab neile, seega täida need oma konto jaoks enne, kui puudutad marsruutimistabelit.

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

Näide eeldab heakskiidetud, töötavat poliitikapõhist IPsec-ühendust ja lähtetruudust säilitavat voogu. See ei ole NAT-itud kaugjuurdepääsuklient, mis laenab üht määratud aadressi, ja see erinevus otsustab, kas selektoreid tuleb muuta.

Samm 1: anna töökoormuse alavõrgule marsruut

Marsruutimistabel, mis on tegelikult töökoormuse alavõrguga seotud, vajab kaugprefiksi jaoks teed, mis osutab lüüsi võrguliidesele. Eksemplari sees paigaldatud külalismarsruut ei ole selle AWS-i marsruutimistabeli kirje ja ükski strongSwan-i konfiguratsioon ei loo seda.

AWS-i seadme marsruutimise juhised kirjeldavad võrguliidese sihtmärke ja edastava eksemplari lähte-/sihtkoha kontrolli nõuet. Piira see kontrollimuudatus lüüsi rolliga ja jäta tavalised rakenduse eksemplarid rahule.

Ära asenda VPC kohalikku marsruuti ega kõiki olemasolevaid kirjeid, et teha ruumi ühele heakskiidetud võrgule. Uuri, mis on seotud ja aktiivne, mitte seda, mida konsooli leht näitab tabeli kohta, mida keegi ei kasuta. Kaks sarnast tabelit võivad olla erinevalt seotud. Tähtis on see, millega töökoormuse alavõrk on ühendatud.

Samm 2: luba edastamine külalisel

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

Tuul peab edastama ja hosti tulemüür peab läbiliikumise lubama. Lisa kavandatud edastusreeglid töökoormuse ja kaugprefiksi jaoks, mitte ära võta vastu kõike, ja kinnita, et lüüsi alavõrk säilitab oma liikluse jaoks kasutatava transpordimarsruudi.

Turvagrupid on koht, kus see samm tavaliselt takerdub. Vaheline seade ei päri otsese eksemplarisuhtluse turvagrupi viitamise käitumist, seega hallatava Client VPN-i näitest kopeeritud reegel ei pruugi kunagi sobida. Kontrolli turvagruppi ja alavõrgu ACL-i tegelikul teel, mõlemas suunas.

Samm 3: laienda selektorid tegelikele lähtetele

Poliitika, mis AWS-i poolel katab ainult 10.60.1.10/32, seletab lüüsist alguse saanud õnnestumist, kattmata 10.60.2.20. Marsruut kaugsihtkoha suunas ei laienda liiklusselektorit ja see on sama üllatuse teine pool.

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

Kui kokkulepitud lahendus kaitseb kogu VPC-d, peavad mõlemad partnerid aktsepteerima 10.60.0.0/16 ja 10.90.0.0/24. Kui see kaitseb üht töökoormust, kasuta seda kitsamat prefiksit teadlikult. Mõlemal juhul uuri paigaldatud CHILD-SA poliitikat, sest konfiguratsioon, mida sina muutsid, ja partner, kes kitsendas seda teisiti, ei ole sama kokkulepe.

Kaugsaidil peab ka säilitatud VPC lähtekohtade vastused tagasi marsruutima kavandatud IPsec-lüüsi kaudu. Hoia toetatud NAT-erand kaitstud liikluse jaoks seal, kus on muid lähte-NAT-i reegleid; mitteheakskiidetud töökoormuse tõlkimine lubatud hostiaadressiks on teine identiteedileping, mitte lühitee soovitud juurdepääsuni.

Samm 4: kontrolli ja vajadusel tagane

Testi töökoormusest endast värske lubatud rakendusoperatsiooniga, seejärel korda sihtkohaga, mis peaks olema välistatud. Kirjuta üles lähteaadress, mida kaugteenus näeb, ja tagasitee, mida see kasutab. Lüüsi ping või roheline IKE-olek ei ole see test.

Kui töökoormus ikka ebaõnnestub, samal ajal kui lüüs töötab, mine samme tagasi järjekorras: selektor, seejärel edastamine ja turvagrupid, seejärel seotud marsruutimistabel. Igal on erinev sümptom ja oletamine jätab vahele selle, mis on tegelikult vale.

Tagasipööramine pöörab sama järjekorra ümber. Eemalda töökoormuse alavõrgu marsruut viimasena, pärast eelmiste selektorite taastamist, et ei jääks alavõrku, mis osutab lüüsile, mis ei kaitse enam selle lähteid. Isehostimine võib teenindada rohkem kui lüüsi hosti, kui need lepingud kehtivad, ja AWS-i hallatav Site-to-Site VPN on teine töömudel, kus strongSwan võib hoopis kliendi lüüsi otsas istuda.

Seotud artiklid