Губење на 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 инстанца.