Тест пребацивања: да ли опстаје успостављени 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

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