Великі завантаження проти 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

Такий підхід до симптому залишає рішення про вихід там, куди його поставила політика безпеки, і його можна скасувати однією командою. Зміна виходу для цілого класу трафіку — це зміна політики з наслідками для автентифікації, журналювання та правил доступу, тож вона не повинна бути першим інструментом у скарзі на затримку.

Якщо вимога справді в іншому виході в інтернет, скажіть це тими словами й реалізуйте на підтримуваній межі: нове з’єднання зі схваленого робочого процесу або застосунок, який відкриває власний запит через вибраний вихід. Потім запишіть, які завдання використовують який вихід, щоб наступній людині не доводилося виводити це з таблиці маршрутизації.

Тримайте контрольний список у записі зміни: точку рішення, поле або завдання, що нею керує, чи існує потік уже і чи був виміряний симптом затримкою або виходом. Чотири питання, і політика, яка відповідає на всі чотири, — та, якою можна керувати, а не яку треба захищати.