Вялікія загрузкі супраць VPN: выбар шляху пры запыце

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

Чаму маршрутызатар не можа вызначыць памер адказу

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

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

Праверка 1: ці ёсць пункт рашэння, які можа выбраць шлях?

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

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

Праверка 2: што метададзеныя вам сапраўды кажуць?

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

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

Праверка 3: ці існуе паток ужо?

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

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

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

Праверка 4: ці сапраўднае патрабаванне — затрымка, а не выхад?

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

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

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

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