گوشی صفحه را باز نمی‌کند: نشانی شنود را بررسی کنید

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

سوکت، تنظیم bind، قاعده‌ی دیوار آتش و URL را دقیقاً به همین ترتیب بررسی کنید.

سوکت به پرسشی باریک‌تر پاسخ می‌دهد

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

از این دو دام نام‌گذاری برمی‌آید. در مرورگر گوشی، localhost یعنی خود گوشی، نه لپ‌تاپ. نشانی wildcard یک مقدار bind است، نه چیزی برای تایپ در URL. هر کس با یکی از این دو آزمایش کند، شکستی را گزارش می‌کند که شبکه هرگز در آن دخیل نبوده است.

IPv6 حالت سومی می‌افزاید، چون سوکت بسته به گزینه‌هایی که آسان نادیده گرفته می‌شوند می‌تواند IPv4 و IPv6 را بپذیرد. خانواده‌ی نشانی را در فهرست بخوانید. یک ورودی wildcard برای یک خانواده خانواده‌ی دیگر را توصیف نمی‌کند.

نشانی شنود را بخوانید

پیش از تغییر پیکربندی سوکت را بررسی کنید. نشانی محلی، درگاه و فرایند مالک با هم نشان می‌دهند که آیا سرور اصلاً از VPN دسترس‌پذیر است.

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

نشانی محلی 127.0.0.1 پرسش را فیصله می‌دهد: هیچ تغییری در دیوار آتش کمکی نمی‌کند، چون برنامه روی رابط VPN گوش نمی‌دهد. wildcard یا نشانی VPN یعنی سوکت سالم است و مرز بعدی برقرار است.

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

bind را از طریق برنامه تغییر دهید

از گزینه‌ی مستندشده‌ی نشانی شنود در چارچوب استفاده کنید و فرایند را دوباره آغاز کنید. اگر لپ‌تاپ مالک نشانی خصوصی 10.77.0.1 باشد، URL گوشی به http://10.77.0.1:8080/ تبدیل می‌شود و آن نشانی باید از طریق VPN مسیریابی شود؛ چیز دیگری در پیکربندی تغییر نمی‌کند.

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

برای HTTPS، نام میزبان سرویس و اعتبارسنجی گواهی را دست‌نخورده نگه دارید. هشدار گواهی روی یک نشانی خام مشکل نام‌گذاری است، نه مرحله‌ای برای کلیک کردن، و DNS خصوصی باید با شنونده‌ای که انتخاب کرده‌اید هم‌خوان باشد.

یک قاعده باز کنید، نه کل شبکه

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

از نشانی مبدأیی استفاده کنید که Windows واقعاً می‌بیند، از جمله هر ترجمه‌ای که دروازه انجام می‌دهد، چون قاعده‌ای که برای نشانی اصلی کلاینت نوشته شده با نشانی ترجمه‌شده مطابقت نخواهد کرد.

صفحه‌ای که بارگذاری می‌شود و خطای برنامه را نشان می‌دهد پیشرفت است: رد HTTP شکستی متفاوت از نبود اتصال TCP است و بررسی بعدی به سیاست دسترسی خود برنامه مربوط است، نه به شبکه.

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