Чучуть поговоримо про протоколи?
Протоколи для QA - IPsec
Що я маю вам сказать.
Поговоримо сьогодні про IPsec - це не “ще один протокол”.
Це рівень безпеки для мережі, а не для апки.
IPsec = захищений тунель між мережами або хостами.
Не HTTP, не API, не UI - а саме IP-рівень.
Його ви зустрічаєте там, де: VPN між офісами, доступ до внутрішніх сервісів, або прод працює, а локально “не конектиться” чи API відкривається тільки з певної мережі
І тут КУА дуже часто впирається в стіну.
Тут дуже важливо зрозуміти КУА що IPsec працює нижче, ніж: HTTP/ HTTPS/ TCP і навіть firewall rules апки
Тобто:
якщо IPsec не піднявся - ніякий curl, Postman і “перезапусти сервіс” не допоможуть.
Типові симптоми IPsec-проблем, з офісу все працює, з дому - ні(і ви точно таке бачили) або ping не йде, але DNS резолвиться чи timeout без логів у бекенді даже сервіс “живий”, але недоступний або API доступний тільки через VPN
І це не баг бекенду.
Це мережа.
Шо ви як куа можете і повині перевірити в тому чи іншому випадку)
Подивитись, чи є IPsec-тунель:
ipsec status
Або (залежить від реалізації):
ip xfrm state
Чи є маршрути через тунель:
ip route
Чи йде трафік взагалі:
ping internal-ip
Перевірити, що трафік шифрується:
tcpdump -i any esp
(ESP = Encapsulating Security Payload - серце IPsec)
це must-have для QA - Бо без розуміння IPsec QA: валить баги “не працює”, чує від інфри “це не до нас”, і не може довести, де саме проблема
А з розумінням - ви чітко кажете: тунель не піднявся, або маршрут не пішов через IPsec, або трафік блочиться ще до сервісу
куа не зобов’язаний його налаштовувати.
Але зобов’язаний розуміти, коли проблема саме там.
Бо інакше половина “дивних” багів так і залишаться магією.
Всім стабільних тунелів і мінімум таймаутів.
Обняв🤗