Шлюз чи переадресований клієнт? Як читати адресу джерела

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

Що насправді бачить призначення

Візьміть клієнта за адресою 10.20.0.7, шлюз із зовнішньою адресою 198.51.100.10 і призначення в інтернеті. Якщо шлюз транслює джерело клієнта, сокет призначення записує 198.51.100.10. Приватна адреса зникає з пакета, і призначення не може прочитати її назад із цього заголовка. Ці числа ілюстративні, а не запис із вашої мережі.

Спостереження все ще корисне: воно визначає мережеве джерело, яке призначення має дозволити або заблокувати. Воно просто не визначає людину чи процес за ним. Для оператора призначення ця різниця вирішує, чи блокування є мережевим рішенням, чи рішенням щодо облікового запису.

Стан трансляції не видно призначенню

Шлюз зберігає відповідність між трансльованим з'єднанням і початковим клієнтом, і саме цього стану призначенню бракує. традиційний опис NAT відокремлює запис трансляції від заголовків, видимих згодом. Читання одного боку не дає іншого.

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

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL і відбитки — це підказки, а не докази

TTL в IPv4 залежить від початкового значення, вибраного відправником, і від кількості переходів, які пройшов пакет. Без обох фактів значення не може довести, що стався перехід VPN. Відомий додатковий маршрутизований перехід теж не дозволяє відрізнити маршрутизатор LAN, шлях тунелю чи іншу схему пересилання. Ставтеся до різниці TTL як до питання, а не висновку.

Інші сигнали поводяться так само. Заголовок User-Agent може встановити застосунок, а схожість у часі може відображати спільну інфраструктуру, а не спільну людину. Кілька користувачів можуть ділити один вихід, і один користувач може змінювати шлях між сеансами. Зібрані разом, кілька слабких сигналів можуть виправдати уважніший погляд на записи шлюзу, але від накопичення вони не стають сильними доказами.

Авторизуйте за ідентичністю, а не за адресою

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

Тримайте докази позначеними: спостережуване джерело, автентифікований обліковий запис, час і розглянутий висновок. Не перекладайте «тут не видно внутрішнього джерела» як «ніде не можливе віднесення». Позначка важлива, коли через місяці запис читає людина, яка не брала участі в розслідуванні.

Запишіть дату спостереження і систему, яка його створила. Фрагмент журналу без віднесення важко захистити пізніше.