Чому результати сканування портів змінюються за виходом VPN?
Змініть вихід, і порт може відповісти інакше, навіть якщо служба не зрушила. Відокремте спостереження шляху від інвентарю, який вам справді потрібен.
Запустіть ту саму перевірку порту з офісної лінії та з виходу VPN, і дві відповіді можуть розійтися щодо адреси, яку ніхто не змінював. Ця розбіжність походить від маршруту та від того, який хост відповів, а не від того, чи працює служба. Три питання розділяють ці пояснення: що насправді запитала проба, який хост відповів і що записав ваш власний сервер. Пройдіть їх у цьому порядку й запишіть кожну відповідь, перш ніж перейти до наступної.
Виправте пробу, перш ніж порівнювати два запуски
Слово стану можна порівнювати з іншим словом стану лише тоді, коли обидва вийшли з одного експерименту. П’ять полів фіксують це: адреса джерела, яку побачила далека сторона, розв’язаний пункт призначення, порт, тип сканування й час. Змініть будь-яке з них, і ви провели другий експеримент замість того, щоб двічі виміряти перший.
Перевірте джерело передусім, бо клієнт VPN може працювати, а трафік ще виходить через фізичний інтерфейс. Запитайте далеку сторону, що вона бачить, потім запитайте ядро, який інтерфейс воно вибрало:
curl -s https://ifconfig.me
ip route get 203.0.113.20Дві адреси в різних мережах означають, що пояснення вже в руках, і решта цих перевірок лише підтвердить його. Коли вони збігаються, зафіксуйте пробу з увімкненим прапорцем причини, щоб стан повертався прив’язаним до пояснення, а не стояв сам як голе слово. Тип сканування також належить до цього запису, бо описує, що запитали, а не що повернулося. Стан без джерела, без методу й без позначки часу не можна порівняти ні з чим:
nmap -sT -p 443,8443 --reason 203.0.113.20Тримайте цей вивід поруч із записом, а не в буфері прокрутки, якого наступна людина не побачить. Два чесні сканування, що розходяться, є суперечкою лише тоді, коли ніхто не записав умови. Коли умови зафіксовано, або результати збігаються і питання закрите, або вони різняться, і різниця є фактом про шлях.
З’ясуйте, який хост завершив рукостискання
Завершене рукостискання доводить, що його завершив якийсь хост, і цей хост не обов’язково є процесом, який ви маєте на увазі. Балансувальник навантаження, зворотний проксі або SYN-проксі можуть відповісти раніше, ніж задіяний справжній сервер, і це звичайний дизайн, а не симптом. Дійсний сертифікат на очікуване ім’я теж цього не звужує, бо сертифікат описує відношення служби й нічого не каже про те, яка машина завершила з’єднання.
Довідник Nmap щодо станів портів вважає це базовим: стан фіксує те, що проба могла спостерігати з місця надсилання, а не властивість порту. Читайте слово стану так, і два запуски, що розходилися, починають виглядати узгодженими, а не суперечливими, тоді як питання зміщується з того, чи відкритий порт, на те, хто стояв перед ним.
Відповідайте на друге питання на бекенді, а не ззовні. Фронтенд, який приймає з’єднання, а потім не досягає свого upstream, дає саме зовнішню картину здорової служби з повільним застосунком. Лише власний запис upstream розділяє два випадки:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'Рядок журналу показує адресу клієнта, яку застосунок справді побачив, а друга команда показує, чи процес, що тримає порт 443, є вашим застосунком, чи чимось перед ним. Якщо ці двоє розходяться щодо того, яка адреса підключилася, ви дивитеся на дві ноги одного запиту, і в тікеті варто це сказати.
Перевірте власні правила, перш ніж звинувачувати тунель
Навмисна політика — найчастіша причина, чому порт відповідає в одній мережі й не відповідає в іншій, і це найменш цікаве доступне пояснення. Правила доступу існують, щоб дозволити одне джерело й відкинути решту, тому зміна виходу — саме та подія, для якої їх писали. Тож інший стан через VPN не показує, що провайдер перевіряє трафік. Він показує, що ваша адреса джерела тепер інша, а це значно менше твердження.
Ці правила можна прочитати на сервері, тож прочитайте їх, а не гадайте про середину мережі. Перелічіть правила фільтрації, які згадують будь-який із двох діапазонів адрес, потім перевірте, чи з’єднання взагалі дійшло до демона:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113Порожній другий результат інформативний, бо до демона нічого не дійшло, і питання належить фільтру, групі безпеки або самому шляху. Влучання означає, що служба побачила ваше джерело й вибрала свою відповідь, і це рішення зазвичай записане в правилі, яке можна прочитати. Жоден результат не підтримує історію про провайдера, і обидва дешевше перевірити, ніж перехопити пакети.
Читайте транспорт, сертифікат і відповідь окремо
Три шари дають три спостереження, і проба, що перевіряє одне з них, не може повідомити про два інші. Тримайте їх окремими рядками в записі, а не згортайте в один вердикт, бо кожен рядок відмовляє по-своєму, і режим відмови каже, куди дивитися далі.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
Одна команда створює перші три рядки проти служби, якою ви керуєте. Покладіть її вивід у запис поруч зі скануванням, а не в повідомлення чату:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/Читайте вивід по порядку: рукостискання відповідає на питання транспорту, суб’єкт сертифіката — на питання імені, а тіло відповіді — на питання застосунку. Коли рядок рукостискання успішний, а рядок відповіді ні, у вас фронтенд зі зламаним upstream, а не заблокований порт. Це інший тікет, ніж той, який ви відкрили, і про це варто сказати прямо.
Завершіть, записавши в тікет чотири факти: адресу джерела, тип сканування, хост, що відповів, і час. Усе, що потрібне пізнішому порівнянню, живе в цих чотирьох, і в того, хто візьме справу далі, не буде історії вашого термінала. Якщо ви не можете заповнити всі чотири, запуск не завершено.