फ़ोन पेज नहीं खोल पा रहा: लिसन पता जाँचें

लैपटॉप पेज को localhost पर परोस रहा है, फ़ोन उसी VPN से जुड़ता है, और फ़ोन का ब्राउज़र बताता है कि साइट तक नहीं पहुँचा जा सकता। सुरंग में अभी कुछ भी गड़बड़ नहीं है, क्योंकि सुरंग केवल पैकेट पहुँचाती है। loopback इंटरफ़ेस से बंधा एक डेवलपमेंट सर्वर किसी और पते पर भेजे गए कनेक्शन को कभी स्वीकार नहीं करता, इसलिए देखने की पहली जगह सुनता हुआ सॉकेट है, VPN नहीं।

सॉकेट, बाइंड सेटिंग, फ़ायरवॉल नियम और URL इसी क्रम में देखें।

सॉकेट अधिक संकीर्ण प्रश्न का उत्तर देता है

127.0.0.1 पर बना श्रोता मशीन से ही आने वाला ट्रैफ़िक स्वीकार करता है और किसी दूसरे पते पर आने वाली हर चीज़ को अस्वीकार करता है। wildcard पते पर श्रोता हर स्थानीय इंटरफ़ेस पर स्वीकार करता है, VPN इंटरफ़ेस सहित, जो अधिकांश डेवलपमेंट सेटअप की ज़रूरत से अधिक चौड़ा है। एक विशेष VPN पते से बंधा श्रोता सबसे संकीर्ण उपयोगी विकल्प है, और यह केवल तब तक काम करता है जब तक वह पता मौजूद है।

इससे दो नामकरण जाल बनते हैं। फ़ोन के ब्राउज़र में localhost का अर्थ फ़ोन है, लैपटॉप नहीं। wildcard पता एक बाइंड मान है, 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 पता इसका अर्थ है कि सॉकेट ठीक है और अगली सीमा लागू होती है।

स्वामी प्रक्रिया भी पुष्टि करें, क्योंकि किसी सामान्य पोर्ट पर असंबंधित सेवा तालिका को सही दिखा सकती है जबकि इच्छित सर्वर कभी शुरू ही नहीं हुआ। केवल नाम नहीं, निष्पादन योग्य फ़ाइल का पाथ मिलाएँ। पिछले रन की पुरानी प्रक्रिया अक्सर धोखेबाज़ होती है।

एप्लिकेशन के ज़रिए बाइंड बदलें

फ़्रेमवर्क के प्रलेखित लिसन-पता विकल्प का उपयोग करें और प्रक्रिया पुनः आरंभ करें। यदि लैपटॉप के पास निजी पता 10.77.0.1 है, तो फ़ोन का URL http://10.77.0.1:8080/ हो जाता है और वह पता VPN से रूट किया जाना चाहिए; सेटअप में और कुछ नहीं बदलता।

बाइंड को बाध्य करने के लिए Windows में मनमाने पते न जोड़ें और गेटवे न बदलें। वे बदलाव डिबगिंग सत्र से आगे तक रहते हैं और अगले व्यक्ति को चौंकाते हैं। VPN पता बनने से पहले शुरू किया गया सर्वर भी बाइंड करने में विफल हो सकता है, इसलिए क्षणिक इंटरफ़ेस के लिए शुरू करने का क्रम मायने रखता है। इसे फिर से प्रयास दें या सुरंग के बाद शुरू करें। बूट पर बाइंड विफलता अगली सुबह बिल्कुल फ़ायरवॉल समस्या जैसी दिखती है।

HTTPS के लिए सेवा का होस्टनाम और प्रमाणपत्र सत्यापन अक्षुण्ण रखें। कच्चे पते पर प्रमाणपत्र चेतावनी नामकरण की समस्या है, क्लिक करके आगे बढ़ने का चरण नहीं, और निजी DNS को आपके चुने हुए श्रोता से मेल खाना चाहिए।

एक नियम खोलें, पूरा नेटवर्क नहीं

एक बार सॉकेट VPN पते पर स्वीकार करने लगे, तो फ़ायरवॉल तय करता है कि अनुरोध पहुँचेगा या नहीं। नियम को इस एप्लिकेशन, इस प्रोटोकॉल, इस स्थानीय पोर्ट और अधिकृत दूरस्थ स्रोत तक सीमित करें, और पुष्टि करें कि VPN अडैप्टर पर कौन-सी प्रोफ़ाइल सक्रिय है।

Windows जो स्रोत पता वास्तव में देखता है उसी का उपयोग करें, गेटवे द्वारा किए गए किसी भी अनुवाद सहित, क्योंकि मूल क्लाइंट पते के लिए लिखा नियम अनूदित पते से मेल नहीं खाएगा।

लोड होकर एप्लिकेशन त्रुटि दिखाने वाला पेज प्रगति है: HTTP अस्वीकृति TCP कनेक्शन न होने से भिन्न विफलता है, और अगली जाँच नेटवर्क की नहीं, एप्लिकेशन की अपनी एक्सेस नीति की है।

इच्छित फ़ोन से पेज माँगकर और यह पुष्टि करके समाप्त करें कि बाहर रखा गया डिवाइस अब भी उस तक नहीं पहुँच सकता। सब कुछ स्वीकार करने वाले नियम के साथ काम करता श्रोता वही परिणाम नहीं है।