Од strongSwan-а ка AWS Site-to-Site: зашто Child SA не бира ништа

IKE тунел може бити активан док подређена асоцијација искључује ваше подмреже. Прво упоредите локални и удаљени CIDR у AWS-у са leftsubnet и rightsubnet.

Конзола приказује up, strongSwan пријављује успостављену IKE асоцијацију, а пакети ипак не стижу. Следеће што треба упоредити није унапред подељени кључ, већ пар префикса за које свака страна мисли да их тунел штити. Прођите кроз провере испод редом, јер прве две одлучују да ли тунел уопште може да носи ваш саобраћај.

Преведите називе из AWS-а у термине strongSwan-а

AWS описује везу са стране клијента: адреса клијентске капије и локални CIDR припадају вама, а удаљени CIDR припада VPC-у. strongSwan назива два краја left и right, ваш префикс је у leftsubnet, а префикс VPC-а у rightsubnet. Замена једног пара даје тунел који преговара и бира погрешан саобраћај.

Преузмите конфигурацију коју AWS генерише за везу и третирајте је као референцу за управо ту везу, укључујући адресе и префиксе тунела. Ако при креирању оба поља CIDR оставе празна, сервис користи подразумевану вредност 0.0.0.0/0 са сваке стране. Рутер конфигурисан са уским префиксом тада се никада неће поклопити, зато или попуните поља или намерно проширите селектор.

Неслагање овде изгледа као отказ рутирања, а није.

Фиксирајте адресу коју AWS заиста види

Рутер иза NAT-а може да шаље IKE са интерфејса за који супротна страна никада није сазнала. Адреса капије забележена у AWS-у мора бити она коју AWS види на мрежи, а рутер мора бити фиксиран на исту локалну адресу уместо да прати подразумевану руту.

conn %default
    local_addrs = 203.0.113.10

У strongSwan-у local_addrs бира изворну адресу за IKE, а старије OpenSwan конфигурације исту идеју пишу као left. Усмерите је на интерфејс који носи јавну адресу, затим на самом NAT уређају проверите да UDP 500 и 4500 стижу до тог хоста, јер правило које је остало од претходног рутера их тихо одбацује. Исправан пар селектора са погрешном изворном адресом ипак не успева, а дневник ће окривити предлог. Управо то навођење на погрешан траг разлог је зашто изворна адреса заслужује сопствену проверу.

Потврдите правило прослеђивања уместо да га претпостављате, јер правило које је било исправно за претходни рутер често остане.

Третирајте фазу 1 и фазу 2 одвојено

AWS приказује IKE и ESP опције као одвојене листе. IKE скуп који прихватају обе стране не говори ништа о ESP предлогу, јер су те две листе независне. Прочитајте оба из генерисане конфигурације и упоредите их једно по једно.

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

Синтакса се не преноси између имплементација. Пар који ради у OpenSwan-у, на пример phase2alg=aes_gcm са ike=aes256-sha1;modp1024, треба превести у облик esp= и ike= strongSwan-а, а називи алгоритама се разликују. Пошто GCM проверава аутентичност током шифровања, није му потребна засебна трансформација интегритета, за разлику од CBC скупа упареног са SHA. Линија фазе 2 убачена из једног демона у други без превода даје одбијање које се чита као неслагање селектора.

Проверите подређену асоцијацију, а не индикатор тунела

Ако се веза учита, али подређена асоцијација не настане, одбијен је или предлог или селектори. Ако подређена настане и њени селектори искључују ваше префиксе, пакети се филтрирају пре него што стигну до тунела. Индикатор конзоле покрива само IKE ниво, па не може да каже која се од две ствари догодила.

ipsec statusall

Пронађите подређену безбедносну асоцијацију и прочитајте селекторе саобраћаја одштампане поред ње, затим их упоредите са префиксима из генерисане конфигурације.

Тестирајте са хоста унутар локалног префикса на хост унутар префикса VPC-а и проверите повратни пут, као и било коју безбедносну групу или мрежни ACL на страни AWS-а. Исправни селектори не штите пакет од каснијег одбацивања.

Када и даље не успева након што се селектори поклопе

Потврдите да рута на обе стране води ка тунелу, затим потврдите да NAT уређај не преписује саобраћај на начин који политика не очекује. Тунел заснован на политици упоређује адресе пакета, па превод примењен после одлуке политике мења исход.

Забележите један улазни и један излазни пакет на свакој страни пре него што промените још један предлог.

Запишите селекторе, предлоге фазе 1 и фазе 2 и изворну адресу у тикет. Ове четири вредности објашњавају већину site-to-site отказа без позива.

Повезани чланци