Резервна оренда після повернення тунелю майданчика: оновити чи зачекати?

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

Два годинники, і один із них не тунель

З DHCP поверх VPN і локальним резервом пристрій може видавати тимчасові локальні оренди, поки віддалений шлях DHCP недоступний. Тимчасова тривалість зазвичай рахується в хвилинах: цього досить мало, щоб приховати проблему, і досить багато, щоб пережити короткий збій. Коли тунель повертається, резерв перестає пропонувати такі оренди. Він не заходить у клієнт і не скасовує оренду, яку той уже тримає. Цей клієнт зберігає адресу, маску, шлюз і розв'язувач до оновлення або закінчення терміну, і тому здоровий тунель і зламаний комп'ютер можуть співіснувати до кінця оренди.

Тримайте реалізацію та версію програмного забезпечення прив'язаними до цього твердження. Назви таймерів і значення за замовчуванням різняться між випусками SonicOS, і старий інтерфейс не доводить, що робить новий.

Порівняйте два кроки відновлення

Крок A — зачекати. Він нічого не коштує, нічим не ризикує і залишає кожному клієнтові оновлення за його власним графіком. Крок B — примусово звільнити й оновити оренду на постраждалому клієнті: це одразу дає потрібну адресу, але перериває все, що клієнт робить. На одному комп'ютері примусове оновлення зазвичай швидше і його легко обґрунтувати. У лабораторії або на платіжному терміналі посеред транзакції очікування безпечніше, а заплановане оновлення поза робочими годинами краще за обидва варіанти.

ipconfig /all
ipconfig /release
ipconfig /renew

Прочитайте вивід, перш ніж щось звільняти. Якщо адреса, шлюз і DNS уже відповідають звичайному діапазону, клієнт відновився сам, а решта проблеми в іншому місці. На клієнті Linux еквівалент — звільнення й оновлення оренди через мережевий менеджер, а не адреса, виправлена вручну, інакше менеджер перезапише вашу зміну наступною подією.

Читайте пропозицію, а не лише адресу

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

tcpdump -ni any 'port 67 or port 68'

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

Де порівняння перевертається

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

Якщо постраждав лише один клієнт, а сусіди в порядку, правильно навпаки: змінна — це оренда цього клієнта, його резервування або поведінка його власного клієнта DHCP, а зміна на всьому майданчику — неправильний інструмент.

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

Запишіть процедуру виходу

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

Закінчіть підтвердженням ресурсу, а не адреси. Доступ до файлового сервера, розв'язання його імені та доступ до інтернету — це три окремі перевірки, і лише остання ніколи не викликала сумнівів.