جریان ترافیک Site-to-Site IPsec VPN

مسیر از LAN تا VPN Gateway

Host در Branch A Packet را برای Remote Subnet به Default Gateway می‌فرستد. شبکه باید Route داشته باشد تا Packet به VPN Gateway برسد. سپس VPN Policy تشخیص می‌دهد این Flow باید داخل IPsec محافظت شود. اگر Route به Peer اشتباه باشد یا Traffic به Gateway VPN نرسد، Crypto Policy هرگز Match نمی‌شود.

در برخی Designها VPN Gateway همان Internet Edge است و در برخی Firewall جداست. توپولوژی واقعی تعیین می‌کند کجا باید Route و Capture را بررسی کنی.

Host-A -> LAN GW -> VPN-GW-A -> Internet -> VPN-GW-B -> LAN GW -> Host-B

برای جریان ترافیک Site-to-Site IPsec VPN، فهم مسیر از LAN تا VPN Gateway باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

Traffic Selector و Prefix Match

Selectorها مشخص می‌کنند کدام Local/Remote Prefixها داخل Tunnel قرار می‌گیرند. اگر Branch A شبکه جدید 10.10.30.0/24 اضافه کند اما Selector طرف مقابل هنوز فقط 10.10.10.0/24 را بشناسد، Tunnel ممکن است Up بماند ولی شبکه جدید کار نکند.

هر دو Peer باید دید سازگار از Traffic مورد حفاظت داشته باشند. در Multi-Subnet Design مستندسازی Prefixها و Change Coordination ضروری است.

Local: 10.10.0.0/16
Remote: 10.20.0.0/16
Protected flow must match policy on both peers

برای تحلیل عملی Traffic Selector و Prefix Match یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در جریان ترافیک Site-to-Site IPsec VPN کمک می‌کند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحله‌ای شکست می‌خورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث می‌شود Troubleshooting حتی در شبکه‌ای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.

NAT و VPN Traffic

در Edgeهایی که هم NAT/PAT اینترنت و هم VPN دارند، Traffic بین Private Siteها معمولاً نباید مثل Internet Traffic PAT شود مگر طراحی خاصی وجود داشته باشد. Order of Operations و Syntax دقیق به Platform وابسته است، اما از دید Troubleshooting باید بررسی کنی Packet قبل از IPsec با آدرس مورد انتظار Match می‌شود یا NAT آن را تغییر داده است.

اگر فقط پس از اضافه شدن NAT Rule جدید VPN خراب شده، Interaction NAT/VPN فرضیه مهمی است. Config Diff و Packet Capture کمک می‌کند.

پیاده‌سازی NAT و VPN Traffic در شبکه شرکت باید به سه فاز Pre-check، Change و Post-check تقسیم شود. در Pre-check وضعیت فعلی، Dependencyها و مسیر مدیریت را ذخیره کن؛ در Change فقط Scope لازم را تغییر بده؛ در Post-check هم State فنی و هم سرویس کاربر را Verify کن. برای Changeهایی که ممکن است Access مدیریت، Routing یا Security را تحت تأثیر قرار دهند، Rollback را قبل از اجرای دستور بنویس و مسیر Recovery را مشخص کن. هدف این نیست که Configuration فقط از نظر Syntax پذیرفته شود؛ Desired State باید با Design، مستندات، Address Plan و Security Policy سازمان سازگار بماند.

Encrypt/Decrypt Counter و Return Path

اگر Encrypt Counter روی A افزایش می‌یابد ولی Decrypt روی B نه، Packet در Underlay یا Policy سمت B مشکل دارد. اگر B Decrypt می‌کند ولی Host-B پاسخ نمی‌دهد، LAN Routing/ACL/Host را بررسی کن. اگر پاسخ ساخته می‌شود اما Encrypt سمت B افزایش ندارد، Return Selector/Route مشکل دارد.

این Counterها بسیار قوی‌اند چون Failure Domain را از «کل VPN» به یک جهت مشخص کاهش می‌دهند.

A encrypt++ -> Internet -> B decrypt++
B encrypt++ -> Internet -> A decrypt++

در Verification مربوط به Encrypt/Decrypt Counter و Return Path، خروجی Command را به‌صورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان می‌دهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان می‌دهد Feature واقعاً چه می‌کند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در جریان ترافیک Site-to-Site IPsec VPN بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.

Troubleshooting Site-to-Site

با Source/Destination دقیق و Timestamp Test کن. Route به Remote Prefix، Tunnel/SA State و Counterها را در هر دو Peer ببین. سپس LAN ACL، Host Firewall و Return Route را بررسی کن. اگر Subnet جدید است، Selector و NAT Policy را با شبکه‌های قدیمی مقایسه کن.

اگر دو Site Address Space هم‌پوشان دارند، Troubleshooting به Change ساده ختم نمی‌شود؛ این یک Design Conflict است و ممکن است NAT خاص، Renumbering یا معماری دیگری لازم باشد.

show ip route <remote-subnet>
show logging
! Check platform-specific IPsec SA counters on both peers

مسیر Troubleshooting Troubleshooting Site-to-Site را با کم‌هزینه‌ترین Test شروع کن که بیشترین اطلاعات را می‌دهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیک‌ترین Boundary سالم به کاربر یا Source را پیدا کن و قدم‌به‌قدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بی‌دلیل دست‌کاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات می‌توانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.