VPN се поново повезао, али сесија апликације и даље пада
Поновно повезивање враћа руте, не стање утичнице. Пошаљите један нови захтев док стари још виси и знаћете које је од два покварило.
Тунел се враћа, клијент каже да је повезан, а прегледач се још врти на страници коју је учитавао пре прекида. Поновно повезивање VPN-а враћа пут и не враћа стање везе које су апликације и удаљена страна накупиле на старом путу. То су различите ствари за поправку и њихово мешање вас враћа у VPN поставке без разлога.
Један тест их чисто раздваја и траје десет секунди. Пошаљите нови захтев на исто одредиште док стари виси.
Шта преживи поновно повезивање, а шта не
Тунел је скуп рута, кључева и адреса, а поновно повезивање може обновити све три док сваки успостављени ток остаје мртав. Оперативни систем држи утичницу отвореном јер ју је апликација затражила, а рок те утичнице може бити удаљен минуте или сате. Испод тога је партнер заборавио ток, унос превођења је истекао, или пут сада пролази кроз крајњу тачку која никада није видела руковање. Ништа у следу поновног повезивања не пролази кроз утичнице апликације и не поправља их.
Неки клијенти додају куку која одбацује застареле везе при поновном повезивању, а већина не. Понашање овде зависи од клијента, платформе и верзије.
Удаљена страна је заборавила и вас
Далеки крај држи сопствено стање: TLS сесију, TCP контролни блок и вероватно унос пресликавања који везује вашу адресу и порт за ток. Уређај за превођење на путу може пустити тај унос да истекне током прекида, чак и кад се тунел брзо успостави. Кад унос нестане, пакети долазе за ток који сервер више не препознаје, а одговор може бити ресет који клијент никада не покаже. Апликације то пријављују као застој, а не као грешку, јер још чекају утичницу која никада неће одговорити.
Рокови мировања на страни сервера раде исто по сопственом распореду, због чега сесија може умрети без икаквог мрежног догађаја. Веза која је мировала дуже него што сервер очекује већ је нестала пре него што приметите да се тунел померио.
Нови захтев је тест који их раздваја
Пошаљите нови захтев на исти хост док стари још виси и гледајте оба. Ако нови захтев успе, тунел, рута и разрешавање имена раде, а квар је ограничен на застарели ток. Ако и нови захтев падне, имате проблем с путем и стање сесије апликације је лажни траг.
Задржите сваки блок директног саобраћаја на месту током теста. Захтев који успе кроз случајни резервни пут не доказује ништа о тунелу.
Потврдите новом везом, не старом
Наредбе испод показују утичнице које су још отворене, покрећу један нови захтев и проверавају држи ли табела сесија још унос за ток. Покрените прву пре и после поновног повезивања да разлика буде видљива. Замените хост и порт својом услугом.
ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com
Успостављена утичница без саобраћаја који се креће је потпис који тражите, а нови захтев који враћа статусни код показује да је пут жив. Табела веза одговара пресликава ли ишта још ток, а то је део који клијент не може видети. Упит према разрешивачу покрива другу половину учитавања странице, јер неуспех имена и заглављена веза у прегледачу изгледају једнако. Заједно, та четири излаза раздвајају застарелу сесију од поквареног тунела.
Забележите време прекида, време поновног повезивања и разлику између старог и новог захтева. Тај запис претвара нејасну притужбу у извештај на који се неко може ослонити.