Раз уже зачепили IPv4 / IPv6 - логічно йти далі. Бо поки існує NAT, IPv4 точно ще поживе )
Протоколи для QA - NAT
Що я маю вам сказать.
NAT - це та сама магія, завдяки якій у вас вдома, в офісі і в половини світу все ще працює IPv4, хоча адрес давно не вистачає.
NAT якшо повністью і я не помеляюсь то це (Network Address Translation) - це коли багато внутрішніх пристроїв сидять за однією зовнішньою IP-адресою.
Світ бачить один IP, а всередині - цілий зоопарк: ноут, телефон, тестовий сервер, Docker, VM.
І от тут починаються ті самі “дивні” QA-баги.
І чому саме КУА тут причому)
Бо NAT дуже часто пояснює кейси типу:
- “у мене працює, у клієнта ні”
- “через VPN ок, без VPN - таймаут”
- “з мобільного не працює, з Wi-Fi працює”
- “сервер бачить всі запити з одного IP”
- “callback не доходить”
якщо по факту:
NAT ламає ілюзію прямого з’єднання.
і що саме відбувається
умовно клієнт має приватну IP (192.168.x.x / 10.x.x.x) і NAT міняє її на одну публічну далі сервер відповідає не “тобі”, а через NAT назад, якщо щось у цьому ланцюжку не так - привіт таймаути
Особливо боляче NAT б’є по: WebSocket / VoIP / WebRTC/ callbacks / webhooks чи rate limit по IP. security-логіці “1 IP = 1 user”
Класика коли
“Ми обмежили 5 запитів з IP”
А потім - весь офіс сидить за одним NAT)
Дам вам пару базових речей
Подивитись свою публічну IP:
curl ifconfig.me
Подивитись локальну:
ip a
Зрозуміти, чи є NAT:
локальна IP ≠ публічна IP → NAT є
Перевірити, як сервер бачить клієнта:
логи
X-Forwarded-For
X-Real-IP
І тут важливий момент
Для IPv6 NAT може взагалі не бути.
І саме тому: що через IPv6 працює, через IPv4 + NAT - ні
І це не баг коду.
Це маршрут.
Що я хочу до вас донести
QA не зобов’язаний налаштовувати NAT.
Але QA зобов’язаний розуміти, що він є і що він робить.
Бо дуже багато “дивних” проблем - це не бекенд, не фронт і не тест.
Це NAT тихо стоїть посередині і ламає логіку.
Всім стабільних конектів
і поменше “а чого тільки з цього офісу не працює”
Обняв
Сильні 💛