Страты Ping у VPN: групуйце запыты Echo перад працэнтам
Шэсць запытаў і тры адказы не даюць падстаў гаварыць пра 50 працэнтаў страт. Групуйце рэха па крыніцы, ідэнтыфікатары і паслядоўнасці, перш чым дзяліць.
У захопе шэсць запытаў 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.