Що насправді означає наскрізна доставка в мережах?

Коли люди говорять, що з'єднання «наскрізне», вони мають на увазі, що дані подорожують від первісної програми-джерела аж до програми-одержувача без того, щоб якийсь посередник мовчки їх переписав або перервав по дорозі. Звучить просто, доки ви не почнете відстежувати фактичний шлях пакета через NAT, брандмауери, балансувальники навантаження та проксі.

Принцип наскрізної доставки

Ця ідея походить із статті 1984 року авторства Saltzer, Reed та Clark, в якій обґрунтовувалось, що певні функції, такі як надійність та шифрування, повинні бути на кінцях мережі, а не в середині. Основна мережа повинна просто пересилати пакети. Кінцеві точки займаються перевіркою помилок, повторною передачею та впорядкуванням.

TCP — це найясніший приклад. Маршрутизатори в середині не відстежують номери послідовності та не підтверджують сегменти. Це робота двох хостів, на яких працюють стеки TCP. Мережевий рівень (IP) просто забезпечує доставку по принципу best-effort, а TCP на кожному кінці виправляє те, що втрачається або переупорядковується.

Де наскрізна доставка ламається сьогодні

Сучасні мережі постійно порушують цей принцип, зазвичай з поважних операційних причин:

• NAT переписує IP-адресу та порт джерела, тому пакет, який бачить сервер, — це не той пакет, який надіслав клієнт.
• Проксі з припиненням TLS та балансувальники навантаження (як AWS ALB або nginx reverse proxy) завершують один сеанс TCP/TLS та стартують новий. Фактичною кінцевою точкою клієнта є проксі, а не сервер програми.
• Stateful брандмауери відстежують стан з'єднання та можуть відкидати пакети, які не відповідають очікуваним послідовностям, фактично втручаючись у розмову.
• CGNAT на мережах ISP означає, що багато клієнтів ділять одну публічну IP-адресу, порушуючи припущення, що IP відповідає одному хосту.

Це матиме практичне значення, коли ви будете налагоджувати. Якщо користувач повідомляє «з'єднання розірвалось», вам потрібно знати, чи розірвалось воно на їхньому ноутбуку, їхньому домашньому маршрутизаторі, ISP, вузлі CDN, балансувальнику навантаження чи на сервері джерела. Наскрізне мислення змушує вас відстежити весь ланцюг замість того, щоб просто перевіряти власні логи сервера.

Тестування наскрізної зв'язності

Декілька інструментів, які насправді показують вам шлях, а не просто успіх/невдачу:

# Відстежити маршрут від вузла до вузла
traceroute 8.8.8.8

# На Linux, MTR дає постійну статистику для кожного вузла
mtr google.com

# Перевірити проблеми MTU, які фрагментують або мовчки відкидають пакети
ping -M do -s 1472 8.8.8.8

Ця остання команда варта глибокого розуміння. Відмови Path MTU discovery — це класична проблема «виглядає як наскрізна зв'язність, але насправді не є» проблема. Невеликі пакети на кшталт TCP SYN проходять добре, але як тільки ви надсилаєте повнорозмірний payload, якийсь вузол в середині мовчки його відкидає, оскільки він надто великий, а ICMP «fragmentation needed» блокується брандмауером. З'єднання зависає, і всі звинувачують програму.

Для TCP конкретно tcpdump або ss -ti на обох кінцях показують, чи навіть обидва хости погоджуються, що вони мають відкрите з'єднання:

ss -ti dst 203.0.113.5

Якщо одна сторона вважає, що з'єднання ESTABLISHED, а друга не показує нічого, щось в середині (зазвичай брандмауер, який припиняє неактивні з'єднання) мовчки його знищило.

Чому це матиме значення для безпеки

Наскрізне шифрування — це версія цієї ж концепції, релевантна для безпеки. TLS між браузером та вузлом CDN — це не те саме, що TLS між браузером та вашим сервером джерела. Якщо CDN припиняє TLS і пересилає plaintext (або свіже з'єднання TLS) вашому бекенду, у вас є два окремих зашифрованих переходи, а не один безперервний зашифрований канал. Це добре для більшості випадків, але якщо ви маєте справу з чимось чутливим, вам потрібно точно знати, де відбувається розшифровка та хто може бачити plaintext на кожному переході.

Та ж логіка застосовується до VPN. VPN із «full tunnel» дає вам наскрізне шифрування від вашого пристрою до вузла виходу VPN, але з'єднання від вузла виходу до фактичного сервера призначення — це окремий перехід зі своїми властивостями безпеки.

Практичний висновок

Коли хтось говорить, що мережевий шлях наскрізний, запитайте: наскрізний між якими двома точками саме? Клієнтом та балансувальником навантаження? Балансувальником навантаження та серверами програми? Назва фактичних кінцевих точок перетворює розпливчату мережеву заяву на щось, що ви можете протестувати з допомогою захоплення пакетів.

Якщо ви хочете глибше вивчити відстеження реального трафіку та читання захоплень пакетів, перегляньте сегменти Wireshark та TCP/IP fundamentals на платформі Korra Studio DEFENSE_GRID.