Тест перемикання: чи виживає встановлений потік TCP?

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

Два результати сховані у фразі «резерв працює». Новий запит завершується успішно — це відновлення. Передача, що вже триває, продовжується — це безперервність. Це різні обіцянки, і більшість схем перемикання дають першу, а друга тихо завершується за тайм-аутом. Вирішіть, яка потрібна вам, перш ніж обирати механізм, і напишіть тест так, щоб він міг їх розрізнити.

Два результати, що виглядають як один успіх

Уявіть клієнта з адресою 10.90.0.42 і з'єднанням до 198.51.100.20:443. Основний вихід перетворює це на одну публічну адресу й порт, а резервний вихід — на іншу. Внутрішня адреса клієнта ніколи не змінюється, тому люди очікують, що з'єднання виживе.

Сервер не бачить внутрішньої адреси. Він бачить перетворену кінцеву точку, і після перемикання ця точка інша.

Тому старий потік завершується за тайм-аутом, а нове з'єднання до того ж сервісу працює одразу. Обидва спостереження правдиві одночасно.

Що бачить сервер, коли вихід змінюється

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

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

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

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Чому однієї публічної адреси недостатньо

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

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

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

Вирішіть, наскільки жорстка вимога

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

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

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

Перевірте старий потік і новий запит

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

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

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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

Схожі статті