Загуба на 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 екземпляр.