L2TP NO_PROPOSAL_CHOSEN: која је фаза заправо пала?

NO_PROPOSAL_CHOSEN стиже пре него што се провери било које PPP корисничко име, што је корисна чињеница и уједно разлог зашто порука заводи. Она јавља да је једна страна одбила предлог; не јавља који се параметар разликовао и не говори ништа о томе да ли је одбијање наступило при изградњи IKE асоцијације или касније при преговарању о заштити саобраћаја. Иза те две могућности стоје два различита исправка, а само један од њих укључује поље за означавање PFS коме људи прво посежу.

Једна порука, два скупа предлога

Распоред IKEv1 L2TP/IPsec има два преговора узастопно. Фаза 1 гради IKE безбедносну асоцијацију од алгоритма шифровања, алгоритма интегритета и Diffie-Hellman групе. Фаза 2 затим преговара како се саобраћај штити, а захтев за PFS припада том другом разговору.

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

Зашто поље за означавање PFS не може да поправи фазу 1

Искључивање PFS-а мења својство фазе 2. Ако се стране никада нису сагласиле о фази 1, разговор ESP се никада не одвија, па поље за означавање нема никакав утицај на одбијање, и зато његово пребацивање даје исту грешку са другом временском ознаком.

Обрнута грешка је једнако честа. Успешна IKE асоцијација не доказује да је ESP предлог прихватљив и сигурно не доказује да се група фазе 2 поклапа. Третирајте успостављени управљачки тунел као доказ само о фази 1. Људи читају зелену линију као „тунел ради“, а затим проведу сат на погрешној фази јер им ништа није рекло да други преговор није почео.

Прочитајте дневник пре него што изаберете алгоритме

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

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Из тих редова одговорите на два питања: да ли се успоставила асоцијација фазе 1 и која је размена пала. Та два одговора сужавају претрагу на један списак атрибута. Голо обавештење без околног контекста то не може, колико год било примамљиво испробати предлог са форумске теме. Копирање радног низа са рачунара са другим backend-ом обично замењује једно одбијање другим, мало каснијим.

Синтакса backend-а се не преноси

Запишите верзију NetworkManager-l2tp и верзију IPsec backend-а пре него што било шта упоредите. Libreswan и strongSwan не деле синтаксу предлога ни идентичне скупове алгоритама, па је низ који ради у једном синтаксна грешка у другом. Инсталирани backend може и по политици одбити IKEv1, а тада ниједан предлог никада неће бити прихваћен.

README пројекта документује те разлике међу backend-овима и држи поља фазе 1 и фазе 2 одвојеним. Читајте га као документацију структуре, не као позив да укључите сваку историјску шифру и слабу групу, јер веза која успева само тако није веза коју су вам тражили да изградите.

Договорите скуп, па проверите етапе

Питајте оператера гејтвеја који су IKE и ESP скупови подржани и одобрени, па упоредите тај одговор са стварним предлозима клијента, а не са његовом конфигурационом датотеком. Ако се несагласност односи управо на PFS фазе 2, одлучите се за подржану групу или за изричито одобрену политику без PFS-а. Не закључујте политику из назива грешке.

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

Након што исправите стварну несагласност, потврдите успостављање IPsec-а пре него што истражите L2TP и PPP, и третирајте свако касније одбијање аутентификације као да припада следећој етапи. Затим испробајте обнављање у одобреном тестном процесу, јер успостављање прве асоцијације не говори ништа о остатку њеног века.