Популярні мережеві порти та сервіси

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

Що відбувається з пакетом або з’єднанням

Популярні мережеві порти та сервіси належить до транспортного або мережевого шляху. Розділяйте local socket, доставку IP, поведінку TCP/UDP, firewall і NAT. Успішний ping не гарантує доступність TCP-порту, а відкритий порт не доводить, що прикладний protocol працює правильно.

Де шукати блокування

Перевіряйте від ближнього до дальнього: process і bind address → local firewall → route → NAT/port forwarding → CGNAT або ISP filtering → external test. Для packet-size проблем окремо враховуйте MTU і Path MTU Discovery. Порт завжди читайте разом із transport protocol.

Контрольний сценарій

Контрольний сценарій: спочатку підтвердьте, що process слухає потрібний transport і bind address. Далі перевірте той самий endpoint локально, з іншого пристрою LAN і ззовні. Різниця між цими трьома точками локалізує host firewall, router/NAT або upstream filtering значно точніше, ніж багаторазове сканування одного порту з одного місця.

Конкретні приклади та значення

Використовуйте ці значення як орієнтири під час читання документації та результатів перевірки: 22 SSH; 25 SMTP; 53 DNS; 80 HTTP; 443 HTTPS; 3306 MySQL; TCP/UDP distinction.

Common defaults are 22/TCP for SSH, 25/TCP for SMTP, 53/UDP and 53/TCP for DNS, 80/TCP for HTTP and 443/TCP for HTTPS. A default port is a convention, not proof of the running application, and services can listen on nonstandard ports.

Типові причини та помилки

Поширена помилка — вважати один успішний тест доказом справності всього ланцюжка. Доступна IP-адреса не гарантує роботу DNS, відкритий порт не підтверджує правильний протокол застосунку, а високий результат speedtest не виключає затримку, втрати чи перевантаження Wi-Fi. NAT, CGNAT, firewall, CDN, Anycast і кеші також змінюють картину та мають враховуватися залежно від завдання.

Чого результат не доводить

Технічний результат має межі. Він зазвичай не встановлює особу користувача, власника пристрою або єдину причину збою без додаткових даних. Геолокація IP приблизна, реєстраційні дані можуть бути приховані, а маршрути змінюються. Безпеку також не можна зводити до одного прапорця, адреси чи статусу. Висновок має відповідати саме тій властивості, яку було виміряно.

Покрокова діагностика

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