Nga strongSwan në AWS Site-to-Site: pse Child SA nuk zgjedh asgjë

Një tunel IKE mund të jetë aktiv ndërsa shoqata fëmijë përjashton nënrrjetet tuaja. Krahasoni së pari CIDR-in lokal dhe të largët të AWS me leftsubnet dhe rightsubnet.

Konsola tregon up, strongSwan raporton një shoqatë IKE të vendosur dhe paketat prapëseprapë nuk mbërrijnë. Gjëja tjetër për të krahasuar nuk është çelësi i paranduar, por çifti i prefiksave që secila anë mendon se tuneli i mbron. Kaloni kontrollet më poshtë me radhë, sepse dy të parat vendosin nëse tuneli mund ta mbajë fare trafikun tuaj.

Përktheni emrat e AWS në termat e strongSwan

AWS e përshkruan lidhjen nga ana e klientit: adresa e portës së klientit dhe CIDR-i lokal janë tuajat, dhe CIDR-i i largët i përket VPC-së. strongSwan i quan dy skajet left dhe right, me prefiksin tuaj në leftsubnet dhe prefiksin e VPC-së në rightsubnet. Kthimi i një çifti prodhon një tunel që negocion dhe zgjedh trafikun e gabuar.

Shkarkoni konfigurimin që AWS gjeneron për lidhjen dhe trajtojeni si referencë për pikërisht atë lidhje, duke përfshirë adresat dhe prefikset e tunelit. Nëse i lini bosh të dyja fushat CIDR gjatë krijimit, shërbimi përdor vlerën e parazgjedhur 0.0.0.0/0 në secilën anë. Një ruter i konfiguruar me prefiks të ngushtë atëherë nuk do të përputhet kurrë, prandaj ose plotësoni fushat ose zgjeroni qëllimisht përzgjedhësin.

Një mospërputhje këtu duket si dështim rrugëtimi dhe nuk është.

Fiksoni adresën që AWS sheh vërtet

Një ruter pas NAT mund të dërgojë IKE nga një ndërfaqe që pala tjetër nuk e ka njohur kurrë. Adresa e portës e regjistruar në AWS duhet të jetë ajo që AWS vëzhgon në rrjet, dhe ruteri duhet të fiksohet në të njëjtën adresë lokale në vend që të ndjekë rrugën e parazgjedhur.

conn %default
    local_addrs = 203.0.113.10

Në strongSwan local_addrs zgjedh adresën burimore për IKE, dhe konfigurimet më të vjetra OpenSwan e shkruajnë të njëjtën ide si left. Drejtojeni te ndërfaqja që mban adresën publike, më pas verifikoni në vetë pajisjen NAT që UDP 500 dhe 4500 arrijnë atë host, sepse një rregull i mbetur nga një ruter i mëparshëm i hedh në heshtje. Çifti i saktë i përzgjedhësve me adresë burimore të gabuar dështon prapëseprapë, dhe regjistri do të fajësojë propozimin. Pikërisht ky keqdrejtim është arsyeja pse adresa burimore meriton verifikim më vete.

Konfirmoni rregullin e përcjelljes në vend që ta supozoni, sepse një rregull që ishte i saktë për ruterin e mëparshëm shpesh mbetet.

Trajtoni fazën 1 dhe fazën 2 veçmas

AWS i shfaq opsionet IKE dhe ESP si lista të veçanta. Një grup IKE që pranohet nga të dyja palët nuk thotë asgjë për propozimin ESP, sepse dy listat janë të pavarura. Lexojini të dyja nga konfigurimi i gjeneruar dhe krahasoni një nga një.

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

Sintaksa nuk udhëton mes implementimeve. Një çift që funksionon në OpenSwan, për shembull phase2alg=aes_gcm me ike=aes256-sha1;modp1024, duhet përkthyer në formën esp= dhe ike= të strongSwan, dhe emrat e algoritmeve ndryshojnë. Meqë GCM vërteton autenticitetin gjatë kriptimit, nuk ka nevojë për një transformim të veçantë integriteti, ndryshe nga një grup CBC i çiftuar me SHA. Një rresht i fazës 2 i ngjitur nga një demon në tjetrin pa përkthim prodhon një refuzim që lexohet si mospërputhje përzgjedhësish.

Kontrolloni shoqatën fëmijë, jo treguesin e tunelit

Nëse lidhja ngarkohet por nuk shfaqet asnjë shoqatë fëmijë, u refuzua ose propozimi ose përzgjedhësit. Nëse shfaqet një fëmijë dhe përzgjedhësit e tij përjashtojnë prefikset tuaja, paketat filtrohen para se të arrijnë tunelin. Treguesi i konsolës mbulon vetëm nivelin IKE, prandaj nuk mund t'ju thotë cila nga të dyja ndodhi.

ipsec statusall

Kërkoni shoqatën e sigurisë fëmijë dhe lexoni përzgjedhësit e trafikut të shtypur pranë saj, më pas krahasoni me prefikset nga konfigurimi i gjeneruar.

Testoni nga një host brenda prefiksit lokal në një host brenda prefiksit të VPC-së, dhe kontrolloni rrugën e kthimit plus çdo grup sigurie ose ACL rrjeti në anën e AWS. Përzgjedhësit e saktë nuk e mbrojnë një paketë nga hedhja më vonë.

Kur vazhdon të dështojë pasi përzgjedhësit përputhen

Konfirmoni që rruga në të dyja anët tregon drejt tunelit, më pas konfirmoni që pajisja NAT nuk e rishkruan trafikun në një mënyrë që politika nuk e pret. Një tunel i bazuar në politikë përputh adresat e paketave, prandaj një përkthim i aplikuar pas vendimit të politikës ndryshon rezultatin.

Regjistroni një paketë hyrëse dhe një dalëse në secilën anë përpara se të ndryshoni një propozim tjetër.

Shënoni përzgjedhësit, propozimet e fazës 1 dhe fazës 2 dhe adresën burimore në biletë. Këto katër vlera shpjegojnë shumicën e dështimeve site-to-site pa një telefonatë.

Artikuj të ngjashëm