VPN पोर्ट मौन? श्रोता, बाइन्ड ठेगाना वा होस्ट फायरवाल

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

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

सकेट नै छ कि छैन

सेवाले आफ्नोबारेमा के भन्छ त्यसबाट सुरु गर्नुहोस्: यो उठ्यो कि र, बढी उपयोगी, यसको पहिलो स्टार्टअप त्रुटि के थियो। पार्स असफलता, हराएको कुञ्जी वा बाइन्ड त्रुटिले श्रोता कहिल्यै बन्न दिँदैन, र प्रक्रिया यति शान्त रूपमा बाहिर निस्कन सक्छ कि स्थिति लाइन अस्पष्ट पढिन्छ। आफूलाई सक्रिय भनी जनाउने युनिट आफैमा प्रमाण होइन, किनकि मुख्य प्रक्रिया जीवित हुन सक्छ जबकि पोर्ट बाइन्ड गर्नुपर्ने कम्पोनेन्ट पहिले नै हारिसकेको हुन सक्छ।

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

सकेटको सूची त्यो तथ्य हो जसमा बाँकी निदान टिकेको छ। पोर्ट मात्र होइन, स्थानीय ठेगानाको स्तम्भ पढ्नुहोस्, किनकि त्यही स्तम्भमा लूपब्याक बाइन्ड र गलत इन्टरफेसमा बाइन्ड देखिन्छ। 127.0.0.1 मा रहेको श्रोता पूर्ण रूपमा चलिरहेको छ र तैपनि तपाईंको ल्यापटपका लागि अदृश्य छ।

सकेट कुन ठेगाना र कुन परिवारमा जवाफ दिन्छ

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

सूचीलाई एउटै पोर्टमा सीमित गर्दा होस्टले धेरै सेवा चलाउँदा पनि यो पढ्नयोग्य रहन्छ। sport फिल्टरले तपाईंले परीक्षण गरिरहेको यातायातसँगै पोर्ट लिन्छ:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

प्रोटोकल स्तम्भले पूरै जवाफ बदल्छ

सकेट तालिका पोर्टसँगै प्रोटोकलमा पनि कुञ्जीबद्ध हुन्छ, र यी दुई स्वतन्त्र प्रविष्टि हुन्। 1194 मा TCP लाई जवाफ दिने सेवाले UDP 1194 मा केही सुनिरहेको छ कि भन्नेबारे केही भन्दैन, र क्लाइन्टले सधैं तीमध्ये एउटा मात्र प्रयोग गर्छ। सर्भर कन्फिगरेसनले कुन यातायात छान्छ र क्लाइन्ट प्रोफाइलले कुन पठाउँछ भनी पुष्टि गर्नुहोस्, त्यसपछि ठ्याक्कै त्यही पंक्ति खोज्नुहोस्।

UDP मा दोस्रो मोड छ: प्रमाणित नगरिएको प्रोब त्यस्तो त्रुटि होइन जसको जवाफ सेवाले दिनुपर्छ। पोर्ट मौन रहेको रिपोर्ट गर्ने स्क्यानले सेवाको उपलब्धता होइन, यसको संयम मापन गरेको हुन्छ, त्यसैले साँचो क्लाइन्ट र प्रोफाइलसँग परीक्षण गर्नुहोस्।

एउटा प्रयास, हेर्ने तीन ठाउँ

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

दुई नतिजाले विपरीत दिशा देखाउँछन्। यदि कुनै प्याकेट होस्टसम्म पुगेन भने बाटोले त्यसलाई खसालिरहेको छ र श्रोता अप्रासंगिक छ। यदि प्याकेट सकेटसम्म पुग्यो र सेवाले अस्वीकार गर्यो भने बाटो ठीक छ र जवाफ प्रोटोकल, क्रिप्टोग्राफी वा प्रमाणहरूमा छ। पहिले नै जडान स्वीकार गरिसकेको सेवाका लागि पोर्ट खोल्दा अर्को निदान सजिलो होइन, कठिन हुन्छ।

नियम बदल्नुअघि चरणको नाम दिनुहोस्

सुरु हुने वार्ता र असफल हुने प्रमाणीकरण एउटै खराबी हो, र अग्रसरण अड्किँदा बन्ने टनेल पूर्ण रूपमा अर्कै हो। चरणको नाम पहिले दिँदा मर्मत साँघुरो रहन्छ: प्रमाणको समस्या फायरवाल नियमले टुङ्गिँदैन, र डेटा-बाटोको समस्या रिस्टार्टले टुङ्गिँदैन।

प्रश्नको जवाफ दिने सबैभन्दा साँघुरो निदान प्रयोग गर्नुहोस्। प्रशासकको नियन्त्रणमा एउटा पोर्टमा अस्थायी प्याकेट अवलोकन उपयुक्त साधन हो; पूरै फायरवाल बन्द गर्नु होइन, किनकि नतिजालाई कारणसँग जोड्न असम्भव हुन्छ। ss को कागजात माथि प्रयोग गरिएका फिल्टर समेट्छ, र यो कुनै पनि क्याप्चरभन्दा सस्तो पहिलो कदम हो। दुई शाखामध्ये कुन सिद्ध गर्नुभयो लेख्नुहोस्, र अर्को घटना ज्ञात जवाफबाट सुरु हुन्छ।