L2TP: фатален сигнал 15, NO_PROPOSAL_CHOSEN и исчезнат modp1024

Врската ви се замрзнува, клиентот излегува и последната линија на екранот е death_handler: Fatal signal 15 received. Таа линија пријавува прекин, а не причина. Една линија погоре во дневникот на IPsec речиси секогаш има NO_PROPOSAL_CHOSEN, и парот укажува на фаза 2 од размената, каде страните ги споредуваат изборите за шифрирање и хаш и запираат кога немаат ништо заедничко. Во таа фаза акредитивите уште не се испратени, па повторното внесување на лозинката не може да го промени резултатот.

Две работи обично го празнат тој пресек на Linux клиент. Локалниот демон можеби повеќе не ја спроведува Diffie-Hellman групата што ја бара профилот, или профилот може да носи предлог од фаза 1 во поле за фаза 2. Двете оставаат трага во дневникот и ниту една не е проблем со сметка.

Што всушност кажуваат двете пораки

IKE преговара во премини. Фаза 1 гради заштитен канал и избира свои алгоритми; фаза 2, детето SA, пренесува сообраќај под одделен сет. NO_PROPOSAL_CHOSEN е известувањето што одговорниот го враќа кога ниту една од понудените комбинации не е прифатлива, и се појавува како [ HASH N(NO_PROP) ] внатре во INFORMATIONAL размена.

Сигналот 15 е друг настан: нешто му нареди на локалниот процес да запре и ракувачот го запиша тоа. Кога двете линии се појавуваат заедно, редоследот е причински, прво одбивање па гасење.

Прочитајте ги преговорите пред да ги допрете акредитивите

Подигнете го нивото на дневникот таму каде што пишува демонот, потоа поврзете се повторно додека го гледате излезот. На домаќин со NetworkManager L2TP приклучокот го предава тоа ниво на backend-от, а пораките завршуваат во journal или во класичната syslog датотека зависно од дистрибуцијата. Било кое од овие ќе ја покаже размената: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' или tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Линијата што го именува pluto доаѓа од libreswan, charon од strongSwan, и двете опишуваат иста состојба со различни зборови. Формата што вреди да се бара е онаа што ја именува групата што недостига, на пример algorithm 'modp1024' is not supported, зашто нејасниот дефект го претвора во конкретен.

Каде исчезна modp1024

Diffie-Hellman групата 2 е доволно слаба што неколку дистрибуции престанаа да ја компајлираат во libreswan од 3.30 наваму. Тогаш профил напишан пред години, или преземен од водич за порта што наведува само aes128-sha1-modp1024, бара од локалниот демон нешто што тој воопшто не може да го изврши. Новите изградби на NetworkManager-l2tp го прават тој исход поверојатен: од 1.2.16 тие го заменуваат сетот со предлози во стил на Windows 10 и iOS и го отфрлаат modp1024 штом се открие libreswan. Спротивната страна често е невина и понатаму ја нуди токму групата што сте ја поставиле.

Токму таа асиметрија го прави дефектот да изгледа случаен. Постар клиент се поврзува, истиот профил на ажуриран преносен сметач не, а конфигурацијата на серверот никогаш не се помести. Штетата ја прави разликата во верзиите.

Два поправки со различен опсег

Евтината поправка е да престанете да ги вградувате алгоритмите рачно. Исчистете ги двете полиња за предлози во уредувачот и оставете приклучокот да избере сет што далечната страна го прифаќа; ако портата поддржува современи групи, преговорите завршуваат без дополнителна работа.

Втората поправка ја одржува старата порта достапна со инсталирање на strongSwan, чии пакети во повеќето дистрибуции понатаму ја спроведуваат групата 2. Тоа е замена на демон, па има цена: проверете дали други тунели на домаќинот зависат од конфигурацијата на libreswan пред да го отстраните, и очекувајте одбивања од SELinux помеѓу NetworkManager и strongSwan приклучокот на Fedora. Тие одбивања се појавуваат во ревизорскиот дневник, а не во трагата на IKE, затоа тунелот може да изгледа расипан веднаш по успешна инсталација. Редоследот што работи е прво dnf install strongswan, потоа rpm -e libreswan.

Предлози што се совпаѓаат и стапиците околу нив

Кога полињата мора да се пополнат рачно, фаза 1 и фаза 2 земаат различни вредности. Пар за кој се знае дека работи против спротивна страна во стил на Meraki нуди aes128-sha1-modp1024 во фаза 1 со 3des-sha1-modp1024 зад него, двете затворени со извичник што го прави сетот строг, така што се испраќаат само тие предлози.

Потоа фаза 2 се стеснува до aes128-sha1 и 3des-sha1 со истиот строг маркер и без никаква наставка Diffie-Hellman. Линија во фаза 2 што носи -modp1024 е вредност од фаза 1 во погрешно поле, и одговорниот ја одбива при секој обид. Копирајте ја таа линија во втор профил и вториот профил не успева на ист начин, и така една печатна грешка станува инцидент за целата флота.

Други дефекти го носат истиот скокачки прозорец без да бидат несовпаѓање на предлози. На KDE типот L2TP може да биде наведен со инсталиран приклучок, а секоја врска веднаш умира, зашто уредувачот на врски и помошниците за време на извршување се испорачуваат како одделни пакети. Домаќини без екран можат повторно да користат профил од работна работна површина: копирајте го од /etc/NetworkManager/system-connections/, поставете режим на 600, потоа извршете nmcli con reload. Подигнете го со nmcli con up id work-l2tp, бидејќи голата форма бара UUID, и отстранете секој застарен ifname запис, инаку менаџерот одговара Could not find source connection додека другото е точно.

Претходно споделен клуч може да се чува како чист текст или како 0s по што следи base64; двете форми работат, но вредноста мора да се совпадне со портата бајт по бајт, вклучително завршните празни места што сте ги копирале со него.