Целосниот тунел во strongSwan бара 0.0.0.0/0 на двете страни

Целосниот тунел бара 0.0.0.0/0 како remote_ts на клиентот и local_ts на портата, плус препраќање, NAT и повратна рута. Проверете ги сите четири.

strongSwan врска што работи за една приватна подмрежа нема да пренесува интернет сообраќај само затоа што некој уредил една линија. Целосниот тунел е договор меѓу две страни за тоа кои адреси ги штити child SA, и секоја страна ја именува другата во однос на себе. Поставете едната страна правилно, а другата погрешно, и child SA или нема да се крене, или ќе се крене потесно од предвиденото. Петте проверки подолу го следат тој договор од клиентот, низ портата и кон интернет.

Прво проверете го селекторот на клиентот

Клиентот го опишува она што сака да го заштити на далечната страна како remote_ts, и сѐ што испраќа доаѓа од неговата сопствена доделена адреса. За интернет сообраќај таа вредност мора да ги покрие одредиштата што корисникот навистина ќе ги достигне, што во пракса значи целиот IPv4 простор. Клиент што сѐ уште наведува една подмрежа бара поделен тунел, како и да се вика профилот во интерфејсот. Страната на изворот обично е dynamic, бидејќи адресата се доделува при поврзување. Фиксен извор запишан таму се крши штом се промени групата адреси.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Овој фрагмент не е целосна датотека за врска, и овој претпоставува дека автентикацијата, идентитетите и групата виртуелни адреси се веќе конфигурирани. Селекторот на изворот кај клиентот и адресата што ја доделува серверот сѐ уште мора да се совпаѓаат, инаку child SA се крева со опфат што ниту една страна не го очекувала. Вчитајте го со swanctl --load-all и прочитајте го излезот пред да претпоставите успех. Датотека што се парсира сепак може да биде одбиена поради селектор што не се преклопува со предлогот на другата страна.

Проверете го селекторот на портата на нејзината страна

Портата го чита истиот концепт од спротивната насока. Интернет одредиштата се локални за портата, така што нејзиниот local_ts е широкиот, а remote_ts ја опишува групата клиенти. Ова превртување е најчестата грешка во конфигурацијата на целосен тунел, и преживува преглед затоа што двете линии изгледаат веродостојно одделно.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Копирањето на фрагментот од клиентот во датотеката на портата создава пар селектори што не опишува ништо корисно, бидејќи двете страни би барале иста улога. Упатството за препраќање на strongSwan експлицитно го документира спарувањето на клиент и порта, и вреди да се чита покрај датотеката за врска, а не по неуспехот. Датотеката на портата исто така бара дефиниција на групата на која упатува remote_ts. Селектор што именува непостоечка група се вчитува без поплака и не успева при поврзување.

Стариот ipsec.conf користи лева и десна улога со различни клучеви, а линијата rightsubnet не е директна замена за вредноста на swanctl. Држете ги двете синтакси во одделни датотеки наместо да ја вметнувате едната во другата. Мешањето во еден директориум е начинот на кој работна врска тивко се враќа по рестарт.

Проверете го договорениот child SA, не датотеката

Зачуваната конфигурација докажува намера и ништо повеќе. Другата страна може да го стесни побараното, и постоечкиот child SA не се заменува само затоа што датотеката под него се променила. Потврдете што е навистина инсталирано пред да промените нешто друго.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Првата команда покажува што вчитал демонот, втората ги покажува воспоставените child SA, а третата политиките што ќе ги примени јадрото. Ако датотеката вели 0.0.0.0/0, а списокот покажува една подмрежа, преговорите го стесниле опфатот и повторното читање на датотеката нема да го објасни тоа. Прекинете го child, стартувајте го повторно и повторно споредете ги сите три излези. Child што се враќа со истиот тесен опфат е стеснет од далечната страна, а не од локалната датотека, и тоа е разговор со другиот администратор, а не локална измена.

Читајте ги двете насоки во списокот политики, бидејќи тунел што инсталира една насока, а не другата, е проблем со рутирање во костим на конфигурација. Политиките напред и назад треба да го именуваат истиот пар селектори во огледална слика, а огледалото што недостасува е дефект во демонот или во предлогот, а не во текстот на селекторот.

Проверете го препраќањето и повратната рута

Селекторот го пропушта сообраќајот до портата, но не ја тера портата да го рутира понатаму. Препраќањето мора да биде овозможено, огнениот ѕид мора да го дозволи текот, и одговорот мора да го најде патот назад до групата клиенти. Тоа се три одделни барања, и секое не успева со различен симптом. Правилото за препраќање што недостасува се однесува како црна дупка, додека повратната рута што недостасува како еднонасочен тунел.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Приватните клиентски адреси обично бараат намерно преведување на изворот пред да можат да излезат од јавниот интерфејс, додека експлицитно рутираната распределба бара поинаков третман. Ако NAT е во игра, задржете ги исклучоците што ги поддржува имплементацијата, за сообраќајот што треба да го прегледа безбедносна политика да не се преведува покрај неа. Широкото правило masquerade копирано од друга порта менува многу повеќе текови отколку што авторот имал намера. Напишете го правилото само за групата клиенти и оставете коментар зошто постои.

На клиентот потврдете ги рутите што ги инсталирал backend, а не рутите што сте ги претпоставиле. Менаџер со оневозможено инсталирање рути бара рачно одржуван дизајн на рутирање, и тој дизајн мора да се ажурира секогаш кога тунелот се менува. Проверете ја табелата за рутирање по повторно поврзување, не само по свежо подигање.

Проверете што тунелот сѐ уште не покрива

Парот селектори покрива IPv4 и ништо друго. IPv6, DNS и секоја политика на ниво на апликација се одделни одлуки што широкиот IPv4 селектор тивко ги игнорира. Тунел што го пренесува секој IPv4 пакет сепак може да го излее секое пребарување на име.

Експлицитно наведете ја предвидената DNS патека, бидејќи целосен тунел што сѐ уште решава имиња преку локалниот резолвер ги излева барањата надвор од тунелот и ги крши приватните имиња. Ако на клиентот му се додели IPv6 адреса, тоа семејство адреси бара ист третман, инаку домаќинот ќе претпочита пат што тунелот не го штити. Тестирајте со име на кое само приватната страна може да одговори, и третирајте јавниот одговор како излевање.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Потврдете го синџирот со тие две команди плус договорените селектори од списокот погоре. Ако traceroute го покажува локалниот рутер како прв скок, сообраќајот не го користи тунелот што и да тврдат селекторите. Интернет пристапот е целосен само кога избраниот сообраќај е примен, препратен и вратен преку проектираната порта. Наоѓањето на 0.0.0.0/0 во профил е почеток на тој синџир, а не негов доказ.

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