Спрацоўвае аварыйны выключальнік: што адбываецца з адкрытымі TCP-сесіямі?

Тунэль абрываецца, аварыйны выключальнік спрацоўвае, і загрузка, завершаная на тры чвэрці, альбо замірае, альбо адразу зрываецца. Гэтыя два вынікі паходзяць з розных рашэнняў у рэалізацыі, а не з розных узроўняў абароны. Адкінуты пакет пакідае злучэнне ў чаканні, а адхілены — закрывае яго і паведамляе праграме. Вырашыць, якія паводзіны вам патрэбныя, — гэта пытанне праектавання, а праверыць яго — асобнае практыкаванне.

Адкіданне, адхіленне і скід — розныя рэчы

Правіла міжсеткавага экрана, якое адкідвае трафік, выкідвае пакет і нічога не вяртае, таму адпраўнік працягвае паўтараць спробы па сваіх таймерах. Правіла, якое адхіляе скідам TCP, закрывае злучэнне адразу, і праграма бачыць памылку. Большасць аварыйных выключальнікаў адкідвае, бо адхіленне раскрыла б палітыку і таму што адкіданне падобнае да паводзін мёртвай сеткі.

Блакаванне — гэта таксама не тое самае, што закрыццё сокета. Праграма ўсё яшчэ трымае дэскрыптар у ўсталяваным стане, і адсутнічаюць толькі пакеты. Таму старонка можа доўгія хвіліны круціць індыкатар, пакуль аперацыйная сістэма сцвярджае, што злучэнне існуе. Чытайце дакументаваную рэалізацыю, а не рабіце высновы з паведамлення праграмы, бо абодва паводзіны выглядаюць як адключэнне сеткі.

Што рабіць праграме, пакуль доўжыцца прамежак

TCP паўтарае перадачу з павелічэннем затрымак, і стандартны бюджэт паўтораў у Linux заканчваецца дзесьці каля чвэрці гадзіны, а не за секунды. Да гэтага часу сокет не ёсць ні карысна адкрытым, ні закрытым. Праграмы з уласнымі keepalive або тайм-аўтамі запытаў часта здаюцца раней, таму дзве праграмы на адной машыне паводзяць сябе па-рознаму падчас аднаго збою.

Калі тунэль вяртаецца, лакальны сокет не змяніўся, а шлях можа і не. Новы публічны адрас крыніцы дае іншы чатырохчасткавы набор на серверы, таму міжсеткавы экран са станам на далёкім баку ўжо не адпавядае сесіі. Злучэнне мёртвае, хаця кліент так і не ўбачыў памылкі.

Вырашыце, ці патрэбна аднаўленне

Выберыце паміж двума дагаворамі. Альбо сесія павінна перажыць кароткі прамежак, што патрабуе стабільнай адрасацыі і сервера, які захоўвае стан, альбо праграма павінна чыста перападключыцца, што патрабуе логікі паўтораў, бяспечнай для паўтарэння. Усё паміж імі дае найгоршы вынік: кліент, які паўторна адпраўляе тое, што сервер ужо зафіксаваў, або кліент, які паведамляе пра поспех для сесіі, якую ніхто не бачыць.

Стабільная адрасацыя — гэта частка, якую забываюць, бо перападключэнне на іншы публічны адрас робіць стан на баку сервера несапраўдным, нават калі сокет кліента выглядае здаровым. Запішыце, які з двух дагавораў датычыцца кожнай праграмы, бо яны рэдка супадаюць усе.

Праверце блакаванне і аднаўленне асобна

Разглядайце абарону ад уцечак і выжыванне сесіі як дзве ўласцівасці, бо праходжанне адной нічога не кажа пра другую. Сесія, якая выжыла, не доказ таго, што прамы трафік быў заблакаваны, а сесія, якая памерла, не доказ таго, што кожны прамы маршрут быў заблакаваны.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Пры назіранні за аднаўленнем выкарыстоўвайце бясшкодную тэставую аперацыю, каб паўторная адпраўка не стала самім інцыдэнтам. Запішыце рэжым збою, які вы сапраўды бачылі: што паказала праграма, ці выжыў сокет і калі ён аднавіўся сам.

Напішыце чаканыя паводзіны побач з правілам рэалізацыі і пастаўце дату. Наступны чалавек, які зменіць гэтае правіла, павінен ведаць, які з двух дагавораў абяцала разгортванне.