strongSwan nei AWS Site-to-Site: wêrom’t de Child SA neat selektearret

In IKE-tunnel kin oan wêze wylst de bernassosjaasje dyn subnetten útslút. Fergelykje earst de lokale en fiere CIDR fan AWS mei leftsubnet en rightsubnet.

De konsole toant up, strongSwan rapportearret in oprjochte IKE-assosjaasje, en de pakketten komme noch altyd net oan. It folgjende dat fergeleke wurde moat is net de foarôf dielde kaai, mar it pear foartekens dat elke kant tinkt dat de tunnel beskermet. Rin de kontrôles hjirûnder yn folchoarder troch, want de earste twa beslute oft de tunnel dyn ferkear wol drage kin.

Oerset de nammen fan AWS nei dy fan strongSwan

AWS beskriuwt de ferbining fan de klantkant: it adres fan ’e klantpoarte en de lokale CIDR binne fan dy, en de fiere CIDR heart by de VPC. strongSwan neamt de beide einen left en right, mei dyn foarteken yn leftsubnet en it VPC-foarteken yn rightsubnet. Ien pear omkeare jout in tunnel dy’t it ferkearde ferkear ûnderhannelt en selektearret.

Download de konfiguraasje dy’t AWS foar de ferbining generearret en behannelje dy as de referinsje foar krekt dy ferbining, ynklusyf tunneladressen en foartekens. Litst beide CIDR-fjilden by it oanmeitsjen leech, dan brûkt de tsjinst de standertwearde 0.0.0.0/0 oan elke kant. In router dy’t mei in smel foarteken konfigurearre is, sil dan nea oerienkomme, dus folje de fjilden yn of ferbreedzje de selektearder bewust.

In ôfwiking hjir liket in routeringsflater en is it net.

Fêstigje it adres dat AWS eins sjocht

In router efter NAT kin IKE stjoere fan in ynterface ôf dy’t de oare kant nea leard hat. It poarte-adres dat yn AWS fêstlein is, moat itselde wêze as dat AWS op ’e tried sjocht, en de router moat oan itselde lokale adres fêstlein wurde ynstee fan syn standertrûte te folgjen.

conn %default
    local_addrs = 203.0.113.10

Yn strongSwan kiest local_addrs it boarne-adres foar IKE, en âldere OpenSwan-konfiguraasjes skriuwe itselde idee as left. Rjochtsje it op ’e ynterface mei it iepenbiere adres, kontrolearje dan op it NAT-apparaat sels oft UDP 500 en 4500 dat hosts berikke, want in regel dy’t fan in eardere router oerbleaun is smyt se stil fuort. In korrekt selektearderpear mei it ferkearde boarne-adres mislearret noch, en it logboek sil it foarstel de skuld jaan. Krekt dy mislieding is wêrom’t it boarne-adres syn eigen kontrôle fertsjinnet.

Befêstigje de trochstjoerregel ynstee fan him oan te nimmen, want in regel dy’t foar de foarige router goed wie, bliuwt faak hingjen.

Behannelje faze 1 en faze 2 apart

AWS toant IKE- en ESP-opsjes as aparte listen. In IKE-set dy’t beide kanten akseptearje seit neat oer it ESP-foarstel, want de beide listen binne ûnôfhinklik. Lês se beide út ’e generearre konfiguraasje en fergelykje se ien foar ien.

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

Syntaksis reizget net tusken ymplemintaasjes. In pear dat yn OpenSwan wurket, bygelyks phase2alg=aes_gcm mei ike=aes256-sha1;modp1024, moat oerset wurde yn strongSwan syn esp=- en ike=-foarm, en de algoritmenammen ferskille. Om’t GCM autentisearret wylst it fersifere, hat it gjin aparte yntegriteitsomfoarming nedich, oars as in CBC-set pearre mei SHA. In rigel fan faze 2 dy’t sûnder oersetting fan it iene daemon yn it oare plakt wurdt, jout in ôfwizing dy’t as in selektearderôfwiking lêst.

Kontrolearje de bernassosjaasje, net de tunnelindikator

As de ferbining laden wurdt mar der gjin bernassosjaasje opkomt, binne of it foarstel of de selektearders wegere. As der wol in bern opkomt en syn selektearders slute dyn foartekens út, wurde pakketten filtere foar’t se de tunnel berikke. De indikator fan ’e konsole beslacht allinnich it IKE-nivo, dus hy kin dy net sizze hokker fan ’e beide barde.

ipsec statusall

Sykje de bernfeiligensassosjaasje en lês de ferkearsselektearders dy’t derneist printe binne, fergelykje se dan mei de foartekens út ’e generearre konfiguraasje.

Test fan in host binnen it lokale foarteken nei in host binnen it VPC-foarteken, en kontrolearje de weromwei plus elke feiligensgroep of netwurk-ACL oan ’e AWS-kant. Korrekte selektearders beskermje in pakket net tsjin letter fuortsmieten.

As it noch mislearret neidat de selektearders oerienkomme

Befêstigje dat de rûte oan beide kanten nei de tunnel wiist, befêstigje dan dat it NAT-apparaat it ferkear net oerskriuwt op in wize dy’t it belied net ferwachtet. In beliedsbasearre tunnel komt oerien mei pakketadressen, dus in oersetting dy’t nei it beliedsbeslút tapast wurdt feroaret de útkomst.

Log ien pakket yn en ien pakket út oan elke kant foar’t jo noch in foarstel feroarje.

Skriuw de selektearders, de foarstellen fan faze 1 en faze 2 en it boarne-adres yn ’e ticket. Dy fjouwer wearden ferklearje de measte site-to-site-flaters sûnder in oprop.

Relatearre artikelen