Test prebacivanja: preživljava li uspostavljeni TCP tok?

Dva ishoda skrivaju se u rečenici da rezerva radi. Novi zahtjev uspijeva, to je oporavak. Prijenos koji već traje nastavlja se, to je kontinuitet. To su različita obećanja, a većina dizajna prebacivanja isporuči prvo dok drugo tiho istekne. Odlučite koje vam treba prije nego odaberete mehanizam i napišite test tako da ih može razlikovati.

Dva ishoda koja izgledaju kao jedan uspjeh

Zamislite klijenta na 10.90.0.42 s vezom prema 198.51.100.20:443. Primarni izlaz to prevodi u jednu javnu adresu i port, a rezervni izlaz u drugu. Unutarnja adresa klijenta nikad se ne mijenja, zato ljudi očekuju da će veza preživjeti.

Poslužitelj ne vidi unutarnju adresu. Vidi prevedenu krajnju točku, a ta je točka nakon prebacivanja drugačija.

Zato stari tok istekne, dok nova veza prema istoj usluzi radi odmah. Oba su zapažanja istodobno točna.

Što poslužitelj vidi kad se izlaz promijeni

TCP veza identificira se svojom četvorkom, a promjena izvorne adrese ili porta stvara drugu vezu sa stajališta hosta koji prima. Paketi koji dolaze s novog izvora na vezi koju poslužitelj ne poznaje odbacuju se ili se na njih odgovara resetom. Ništa u adresi VPN klijenta ne čuva povezanost kroz tu promjenu.

Prebacivanje sa stanjem postoji upravo da to izbjegne i radi razmjenom stanja prevođenja i stanja veza između uređaja za prosljeđivanje. To je svojstvo para, ne tunela, i mora se projektirati i testirati, a ne pretpostavljati.

Provjerite drži li par zaista stanje prije nego ikome obećate kontinuitet. Naredbe ispod pokazuju trenutačno stanje na obje strane.

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

Zašto ista javna adresa nije dovoljna

Zadržavanje jedne javne adrese na oba puta dobar je početak, jer poslužitelj tada vidi istu izvornu krajnju točku. Samo po sebi nije dovoljno. Uređaj za prosljeđivanje i dalje treba stanje prevođenja, stanje vatrozida i upotrebljiv povratni put, a to mora postojati na onom uređaju koji nakon prebacivanja nosi promet.

RFC 3022 opisuje prevođenje adresa i razmatra razmjenu stanja između uređaja koji prevode kao dio rezervnog dizajna. Lebdeća adresa ili kopirani profil prenosi konfiguraciju bez prijenosa stanja.

Zato test koji samo pinga kroz rezervu dokazuje vrlo malo. Ping nema stanje veze koje može izgubiti.

Odlučite koliko je zahtjev jak

Ako se korisnici mogu ponovno povezati nakon kvara, dizajn je dizajn oporavka i prihvatni test je novi zahtjev. Ako prijenos datoteke mora preživjeti, dizajnu treba sinkronizacija stanja i mnogo pažljiviji test. Ako udaljena sesija mora preživjeti, zahtjev je još jači i može trebati mehanizam na razini aplikacije umjesto onog na razini mreže.

Napišite zahtjev kao rečenicu s mjerljivim ishodom, na primjer da se upload završi bez ponovnog pokretanja ili da se operater ponovno poveže u roku od minute. Zatim odaberite najjeftiniji mehanizam koji ga zadovoljava, a to je često dizajn oporavka.

Jasno recite što se događa kad se primarni vrati, jer automatsko vraćanje može prekinuti vezu koja se upravo oporavila na rezervi. Taj slučaj pripada u testni plan, a ne u fusnotu.

Provjerite stari tok i novi zahtjev

Pokrenite bezopasan dugotrajan prijenos kroz primarni, zatim odvojen novi zahtjev prema istoj usluzi. Zabilježite kontekst aplikacije, uočenu izlaznu adresu i vrijeme. Prekinite primarni na odobren način i nastavite gledati izvorni prijenos dok šaljete novi zahtjev kroz rezervu.

Prijavite tri vrijednosti: je li stari tok nastavio, resetirao se ili istekao; kada je nova operacija prvi put uspjela; i je li vraćanje nešto prekinulo. Ta tri retka su prihvatni zapis.

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

Ako radno opterećenje piše podatke, ne ponavljajte nesigurnu operaciju naslijepo nakon isteka. Zapis je možda stigao prije nego što je odgovor nestao. Pitajte aplikaciju za rezultat ili ponovite samo tamo gdje je operacija idempotentna. Zatim napišite prihvatnu izjavu u tri dijela: nove operacije se oporavljaju prema politici izlaza, postojeći tokovi imaju dokumentirano ponašanje pri prekidu, a aplikacija se sigurno nastavlja. Ta je izjava provjerljiva i iskrena o tome što dizajn ne obećava.