Слухайте, хочу вам розказати як я вчора в 10 веччері попав на фокап , і коли ти думаєшь «Чорт, а я ж думав, що знаю мережі» ))
Ранкові QA-історія: як же іх давно не було ТАК???
Тестував я інтеграцію між двома сервісами.
Умовно Сервер Х шле запити на Сервер Y - і раптом половина викликів тупо падає в таймаут. Без помилок. Без 5xx. Просто тиша.
Ну окей, думаю
«Зараз три каманди в терміналі - і розберемося».
Ага… як же ж
Ну перевірка, як завжди, з очевидного
Це - nc
nc -vz server-y 9090
конект є, все красиво.
як же без telnet
telnet server-y 9090
- всі помьятають шо він робе так?
і теж ок.
ну і сurl
curl -v http://server-y:9090/health
і тут вже починається «вічне завантаження»… і Потім timeout.
Тобто дістатися можна, а відповіді нема.
Так-так, це той самий момент, коли мозок каже: «ооо, походу буде весело».
Короче поліз я далі
Тобто сервері Y сервіс живий:
Спробуємо
sudo ss -tulnp | grep 9090
У логах видно, що запит прийшов і навіть була сформована відповідь, і трафік на вихід теж є - tcpdump підтвердив.
І тут уже зрозумів:
проблема не на стороні Y, відповідь відправляється.
І ось тут почалося цікаве
На сервері X зняв дамп:
Через
sudo tcpdump -i eth0 host server-y -w debug.pcap
Відкриваю у Wireshark.
І реально видно:
SYN → SYN-ACK → ACK → запит полетів → а назад пакетів НУЛЬ.
Не дроп, не RST, не ICMP. Просто… нічого.
Як у чорну діру.
тобто розгадка яка (після години матюків і інфри)
Виявилось, що сервер X після міграції в інший датацентр отримав новий набір правил фаєрвола.
І там було правило типу: - дозволити вихід на порт 9090, але заборонити вхідні пакети з цього діапазону IP
Тобто:
- вийти можна
- повернутись не можна
І curl зависав, бо пакет-відповідь просто рубився фаєрволом ще до додатку.
Шо я маю вам сказать:
Не ведіться на «telnet працює - значить все добре».
Telnet і nc показують тільки те, що можна достукатись,
А не те, що відповідь повернеться назад.
Фаєрволи інколи працюють за принципом:
«Випущу. Але назад не пущу.»
І це найпідліший тип багів.
Всім гарного дня і настрою!
Обняв, друзі 🤗🤗🤗