برداشت‌هایی که روی رابط تونل گرفته می‌شوند هرگز شناسه VLAN شعبه را نشان نمی‌دهند و این ویژگی طراحی است، نه کمبود ابزار. تونل TUN مسیریابی‌شده بسته‌های IP را حمل می‌کند، بنابراین فریم Ethernet برچسب‌خورده‌ای که آن‌ها را در پیوند شعبه حمل می‌کرد، در همان مسیریابی که آن‌ها را مسیریابی کرد پایان می‌یابد. اگر پرسش سیاست شما درباره بخش‌هاست، موقعیت حسگر باید پیش از آغاز برداشت برای همان پرسش انتخاب شود. فیلد VLAN که انتظارش را داشتید باید با زمینه‌ای جایگزین شود که بتوانید از آن دفاع کنید.

ببینید رابط تونل در واقع چه چیزی را حمل می‌کند

TUN بسته‌های IP را به میزبان تحویل می‌دهد؛ TAP فریم‌های Ethernet را تحویل می‌دهد. طراحی مسیریابی‌شده از اولی استفاده می‌کند، یعنی بسته‌ای که پس از رمزگشایی می‌رسد هیچ سرآیند لایه پیوند ندارد و بنابراین هیچ برچسب 802.1Q برای خواندن نیست. در مسیر چیزی حذف نشده است، چون برچسب هرگز وارد تونل نشد. بسته درونی از سرآیند IP خود آغاز می‌شود، پس هر فیلدی که یک قاعده آگاه از VLAN انتظار دارد به‌سادگی غایب است.

پیش از بحث درباره برداشت، نوع رابط را تأیید کنید، زیرا یک دستگاه TAP در همان استقرار رفتار متفاوتی خواهد داشت و شما را به نتیجه نادرست می‌رساند.

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

فرمان اول نوع دستگاه و پرچم‌هایش را چاپ می‌کند. دومی سرآیندهای لایه پیوند را برای بیست بسته نخست چاپ می‌کند و روی دستگاه TUN خروجی از IP بدون بلوک Ethernet آغاز می‌شود، که تمام توضیح در یک صفحه است.

انتخاب TAP نیز برچسب را بازنمی‌گرداند. دستگاه TAP فریم‌ها را به یک پل می‌فرستد و آنچه بر سر برچسب می‌آید به فیلتر VLAN پل و عضویت تنظیم‌شده پورت بستگی دارد. این یک تصمیم طراحی جداگانه با حالت‌های خرابی خاص خود است.

در یکی از سه جا بایستید و آنچه می‌تواند ببیند را بپذیرید

روی بخش Ethernet شعبه برچسب وجود دارد، اما حسگر تنها ترافیک محلی همان بخش را می‌بیند. در شبکه بیرونی VPN ترافیک محافظت‌شده است، بنابراین ناظر تنها نقاط پایانی و حجم را می‌آموزد و چیزی درباره بسته درونی نمی‌داند. در مسیر TUN پس از رمزگشایی، بسته IP درونی در دسترس است، با آدرس‌دهی و پورت‌هایش و بدون فریم شعبه. از این رو یک برداشت روی ترانک و یک برداشت مسیریابی‌شده از همان جریان مانند دو گفتگوی متفاوت به نظر می‌رسند.

آن سه موقعیت به سه پرسش متفاوت پاسخ می‌دهند و یک برداشت نمی‌تواند همزمان همه آن‌ها باشد.

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

این جفت را اجرا کنید و مقایسه کنید. اولی فریم‌های برچسب‌خورده و شناسه‌های VLAN آن‌ها را جایی نشان می‌دهد که پیوند شعبه به میزبان ترانک شده است؛ دومی همان گفتگو را پس از مسیریابی به صورت IP ساده نشان می‌دهد. اگر اولی هیچ چیزی برنگرداند، بررسی کنید که آیا پورت میزبان پورت دسترسی است، چون در آن صورت سوئیچ برچسب را از قبل حذف کرده و هیچ برداشتی روی میزبان هرگز آن را نشان نخواهد داد.

برچسب گمشده را با نقشه‌ای جایگزین کنید که بتوانید از آن دفاع کنید

اگر سیاست بخش‌ها را بر اساس پیشوند IP تفکیک می‌کند، آن نقشه را همراه با محدودیت‌هایش بنویسید. بازه‌های آدرس هم‌پوشان، ترجمه مبدأ و دروازه مشترک هر یک می‌توانند یک پیشوند را برای تشخیص این که بسته واقعاً از کجا آمده ناکافی کنند.

به رابط و بافت مسیریابی که کنترل می‌کنید اعتماد کنید، نه به برچسبی که کلاینت ارائه می‌دهد. فیلد سرآیندی که یک همتا می‌تواند تنظیم کند شاهد عضویت نیست و قاعده‌ای که آن را چنین می‌شمارد به‌سادگی دور زده می‌شود.

ip route get 10.20.30.40
ip -br addr show

فرمان اول رابط و منبعی را که هسته برای یک مقصد استفاده می‌کرد گزارش می‌دهد که نمای محلی اتصال به بخش است. دومی آدرس‌ها را به تفکیک رابط فهرست می‌کند تا پیشوندهای نقشه شما با واقعیت سنجیده شود، نه با نمودار.

پیش از اعتماد به نتیجه، مسیر برگشت و بار مفید را بررسی کنید

نقطه بازرسی‌ای که تنها یک جهت را می‌بیند نیمی از گفتگو را از دست می‌دهد و مسیریابی نامتقارن به محض دخالت VPN رایج است. پیش از آنکه یک برداشت یک‌طرفه را کامل بدانید، تأیید کنید که پاسخ‌ها از همان حسگر عبور می‌کنند.

بازیابی بسته IP درونی نیز یک نشست HTTPS درون آن را رمزگشایی نمی‌کند. اگر پرسش سیاست درباره محتوا باشد نه جریان‌ها، موقعیت حسگر باید دوباره جابه‌جا شود و آن تصمیم به همان سند طراحی تعلق دارد.

گسترش یک ترانک نامحدود تا یک حسگر فقط برای اینکه فیلد VLAN ظاهر شود، مرز شبکه را بزرگ می‌کند بدون پاسخ به پرسش اصلی. موقعیت را برای اطلاعاتی که سیاست نیاز دارد انتخاب کنید، آنچه نمی‌تواند ببیند را ثبت کنید و وقتی پرسش تغییر کرد انتخاب را بازبینی کنید.

مقالات مرتبط