strongSwanista AWS Site-to-Siteen: miksi Child SA ei valitse mitään

IKE-tunneli voi olla pystyssä, vaikka lapsiyhteys jättää aliverkkosi ulkopuolelle. Vertaa ensin AWS:n paikallista ja etä-CIDR:ää leftsubnet- ja rightsubnet-arvoihin.

Konsoli näyttää up-tilaa, strongSwan ilmoittaa muodostetusta IKE-yhteydestä, eivätkä paketit silti saavu. Seuraavaksi ei vertailla esijaettua avainta vaan sitä etuliiteparia, jonka kumpikin osapuoli uskoo tunnelin suojaavan. Käy alla olevat tarkistukset järjestyksessä läpi, sillä kaksi ensimmäistä ratkaisevat, voiko tunneli ylipäätään kuljettaa liikennettäsi.

Käännä AWS:n nimet strongSwanin termeiksi

AWS kuvaa yhteyden asiakkaan puolelta: asiakasyhdyskäytävän osoite ja paikallinen CIDR kuuluvat sinulle ja etä-CIDR kuuluu VPC:lle. strongSwan kutsuu kahta päätä nimillä left ja right, jolloin etuliitteesi on leftsubnetissa ja VPC:n etuliite rightsubnetissa. Yhden parin kääntäminen tuottaa tunnelin, joka neuvottelee ja valitsee väärän liikenteen.

Lataa konfiguraatio, jonka AWS luo yhteydelle, ja käytä sitä juuri tämän yhteyden vertailukohtana, mukaan lukien tunnelin osoitteet ja etuliitteet. Jos jätät molemmat CIDR-kentät tyhjiksi luonnissa, palvelu käyttää kummallakin puolella oletusta 0.0.0.0/0. Kapealla etuliitteellä määritetty reititin ei silloin koskaan täsmää siihen, joten joko täytä kentät tai levennä valitsinta tarkoituksella.

Epäsuhta näyttää tässä reititysvialta eikä ole sitä.

Kiinnitä osoite, jonka AWS todella näkee

NAT:n takana oleva reititin voi lähettää IKE:n rajapinnasta, jota vastapuoli ei koskaan oppinut tuntemaan. AWS:ään tallennettu yhdyskäytävän osoite on saatava samaksi kuin se, jonka AWS näkee verkossa, ja reititin on kiinnitettävä samaan paikalliseen osoitteeseen sen sijaan, että se seuraisi oletusreittiään.

conn %default
    local_addrs = 203.0.113.10

strongSwanissa local_addrs valitsee lähdeosoitteen IKE:lle, ja vanhemmat OpenSwan-konfiguraatiot kirjoittavat saman idean muodossa left. Kohdista se rajapintaan, jolla julkinen osoite on, ja varmista sitten itse NAT-laitteesta, että UDP 500 ja 4500 saavuttavat kyseisen isännän, koska aiemmasta reitittimestä jäänyt sääntö pudottaa ne hiljaisesti. Oikea valitsinpari väärällä lähdeosoitteella epäonnistuu silti, ja loki syyttää ehdotusta. Juuri tämän harhaanjohtavuuden vuoksi lähdeosoite ansaitsee oman tarkistuksensa.

Vahvista edelleenlähetyssääntö sen sijaan, että olettaisit sen, koska edelliselle reitittimelle oikea sääntö jää usein jäljelle.

Käsittele vaihe 1 ja vaihe 2 erikseen

AWS näyttää IKE- ja ESP-vaihtoehdot erillisinä listoina. IKE-kokoonpano, jonka molemmat osapuolet hyväksyvät, ei kerro mitään ESP-ehdotuksesta, koska listat ovat riippumattomia. Lue molemmat luodusta konfiguraatiosta ja vertaa niitä yksitellen.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Syntaksi ei siirry toteutusten välillä. OpenSwanissa toimiva pari, esimerkiksi phase2alg=aes_gcm yhdessä ike=aes256-sha1;modp1024:n kanssa, on käännettävä strongSwanin esp= ja ike= -muotoon, ja algoritmien nimet eroavat. Koska GCM todentaa salatessaan, se ei tarvitse erillistä eheysmuunnosta, toisin kuin SHA:n kanssa paritettu CBC-kokoonpano. Yhdestä taustapalvelusta toiseen ilman käännöstä liitetty vaiheen 2 rivi tuottaa hylkäyksen, joka kuulostaa valitsinten epäsuhdalta.

Tarkista lapsiyhteys, ei tunnelin ilmaisinta

Jos yhteys latautuu mutta lapsiyhteyttä ei synny, joko ehdotus tai valitsimet hylättiin. Jos lapsi syntyy ja sen valitsimet jättävät etuliitteesi ulkopuolelle, paketit suodatetaan ennen kuin ne saavuttavat tunnelin. Konsolin ilmaisin kattaa vain IKE-tason, joten se ei voi kertoa, kumpi kahdesta tapahtui.

ipsec statusall

Etsi lapsen tietoturvayhteys ja lue sen viereen tulostetut liikenteen valitsimet ja vertaa niitä sitten luodun konfiguraation etuliitteisiin.

Testaa paikallisen etuliitteen sisällä olevasta isännästä VPC:n etuliitteen sisällä olevaan isäntään ja tarkista paluureitti sekä mahdollinen tietoturvaryhmä tai verkon ACL AWS:n puolella. Oikeat valitsimet eivät suojaa pakettia myöhemmältä pudotukselta.

Kun se epäonnistuu silti valitsinten täsmättyä

Vahvista, että reitti molemmilla puolilla osoittaa tunneliin, ja vahvista sitten, ettei NAT-laite kirjoita liikennettä uudelleen tavalla, jota käytäntö ei odota. Käytäntöpohjainen tunneli täsmää pakettien osoitteita, joten käytäntöpäätöksen jälkeen tehty käännös muuttaa lopputuloksen.

Kirjaa yksi saapuva ja yksi lähtevä paketti kummallakin puolella ennen kuin muutat seuraavaa ehdotusta.

Kirjaa valitsimet, vaiheen 1 ja vaiheen 2 ehdotukset sekä lähdeosoite tikettiin. Nämä neljä arvoa selittävät useimmat site-to-site-viat ilman puhelua.

Aiheeseen liittyvät artikkelit