Konzola prikazuje status up, strongSwan prijavljuje uspostavljenu IKE asocijaciju, a paketi i dalje ne stižu. Sljedeće što treba uporediti nije unaprijed dijeljeni ključ, nego par prefiksa za koje svaka strana misli da ih tunel štiti. Prođite kroz provjere ispod redom, jer prve dvije odlučuju može li tunel uopće prenositi vaš saobraćaj.

Prevedite AWS nazive u strongSwan termine

AWS opisuje vezu sa strane korisnika: adresa korisničkog pristupa i lokalni CIDR pripadaju vama, a udaljeni CIDR pripada VPC-u. strongSwan naziva dva kraja left i right, vaš prefiks je u leftsubnet, a prefiks VPC-a u rightsubnet. Ako okrenete jedan par, dobijate tunel koji pregovara i odabire pogrešan saobraćaj.

Preuzmite konfiguraciju koju AWS generiše za vezu i tretirajte je kao referencu upravo za tu vezu, uključujući adrese tunela i prefikse. Ako oba CIDR polja ostavite prazna pri kreiranju, servis koristi zadanu vrijednost 0.0.0.0/0 na svakoj strani. Ruter konfigurisan s uskim prefiksom tada se nikada neće podudariti, pa ili popunite polja ili namjerno proširite selektor.

Nepodudarnost ovdje izgleda kao kvar rutiranja, ali to nije.

Fiksirajte adresu koju AWS zaista vidi

Ruter iza NAT-a može slati IKE s interfejsa za koji druga strana nikada nije saznala. Adresa pristupa zabilježena u AWS-u mora biti ona koju AWS vidi na mreži, a ruter mora biti vezan za istu lokalnu adresu umjesto da slijedi zadanu rutu.

conn %default
    local_addrs = 203.0.113.10

U strongSwan-u local_addrs bira izvornu adresu za IKE, a starije OpenSwan konfiguracije istu ideju zapisuju kao left. Usmjerite ga na interfejs koji nosi javnu adresu, zatim na samom NAT uređaju provjerite da UDP 500 i 4500 stižu do tog hosta, jer pravilo zaostalo od prethodnog rutera ih tiho odbacuje. Ispravan par selektora s pogrešnom izvornom adresom i dalje ne uspijeva, a dnevnik će okriviti prijedlog. To usmjeravanje na pogrešan trag razlog je zašto izvorna adresa zaslužuje vlastitu provjeru.

Potvrdite pravilo prosljeđivanja umjesto da ga pretpostavljate, jer pravilo koje je bilo ispravno za prethodni ruter često ostane.

Tretirajte fazu 1 i fazu 2 odvojeno

AWS prikazuje IKE i ESP opcije kao odvojene liste. IKE skup koji obje strane prihvataju ne govori ništa o ESP prijedlogu, jer su te dvije liste nezavisne. Pročitajte obje iz generisane konfiguracije i uporedite ih jednu po jednu.

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

Sintaksa se ne prenosi između implementacija. Par koji radi u OpenSwan-u, na primjer phase2alg=aes_gcm s ike=aes256-sha1;modp1024, treba prevesti u strongSwan oblik esp= i ike=, a nazivi algoritama se razlikuju. Budući da GCM provjerava autentičnost dok šifruje, ne treba mu zasebna transformacija integriteta, za razliku od CBC skupa uparenog sa SHA. Red faze 2 prenesen iz jednog daemona u drugi bez prijevoda daje odbijanje koje izgleda kao nepodudarnost selektora.

Provjerite podređenu asocijaciju, a ne indikator tunela

Ako se veza učita ali podređena asocijacija ne nastane, odbijeni su ili prijedlog ili selektori. Ako podređena asocijacija nastane, ali njeni selektori isključuju vaše prefikse, paketi se filtriraju prije nego što stignu do tunela. Indikator konzole pokriva samo IKE nivo, pa ne može reći šta se od toga dvoje dogodilo.

ipsec statusall

Potražite podređenu sigurnosnu asocijaciju i pročitajte selektore saobraćaja ispisane pored nje, zatim ih uporedite s prefiksima iz generisane konfiguracije.

Testirajte s hosta unutar lokalnog prefiksa na host unutar VPC prefiksa i provjerite povratni put te bilo koju sigurnosnu grupu ili mrežni ACL na AWS strani. Ispravni selektori ne štite paket od kasnijeg odbacivanja.

Kada i dalje ne uspijeva nakon što se selektori podudare

Potvrdite da ruta na obje strane vodi prema tunelu, zatim potvrdite da NAT uređaj ne prepisuje saobraćaj na način koji politika ne očekuje. Tunel zasnovan na politici podudara adrese paketa, pa prevođenje primijenjeno nakon odluke politike mijenja ishod.

Zabilježite jedan paket na ulazu i jedan na izlazu na svakoj strani prije nego što promijenite još jedan prijedlog.

Zabilježite selektore, prijedloge faze 1 i faze 2 i izvornu adresu u tiketu. Te četiri vrijednosti objašnjavaju većinu site-to-site kvarova bez poziva.

Povezani članci