Потеря Ping в VPN: группируйте запросы Echo до процента

Одна запись содержит шесть запросов Echo и три ответа, и кто-то пишет в тикете о потере 50 процентов пакетов. Это число может быть верным для записи и неверным для туннеля. Шесть запросов могут относиться к двум разным разговорам с двумя разными договорами доставки. Сгруппируйте их до деления, и соотношение перестанет быть интересной частью отчёта.

Шаг 1: разделите потоки по источнику и назначению

Запрос Echo несёт источник и назначение, и эти два поля определяют, к какому разговору он относится. Зонд, созданный шлюзом, использует адрес туннеля шлюза, а зонд, пересланный от имени хоста LAN, сохраняет адрес этого хоста. У дальней стороны может быть обратный маршрут для одного и не быть для другого, из-за чего две группы ведут себя по-разному по причинам, не связанным с туннелем.

Разделите запись по этим полям, прежде чем что-либо считать, и оставьте назначение частью ключа. Два потока к разным партнёрам несравнимы, даже если у них общий источник.

Запишите группы с их количеством, потому что следующий шаг решает, какие ответы к какой группе относятся. Группа с тремя запросами и без подходящего ответа — это находка. Группа с тремя запросами и тремя ответами — это базовая линия.

Шаг 2: сопоставьте по идентификатору и последовательности

Формат Echo в RFC 792 несёт идентификатор и номер последовательности и рассматривает их как поля, которые связывают ответ с его запросом. Для этой работы нужны оба. Один номер последовательности не уникален, поскольку разные отправители или процессы могут повторно использовать одно и то же значение в одном окне записи. Идентификатор сужает отправителя, а последовательность — позицию, и именно пара вместе делает сопоставление защитимым.

Ответ меняет направление адресов своего запроса, поэтому сопоставление — это пара запрос-ответ, а не два одинаковых кортежа. Сравните источник запроса с назначением ответа и назначение запроса с источником ответа, затем подтвердите, что идентификатор и последовательность совпадают.

Сохраните и окно наблюдения, потому что длинная запись может содержать законное повторное использование обоих полей. Сокращение окна до одного всплеска убирает большую часть этой неоднозначности. Это также делает подсчёты воспроизводимыми для каждого, кто читает тикет.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Шаг 3: сравните кортежи на одной границе

Если трансляция сетевых адресов находится между точкой записи и партнёром, адреса в запросе и ответе будут различаться по замыслу. Сравните кортежи на одной границе, или переносите сопоставление явно, чтобы разница была учтена. Смешивание запросов до трансляции с ответами после трансляции создаёт несоответствия, которых никогда не было на проводе.

Определите границу до начала подсчёта и укажите её в отчёте, чтобы следующий человек мог воспроизвести группировку. Одна запись на стороне клиента и другая на стороне сервера — это две разные границы. Каждая отвечает на свой вопрос о том, где исчез ответ.

Группа переведённых зондов также наследует собственное состояние устройства перевода, которое может быть настоящей причиной того, что ответ никогда не приходит. Проверьте это состояние, прежде чем винить путь за ним.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Шаг 4: скажите, что запись может и чего не может доказать

Наблюдаемый пробел не доказывает, что удалённый хост молчал. Точка записи может видеть только одно направление, фильтр может отбросить ответ, или буфер мог переполниться за время окна. Каждое из этого даёт одно и то же отсутствие и разный вывод.

Запишите место записи, выражение фильтра и счётчики отбрасывания рядом с подсчётами, потому что соотношение без них нельзя проверить. Именно эти три строки делают число защитимым позже.

Затем отделите то, что наблюдение устанавливает, от того, что оно предполагает, в двух предложениях вместо одного. Первое предложение указывает подсчёты и границу. Второе указывает гипотезу и то, что её подтвердит.

Когда вопрос в том, отбрасывает ли конкретный путь пакеты, контролируемый зонд с явным адресом источника — более сильное доказательство, чем пассивный подсчёт смешанного трафика. Отправьте его с той же машины, в то же время, тому же партнёру. Измените одну переменную, и сравнение сохраняется.

Сообщите группы и следующую границу

В отчёте три строки: определение группы, сопоставленные подсчёты внутри каждой группы и граница, на которой сделано сравнение. Тогда читатель видит, что одна группа ответила полностью, а другая нет, что указывает на маршрут или разрешение, а не на случайную потерю.

Приложите файл записи и выражения фильтров, чтобы группировку можно было воспроизвести. Сводка без файла — это утверждение, а не результат.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Когда одна группа показывает пять ответов, а другая ни одного, находка в том, что у одного источника есть работающий обратный маршрут, а у другого нет. Это гораздо лучший тикет, чем смешанный процент, и он направляет следующую проверку на обратный маршрут, а не на несвязанный экземпляр VPN.