VPN ویندوز عدد 255.255.255.255 را نشان می‌دهد: آیا ماسک اشتباه است؟
در تونل نقطه‌به‌نقطه، ماسک میزبان عادی است. مدل رابط را تأیید کنید، مسیر میزبان ناموفق را بخوانید و DNS را از دسترسی به سرویس جدا کنید.
تونل وصل می‌شود، جزئیات آداپتور را باز می‌کنید و ماسک 255.255.255.255 را نشان می‌دهد. در مقایسه با 255.255.255.0 شبکه محلی دفتر خراب به نظر می‌رسد و معمولاً خطا از همان‌جا شروع می‌شود. در پیوند نقطه‌به‌نقطه، ماسک میزبان توصیف درست انتهای محلی است و شبکه‌های دور به‌صورت مسیر می‌آیند نه زیرشبکه متصل. روش زیر دو پرسش را جدا می‌کند تا برای اصلاح یک مقدار نمایش‌داده‌شده، دامنه DHCP سالم را بازسازی نکنید.
پیوند نقطه‌به‌نقطه یک قطعه Ethernet نیست
رابط Ethernet به ماسک زیرشبکه نیاز دارد زیرا هر نشانی در آن محدوده به‌طور بالقوه روی همان کابل قابل دسترسی است. تونل به سبک PPP دقیقاً یک همتا در انتهای دیگر دارد. نه دامنه پخش وجود دارد، نه ARP و نه دلیلی که نشانی محلی محدوده‌ای را توصیف کند.
مذاکره نشانی برای این مدل در RFC 1332 تعریف شده است که توضیح می‌دهد دو سر چگونه درباره نشانی‌های خود توافق می‌کنند. کاری که نمی‌کند این است که شبکه محلی دفتر را به‌عنوان شبکه‌ای مستقیماً متصل به کلاینت بدهد. کلاینت جای دفتر را با نصب مسیرها از طریق پیوند یاد می‌گیرد و همان مسیرها در واقع دسترسی‌پذیری را تعیین می‌کنند.
این به معنای درست بودن هر ماسکی نیست که می‌بینید. کلاینت بدتنظیم هم می‌تواند نشانی‌دهی عجیب تولید کند. نکته باریک‌تر است: ماسک میزبان روی این نوع آداپتور انتظار می‌رود، پس به‌تنهایی مدرک خرابی نیست.
گام 1: مدل رابط را تأیید کنید
پیش از داوری درباره آنچه می‌گوید، ببینید آداپتور چیست. رشته توصیف درایور را مشخص می‌کند و طول پیشوند روی نشانی تخصیص‌یافته تأیید می‌کند کلاینت بر چه چیزی توافق کرده است:
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtuفرمان سوم همان است که بیشتر بحث‌ها را پایان می‌دهد. واحد بزرگ انتقال پایین ویژگی پیوند کپسوله است، در حالی که مقدار شبیه Ethernet به مدل آداپتور مجازی دیگری اشاره دارد. اگر توصیف درایور PPP یا RAS را نام ببرد و پیشوند 32 باشد، دقیقاً همان طرحی را می‌بینید که بالا توصیف شد و می‌توانید نگرانی درباره ماسک را کنار بگذارید.
| Observation | What it means | Reasonable next step |
|---|---|---|
| /32 on a PPP or RAS adapter | Point-to-point endpoint addressing | Look at routes, not the mask |
| /32 on an Ethernet-like adapter | Client chose host addressing deliberately | Confirm against the server's push policy |
| Mask differs from the office LAN | Usually irrelevant to reachability | Test the destination instead |
گام 2: مسیر مقصد ناموفق را بخوانید
دسترسی‌پذیری برای هر مقصد تعیین می‌شود و یک رابط متصل هیچ چیزی درباره آن نمی‌گوید. مستقیماً از جدول مسیرها نشانی‌ای را بپرسید که کاربر واقعاً می‌خواهد به آن برسد:
Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4Find-NetRoute پاسخ مستقیم است: رابط و نشانی مبدأیی را نام می‌برد که سیستم برای آن مقصد استفاده می‌کرد. اگر تونل را برگرداند، ترافیک به آن میزبان از تونل می‌گذرد و ماسک هرگز مشکل نبوده است.
اگر آداپتور فیزیکی را برگرداند، دو مسیر نامزد و معیارهایشان را مقایسه کنید. مسیر محلی مشخص‌تر، یک ورودی باقی‌مانده از کلاینت دیگر یا معیار کمتر در مسیر فیزیکی همه بر مسیر گسترده تونل پیروز می‌شوند. نتیجه قابل مشاهده منبعی است که در دسترس نیست در حالی که همه چیز دیگر کار می‌کند. پیشوندهای بلندتر همیشه برنده‌اند، بنابراین برنده اغلب مسیر میزبانی است که کسی ماه‌ها پیش افزوده و فراموش کرده است.
اینجا هر دو جهت را هم بررسی کنید. مسیر به سمت سرور لازم است اما کافی نیست، زیرا پاسخ هم باید از تونل بازگردد. وقتی یک میزبان داخلی کار می‌کند و دیگری نه، تفاوت معمولاً در همین جدول است نه در پیکربندی آداپتور.
گام 3: حل نام را از دسترسی به سرویس جدا کنید
برنامه‌ای که یک اشتراک را باز نمی‌کند ممکن است در یکی از دو مرحله بسیار متفاوت شکست بخورد. نام را حل کنید و سپس به نشانی برسید. اگر اولی شکست بخورد و دومی کار کند، تونل سالم است و حل‌کننده نه:
Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445آزمون موفق نشانی همراه با آزمون ناموفق نام، مشکل را در حل‌وفصل جایابی می‌کند و فرمان دوم نشان می‌دهد آیا رابط تونل اصلاً سروری دریافت کرده است. بسیاری از کلاینت‌ها DNS را به‌عنوان بخشی از پیکربندی تونل ارسال می‌کنند و نمایه‌ای که آن گزینه‌های ارسالی را نادیده بگیرد، دستگاه را با حل‌کننده‌ای رها می‌کند که ناحیه خصوصی را نمی‌بیند.
یک نشانی کارکننده را اصلاح دائمی ندانید. اتصال از طریق نشانی، حل نام را دور می‌زند و می‌تواند بررسی هویت سرور را که برنامه در غیر این صورت انجام می‌داد تضعیف کند. این یک پسرفت امنیتی است که خود را راه‌حل موقت جا می‌زند. از آن برای جایابی خرابی استفاده کنید و سپس حل نام را درست کنید.
بازگردانی: DHCP را به‌خاطر یک مقدار نمایشی بازنسازید
اگر تغییر سرویس نشانی‌دهی را آغاز کرده‌اید، بایستید و بررسی کنید آیا چیزی که تغییر داده‌اید باربر است. بازسازی یک دامنه، صدور مجدد اجاره‌ها یا جابه‌جایی استخر، وضعیتی را تغییر می‌دهد که کلاینت‌های دیگر به آن وابسته‌اند و هیچ‌یک از این‌ها با ماسک میزبان روی آداپتور نقطه‌به‌نقطه توجیه نمی‌شود.
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445این سه را پس از هر تغییر هدفمند اجرا کنید و با اجرای قبلی مقایسه کنید. نتیجه سودمند مسیری مستند به منبع است، نه آداپتوری که ماسکش شبیه شبکه محلی دفتر است.
سپس بنویسید ماسک در واقع چه معنایی داشت، زیرا نفر بعدی همان گفت‌وگو را باز می‌کند و به همان نتیجه نادرست می‌رسد. یک جمله در یادداشت‌های نمایه، که تونل نقطه‌به‌نقطه است و زیرشبکه‌های دور به‌صورت مسیر می‌آیند، تمام بررسی دفعه بعد را ذخیره می‌کند.