strongSwan залишається вимкненим після перезавантаження peer: відновити один тунель

Відмовтеся від перезапуску демона. Перенесіть ініціювання та DPD на з’єднання, яке має повернутися, потім перевірте за назвою і доведіть службу, а не демон.

Віддалений шлюз перезавантажується, повертається за хвилину, а локальний демон strongSwan продовжує працювати, поки тунель залишається вимкненим. Завдання cron, яке шукає ESTABLISHED і перезапускає демон, зрештою замаскує це, а також перерве кожен сторонній тунель на машині, можливо пропустивши той, що відмовив. Відновлення належить з’єднанню, яке має повернутися, виражене в налаштуваннях, що переживають reload. Цей runbook налаштовує це для одного з’єднання і доводить результат за назвою.

Відмовтеся від глобального перезапуску, збережіть його докази

Перезапуск демона має два конкретні недоліки: він знищує стан кожного з’єднання і нічого не каже про те, яка подія насправді відмовила. Текст стану, який ви шукали, міг прийти з іншого з’єднання, тоді як потрібний child простоював, бо ніщо його не запустило.

Прочитайте завантажені з’єднання та активні асоціації перед будь-якими змінами, щоб мати картину «до», з якою порівняти після повернення peer.

swanctl --list-conns
swanctl --list-sas

Перенесіть ініціювання та повтори на з’єднання, що повертається

У розгортанні swanctl.conf ці налаштування живуть на рівні з’єднання та child, а не в глобальній політиці. Фрагмент нижче — приклад з боку ініціатора, який припускає, що пропозиції, автентифікація та селектори вже коректні.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action вирішує, що відбувається під час завантаження child: start ініціює негайно, а trap встановлює політику, яка запускає ініціювання, коли з’являється відповідний трафік. Запис trap|start потребує strongSwan 5.9.6 або новішого, тому перевірте версію перед копіюванням рядка. dpd_action=restart вимагає нових переговорів, щойно peer оголошено мертвим, а keyingtries=0 на рівні з’єднання дозволяє подальші спроби до успіху або постійної помилки. В IKEv2 dpd_timeout не має жодного ефекту, бо звичайна повторна передача вирішує, коли peer не відповідає.

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

Знайте, від якої події ви відновлюєтеся

Три збої виглядають однаково на панелі й потребують різних налаштувань. Початкове з’єднання, яке так і не піднялося, — це проблема конфігурації або доступності. Peer, який перестав відповідати, — це випадок DPD. Child, який peer явно закрив, — це подія політики з власним close_action, яку DPD ніколи не помічає. Читання журналу навколо збою підкаже, який із трьох у вас, і відповідь змінює виправлення.

Не додавайте агресивне повторне ініціювання з’єднанню, яке оператори навмисно закривають на обслуговування, інакше тунель з’явиться знову посеред вікна. Для схем на вимогу достатньо збереженого trap, бо відповідний трафік відновлює child без будь-якого таймера.

Перевіряйте за назвою, а не за станом демона

Прочитайте з’єднання та його child за назвою, поки peer ще вимкнений, а потім знову, коли він повернеться; різниця між цими двома виводами і є доказом.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

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

Якщо child ніколи не ініціює, перевірте, чи тестовий трафік точно відповідає налаштованим селекторам, включно з протоколом і портом. Якщо він ініціює і зазнає невдачі, прочитайте помилку автентифікації або пропозиції замість того, щоб ховати її за нескінченним циклом, бо keyingtries=0 охоче повторюватиме постійну відмову вічно.

Завантажте зміну у вікно обслуговування і повторіть тест

Перезавантаження безпечніше за перезапуск демона, і все ж воно не безкоштовне: заміна або вивантаження child може закрити запущену асоціацію чи скинути її trap.

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

swanctl --load-conns
swanctl --list-conns

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

Схожі статті