फोनले पृष्ठ खोल्न सक्दैन: सुन्ने ठेगाना जाँच्नुहोस्

ल्यापटपले localhost मा पृष्ठ सेवा गर्छ, फोन त्यही VPN मा जोडिन्छ, र फोनको ब्राउजरले साइट पुग्न नसकिने रिपोर्ट गर्छ। सुरुङमा अझै केही गलत छैन, किनकि सुरुङले प्याकेट मात्र पुर्याउँछ। loopback इन्टरफेसमा बाँधिएको विकास सर्भर ले अरू कुनै ठेगानामा गएको जडान कहिल्यै स्वीकार गर्दैन, त्यसैले पहिले हेर्ने ठाउँ सुन्ने सकेट हो, VPN होइन।

सकेट, बाइन्ड सेटिङ, फायरवाल नियम र URL — यही क्रममा काम गर्नुहोस्।

सकेटले अझ साँघुरो प्रश्नको जवाफ दिन्छ

127.0.0.1 मा सिर्जना गरिएको लिसनरले मेसिन आफैंबाट आउने ट्राफिक स्वीकार गर्छ र अर्को ठेगानामा आउने सबै कुरा अस्वीकार गर्छ। वाइल्डकार्ड ठेगानामा रहेको लिसनरले हरेक स्थानीय इन्टरफेसमा स्वीकार गर्छ, VPN इन्टरफेस सहित, जुन धेरै विकास सेटअपलाई आवश्यक भन्दा फराकिलो हुन्छ। एउटा निश्चित VPN ठेगानामा बाँधिएको लिसनर सबैभन्दा साँघुरो उपयोगी विकल्प हो, र त्यो ठेगाना रहेसम्म मात्र काम गर्छ।

त्यसबाट दुई नामकरण जाल तर्फ आउँछन्। फोनको ब्राउजरमा localhost भन्नाले फोन बुझिन्छ, ल्यापटप होइन। वाइल्डकार्ड ठेगाना बाइन्ड मान हो, URL मा टाइप गर्ने कुरा होइन। जसले यीमध्ये कुनै एउटा प्रयोग गरेर परीक्षण गर्छ, उसले नेटवर्कसँग कहिल्यै नजोडिएको असफलता रिपोर्ट गर्नेछ।

IPv6 ले तेस्रो अवस्था थप्छ, किनकि सकेटले विकल्पहरूमा निर्भर गरेर IPv4 र IPv6 स्वीकार गर्न सक्छ, जो चाँडै नजरबाट छुट्छन्। सूचीमा ठेगाना परिवार पढ्नुहोस्। एउटा परिवारको वाइल्डकार्ड प्रविष्टिले अर्कोको वर्णन गर्दैन।

सुन्ने ठेगाना पढ्नुहोस्

कन्फिगरेसन बदल्नु अघि सकेट जाँच्नुहोस्। स्थानीय ठेगाना, पोर्ट र मालिक प्रक्रियाले सँगै पहिचान गर्छ कि सर्भर 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 इन्टरफेसमा सुनिरहेको छैन। वाइल्डकार्ड वा VPN ठेगाना भन्नाले सकेट ठीक छ र अर्को सीमा लागू हुन्छ।

मालिक प्रक्रिया पनि पुष्टि गर्नुहोस्, किनकि सामान्य पोर्टमा रहेको असम्बन्धित सेवाले तालिका सही देखाउन सक्छ जबकि इच्छित सर्भर कहिल्यै सुरु भएको थिएन। कार्यान्वयन पथ मिलाउनुहोस्, नाम मात्र होइन। अघिल्लो रनको पुरानो प्रक्रिया बारम्बार ठग हुन्छ।

एप्लिकेसनमार्फत बाइन्ड बदल्नुहोस्

फ्रेमवर्कको कागजात गरिएको लिसन-ठेगाना विकल्प प्रयोग गरेर प्रक्रिया पुनः सुरु गर्नुहोस्। यदि ल्यापटपसँग निजी ठेगाना 10.77.0.1 छ भने फोनको URL http://10.77.0.1:8080/ हुन्छ र त्यो ठेगाना VPN मार्फत रुट गर्नुपर्छ; सेटअपको अरू केही बदलिँदैन।

Windows मा स्वेच्छाचारी ठेगाना नथप्नुहोस् र बाइन्ड बाध्य पार्न गेटवे नबदल्नुहोस्। ती परिवर्तन डिबगिङ सत्रपछि पनि रहन्छन् र अर्को व्यक्तिलाई अचम्ममा पार्छन्। VPN ठेगाना नहुँदै सुरु गरिएको सर्भर पनि बाइन्ड गर्न असफल हुन सक्छ, त्यसैले अस्थायी इन्टरफेसका लागि सुरु गर्ने क्रम महत्त्वपूर्ण छ। यसलाई पुनः प्रयास दिनुहोस् वा सुरुङपछि सुरु गर्नुहोस्। बुटमा बाइन्ड असफलता भोलिपल्ट बिहान ठ्याक्कै फायरवाल समस्याजस्तै देखिन्छ।

HTTPS का लागि सेवा होस्टनेम र प्रमाणपत्र प्रमाणीकरण अक्षुण्ण राख्नुहोस्। कच्चा ठेगानामा प्रमाणपत्र चेतावनी नामकरण समस्या हो, क्लिक गरेर पार गर्ने कदम होइन, र निजी DNS ले तपाईंले छानेको लिसनरसँग मिल्नुपर्छ।

एउटा नियम खोल्नुहोस्, सम्पूर्ण नेटवर्क होइन

सकेटले VPN ठेगानामा स्वीकार गरेपछि अनुरोध आउने हो कि होइन भन्ने फायरवालले निर्धारण गर्छ। नियमलाई यही एप्लिकेसन, यही प्रोटोकल, यही स्थानीय पोर्ट र अधिकृत टाढाको स्रोतमा सीमित गर्नुहोस्, र VPN एडाप्टरमा कुन प्रोफाइल सक्रिय छ पुष्टि गर्नुहोस्।

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

लोड भएर एप्लिकेसन त्रुटि देखाउने पृष्ठ प्रगति हो: HTTP अस्वीकृति TCP जडान नहुनुभन्दा फरक असफलता हो, र अर्को अनुसन्धान नेटवर्कको होइन, एप्लिकेसनको आफ्नै पहुँच नीतिको विषय हो।

इच्छित फोनबाट पृष्ठ मागेर र बहिष्कृत यन्त्रले अझै पुग्न नसक्ने पुष्टि गरेर टुंग्याउनुहोस्। सबै कुरा स्वीकार गर्ने नियमसहितको कार्यरत लिसनर त्यही नतिजा होइन।