Од 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 неуспеси без телефонски повик.

Поврзани статии