افت بسته 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 بی‌ربط.