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

ترتیب مهم‌تر از فهرست است.

بررسی 1: تعیین کنید تونل باید چه چیزی را حمل کند

Azure VPN Gateway تونل را پایان می‌دهد و ترافیکی را که به VNet تعلق دارد ارسال می‌کند؛ اینیک خروجی عمومی اینترنت نیست. اگر کاربران انتظار دارند مرورشان از Azure خارج شود، طراحی پیش از آنکه هر تنظیم کلاینت وارد شود اشتباه است. split tunneling را فعال کنید تا اینترنت محلی بر مسیر محلی بماند، و وقتی نشانی خروجی ثابت واقعاً لازم است از نمونه NAT یا تونل سایت به سایت استفاده کنید.

پیش از آنکه چیزی را آزمایش کنید بنویسید کلاینت باید به کجا برسد. بدون آن فهرست، هر نتیجه جزئی شبیه پیشرفت به نظر می‌رسد.

بررسی 2: فضاهای نشانی را پیش از گواهی‌ها مقایسه کنید

همپوشانی بر پایه محدوده‌های گسترده‌تر داوری می‌شود، پس دو شبکه‌ای که در سطح زیرشبکه متفاوت به نظر می‌رسند اگر بلوک‌های والدشان همپوشانی داشته باشند باز هم برخورد می‌کنند. زیرشبکه دروازه باید اختصاصی و به اندازه کافی برای SKU بزرگ باشد، و استخر نشانی کلاینت نباید با VNet یا با چیزی که از طریق peering قابل دسترسی است برخورد کند. طرح را تغییر دهید و دوباره مستقر کنید، چون افزودن مسیرها برای جبران تونلی می‌سازد که برای برخی مقاصد کار می‌کند و به شکلی توضیح‌ناپذیر برای برخی دیگر نه. تأمین در اینجا با صدای بلند شکست می‌خورد، و این همان حالت خوب است.

احراز هویت دروازه بعدی است. پروفایل‌های گواهی، RADIUS و Entra ID قابل تعویض نیستند، و بسته کلاینت برای هرکدام متفاوت است.

بررسی 3: یک نام خصوصی را از داخل حل کنید

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

ابتدا یک نشانی را آزمایش کنید، چون این کار مسیریابی را در یک گام از نام‌گذاری جدا می‌کند: Test-NetConnection 10.20.1.4 -Port 3389.

اگر نشانی پاسخ داد و نام پاسخ نداد، مستقیماً از resolver بپرسید با Resolve-DnsName files.corp.example -Server 10.20.0.4. اگر هر دو شکست خوردند، خطا از DNS نیست و باید ویرایش تنظیمات DNS را متوقف کنید. DNS پلتفرم Azure در 168.63.129.16 فقط از داخل VNet پاسخ می‌دهد، پس کلاینتی در بیرون آن نمی‌تواند از آن نشانی به عنوان resolver استفاده کند.

بررسی 4: سرویس پشت تونل را آزمایش کنید

تونل سالم و درگاه بسته از دید کلاینت یکسان به نظر می‌رسند. فایروال مهمان را بررسی کنید، سپس گروه امنیت شبکه روی زیرشبکه یا NIC، سپس اینکه سرویس روی نشانی خصوصی گوش می‌دهد نه فقط روی loopback. به جای باز کردن قاعده‌ای به اینترنت، استخر کلاینت را به عنوان منبع مجاز کنید، و به یاد داشته باشید که SMB به Azure Files به مسیر endpoint خصوصی که از تونل عبور می‌کند نیاز دارد. وقتی منبعی با IP پاسخ می‌دهد اما با نام نه، به بررسی 3 برگردید نه اینکه دروازه را دست بزنید.

یک جدول لایه‌ها را هنگام کار از هم جدا نگه می‌دارد:

SymptomLayer to check
Name fails, private IP worksResolver setting or forwarder
Private IP also failsAddress plan, NSG, guest firewall
Private works, internet failsExpected; the gateway is not an egress
Connects, then dropsTunnel type or certificate mismatch

بررسی 5: پیش از ارجاع، پروفایل را ثبت کنید

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

برای یک تیم کوچک، طراحی پایدار یک VNet، یک forwarder DNS و یک کلاینت split-tunnel مستند است. اگر الزام یک خروجی عمومی ثابت است، یک تونل سایت به سایت روی فایروالی که کنترل می‌کنید پایان دهید و ترافیک اینترنت را به آنجا مسیریابی کنید، به جای اینکه از دروازه نقطه به سایت چیزی بخواهید که هرگز برای آن ساخته نشده است.

مقالات مرتبط