Чи ламає спільний файл параметрів pppd ваш інший VPN?

Ви додаєте один рядок, щоб упертий профіль PPTP усе ж підключився, а за тиждень клієнт L2TP, який працював місяцями, перестає працювати. Очевидне прочитання — два протоколи тепер конфліктують. Частіше обидва клієнти запускають pppd, обидва читають ті самі типові параметри, а доданий рядок ніколи не був обмежений профілем, який ви виправляли. Спільний файл параметрів і є тим зв'язком, а протоколи тут ні до чого.

Що клієнт успадковує під час запуску

Клієнт на базі PPP рідко будує командний рядок з нуля. Він запускає pppd, який читає системні типові параметри, потім файл користувача або термінала, далі аргументи, передані клієнтом, а клієнт може ще вказати файл peer. Кожен із цих шарів може нести плагін, метод автентифікації або директиву маршруту, і перший шар, що задає захищений параметр, може зафіксувати його від подальших змін.

Тож корисне питання — не який VPN зламався, а який шар надав це налаштування. Клієнт, що сам генерує аргументи, виглядає самодостатнім, але все одно успадковує все, що містить системний файл.

З'ясуйте походження рядка, перш ніж його змінювати

Почніть із процесу, який працює, поки з'єднання активне. Командний рядок показує, які файли передані явно, а все, чого там немає, прийшло зі шляху за замовчуванням.

ps -o pid=,args= -C pppd

Якщо в списку аргументів є ім'я peer, прочитайте цей файл. Якщо ні, потрібне налаштування живе у спільному шляху. посібник pppd перелічує порядок читання цих файлів і параметри, які звичайний користувач не може перевизначити, тому пізніший рядок іноді не дає жодного ефекту. Захищений параметр, як-от шлях до плагіна, не можна замінити пізнішим рядком на рівні користувача, тож редагування не того файлу не дає видимого результату.

Рядок плагіна, що йде за кожним клієнтом

Плагін, завантажений у системному файлі, — найгірший випадок, бо він змінює те, що намагається завантажити новий процес PPP, незалежно від того, яку кнопку натиснув користувач. Плагін L2TP — класичний приклад: правильний для одного профілю, безглуздий або шкідливий для профілю PPTP, що стартує з тих самих типових параметрів.

Перенесіть його у файл peer, який вибирає клієнт, або в налаштування окремого з'єднання самого клієнта, якщо він це підтримує. Просте видалення виправить другий клієнт і зламає перший — саме так ці проблеми й мандрують між командами.

Перевірте кожен клієнт після перенесення

Перевірте обидва з'єднання з тієї самої машини, одне за одним, і читайте узгоджені параметри, а не вікно успіху. Наведений нижче дамп друкує набір параметрів, який pppd справді склав, і тільки цей список має значення.

sudo pppd call office debug dump

Повторіть для другого клієнта й порівняйте два виводи. Перенесений параметр має з'явитися рівно в одному з них. Якщо він є в обох, клієнт генерує його знову, і виправлення належить тому профілю, а не спільному файлу. Запишіть, де тепер живе це налаштування, поруч із з'єднанням, щоб наступна людина не відкривала цей зв'язок заново, знову його зламавши.