Втрата 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.