راینو

در پایان این درس باید بتوانی

VPN را از NAT و ACL جدا کنی
Tunnel را به‌عنوان Encapsulation منطقی توضیح بدهی
Remote Access را از Site-to-Site تشخیص بدهی
Underlay و Overlay را در مسیر VPN تفکیک کنی
Failure اینترنت را با Failure VPN اشتباه نگیری

VPN و شبکه غیرقابل اعتماد

VPN برای انتقال Traffic خصوصی روی یک Transport عمومی یا مشترک استفاده می‌شود. نکته اصلی این است که Endpointهای VPN قبل از ایجاد Tunnel باید از طریق Underlay به هم Reachability داشته باشند. اگر Edge Router اینترنت ندارد، تغییر Encryption Parameter Tunnel معمولاً مشکل را حل نمی‌کند.

VPN می‌تواند Confidentiality، Integrity و Authentication را با Mechanismهای امنیتی فراهم کند، اما نوع و سطح حفاظت به Protocol و Policy وابسته است. کلمه VPN به‌تنهایی تضمین نمی‌کند همه Traffic Encrypt شده یا همه مقصدها از Tunnel عبور می‌کنند.

مدل Site-to-Site

Private LAN -> VPN Gateway == Encrypted Tunnel == VPN Gateway -> Private LAN

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

Remote Access VPN

در Remote Access، یک User یا Device بیرون سازمان معمولاً با VPN Client به Gateway سازمان متصل می‌شود. پس از Authentication و ایجاد Session، Client می‌تواند به Resourceهای مجاز داخلی دسترسی بگیرد. Policy ممکن است Full Tunnel باشد که بیشتر Traffic را از VPN می‌فرستد یا Split Tunnel باشد که فقط Prefixهای مشخص سازمانی را وارد Tunnel می‌کند.

در Troubleshooting باید Client Internet Access، DNS، Credential/MFA، Reachability به VPN Gateway، Tunnel State و Routeهای پس از اتصال را جدا بررسی کنی. Login موفق به معنی Reachability همه Serverهای داخلی نیست.

Remote Access

Remote User -> Internet -> VPN Gateway -> Internal Resources

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

Site-to-Site VPN

در Site-to-Site معمولاً دو Gateway شبکه‌های جدا را به هم متصل می‌کنند و Hostهای داخل شعبه‌ها بدون اجرای VPN Client اختصاصی از Tunnel استفاده می‌کنند. Traffic Selector یا Policy تعیین می‌کند کدام Subnetها باید محافظت شوند.

اگر شعبه A با 10.10.0.0/16 و شعبه B با 10.20.0.0/16 متصل شوند، Route و Policy هر دو سمت باید با Prefixهای واقعی هماهنگ باشند. Overlap Addressing یکی از مشکلات جدی طراحی است، چون دو طرف ممکن است یک Subnet یکسان داشته باشند.

Site-to-Site

Branch-A 10.10.0.0/16 -> VPN-GW-A == Tunnel == VPN-GW-B <- 10.20.0.0/16 Branch-B

پیاده‌سازی Site-to-Site VPN در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.

Underlay و Overlay

Underlay مسیر پایه‌ای است که VPN Endpointها را روی WAN/Internet به هم می‌رساند. Overlay ارتباط منطقی داخل Tunnel است. اگر Public IP طرف مقابل Ping یا Reachability لازم ندارد، ابتدا Underlay را بررسی کن. اگر Tunnel Up است ولی Prefix داخلی Reach نمی‌شود، Overlay Routing، Policy یا ACL مهم‌تر است.

این تفکیک کمک می‌کند هر Test هدف داشته باشد: Traceroute به Public Peer وضعیت Underlay را می‌سنجد؛ Ping با Source داخلی به Prefix Remote بیشتر Overlay را می‌سنجد.

دو لایه VPN

Underlay: Public-IP-A <-> Internet <-> Public-IP-B
Overlay: 10.10.0.0/16 <-> Tunnel <-> 10.20.0.0/16

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

Troubleshooting اولیه VPN

Runbook را با Scope شروع کن: یک User، یک Site، همه Tunnelها یا یک Prefix؟ سپس Underlay Reachability، Time/Certificate در صورت استفاده، Authentication، Tunnel State، Route و Policy را بررسی کن. در Remote Access، Client Log بسیار مهم است؛ در Site-to-Site، Counterهای Security Association و Packet Capture در Edge سرنخ می‌دهند.

اگر Tunnel Up است ولی Packet Counter افزایش ندارد، Traffic شاید به Selector نمی‌رسد یا Route غلط است. اگر Encrypt افزایش می‌یابد ولی Decrypt سمت مقابل نه، مسیر یا Policy بین Gatewayها را بررسی کن.

Runbook مفهومی

ping <peer-public-ip>
traceroute <peer-public-ip>
show ip route <remote-prefix>
show logging

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

سناریوی عملی

کاربران شعبه می‌گویند ERP مرکز قطع است اما اینترنت محلی کار می‌کند. Public Peer قابل دسترس و Tunnel Up است. Route به Prefix ERP اشتباه به Default Route می‌رود. مشکل Underlay یا Encryption نیست؛ Overlay Routing است.

اشتباهات رایج

اشتباه‌های رایج و علت آن‌ها

یکی دانستن VPN با Internet Connectivity
فرض اینکه Tunnel Up یعنی همه Prefixها Reachable هستند
نادیده گرفتن Overlap Addressing
شروع تغییر Crypto قبل از بررسی Underlay و Route

تمرین عملی

Remote Access و Site-to-Site را روی یک دیاگرام مقایسه کن
برای هر مدل Underlay و Overlay را علامت بزن
سه Failure را به Underlay/Authentication/Overlay دسته‌بندی کن
یک Runbook پنج‌مرحله‌ای VPN بنویس

نکته‌هایی که باید با خودت ببری

VPN ارتباط منطقی محافظت‌شده روی Transport دیگر است
Remote Access برای User/Device و Site-to-Site برای اتصال شبکه‌ها رایج است
Underlay باید قبل از Overlay سالم باشد
Tunnel State و Route/Policy هر دو مهم‌اند
Troubleshooting باید Failure Domain را جدا کند

خودسنجی

Underlay چیست؟

مسیر پایه‌ای که Endpointهای VPN را به هم می‌رساند.

Site-to-Site معمولاً چه چیزی را متصل می‌کند؟

دو شبکه از طریق Gatewayها.

Tunnel Up ولی Remote LAN قطع است؛ چه چیزهایی را بررسی می‌کنی؟

Route، Selector/Policy و ACL.

Remote Access به Client اختصاصی نیاز دارد؟

معمولاً Client یا قابلیت VPN در Device برای Session کاربر استفاده می‌شود.

منابع رسمی

منابع مرجع این درس

مطالعه همیشه آزاد است

برای ذخیره پیشرفت وارد حساب شو

حساب کاربری برای آزمون و ثبت مرحله‌ها استفاده می‌شود

ورود یا ثبت‌نام

بازگشت به صفحه دوره CCNA