VPN абрываецца падчас вялікіх загрузак: спачатку прачытайце чаргу

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

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

Змяняйце адну зменную за прагон і трымайце канчатковы пункт нязменным.

Пабудуйце паўторнае параўнанне нагрузкі

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

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

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

Чытайце чаргу, а не хуткасць

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

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

Праверце прыладу і шлях кіравання

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Тайм-аўт кліента таксама можа супасці з запланаванай перазаменай ключоў або з падзеяй палітыкі сеансу. Чытайце ўласны журнал кліента, каб даведацца парадак падзей, а не толькі паведамленне пра памылку праграмы.

Змяніце адно і паўтарыце

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

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

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

Падобныя артыкулы