Тест на префрлање: дали опстојува воспоставен 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 го опишува преведувањето на адреси и размената на состојба меѓу уредите што преведуваат ја смета за дел од резервно решение. Лебдечка адреса или копиран профил ја преместува конфигурацијата без да ја премести состојбата.

Затоа тест што само пингува низ резервата докажува многу малку. Пингот нема состојба на врска што може да ја загуби.

Одлучете колку е строго барањето

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

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

Кажете јасно што се случува кога примарниот пат ќе се врати, бидејќи автоматското враќање може да прекине врска што штотуку се обновила на резервата. Тој случај припаѓа во тест планот, а не во фуснота.

Проверете го стариот тек и новото барање

Започнете безопасен долг пренос низ примарниот пат, потоа одделно ново барање кон истиот сервис. Запишете го контекстот на апликацијата, забележаната излезна адреса и времето. Прекинете го примарниот пат на одобрен начин и продолжете да го набљудувате првичниот пренос додека го испраќате новото барање низ резервата.

Пријавете три вредности: дали стариот тек продолжи, се ресетираше или истече; кога новата операција првпат проработе; и дали враќањето прекина нешто. Тие три реда се прифатниот запис.

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

Ако работното оптоварување пишува податоци, не повторувајте неизвесна операција слепо по истекот. Записот можеби стигнал пред одговорот да се загуби. Прашајте ја апликацијата за резултатот или повторете само таму каде операцијата е идемпотентна. Потоа напишете ја изјавата за прифаќање во три дела: новите операции се обновуваат според политиката на излез, постојните текови имаат документирано однесување при прекин, и апликацијата безбедно продолжува. Таа изјава е проверлива и е чесна за тоа што решението не го ветува.