WireGuard हँडशेक चालतो, सेवा चालत नाही

हँडशेक पूर्ण होतो, क्लायंट अलीकडचा हस्तांतरण काउंटर दाखवतो, आणि तरीही त्याच सर्व्हरवरील सेवेसाठीची विनंती अयशस्वी होते। हे संयोजन लोकांना गोंधळात टाकते, कारण बोगदा स्पष्टपणे चालत आहे। जे सिद्ध झाले नाही ते म्हणजे स्थानिक वितरण: पॅकेट होस्टपर्यंत पोहोचले, आणि होस्टने ते योग्य सॉकेटवर स्वीकारून उत्तर देण्याची परवानगी असलेल्या प्रक्रियेकडे सोपवायचे आहे। हे तीन तपासणी बिंदू क्रमाने पाहा।

जो पहिला जुळत नाही तिथे थांबा, आणि बाकीच्यांसाठी नियम जोडू नका।

हँडशेक फक्त बोगदा सिद्ध करतो

WireGuard चा हँडशेक समवयस्कांमध्ये की स्थापित करतो आणि प्रत्येक समवयस्काने सूचीबद्ध केलेल्या श्रेणींसाठी रहदारीला परवानगी देतो। सर्व्हरवर कोणत्या प्रक्रिया ऐकत आहेत याबद्दल तो काहीही सांगत नाही, आणि होस्टचा फायरवॉल स्वतःच्या कोणत्याही पत्त्यावर पाठवलेले पॅकेट स्वीकारतो का, हेही सांगत नाही।

शेवटचा फरकच सर्वात जास्त दुर्लक्षित होतो: होस्टकडेच जाणारी रहदारी स्थानिक इनपुट आहे, तर होस्टमधून दुसरीकडे जाणारी रहदारी फॉरवर्डिंग आहे। त्यांना वेगवेगळ्या फायरवॉल साखळ्या आणि वेगवेगळ्या सेटिंग्ज हाताळतात। चुकीची साखळी तपासल्यास दुपार वाया जाते आणि निर्दोष दिसणारे काउंटर मिळतात।

ऐकणारा आणि मार्ग वाचा

क्लायंटवर सर्व्हरचा बोगदा पत्ता बोगद्यात राउट होतो याची खात्री करा। सर्व्हरवर क्लायंट वापरत असलेल्या पत्त्यावर सॉकेट आहे आणि त्यामागील प्रक्रिया हेतू असलेलीच आहे याची खात्री करा।

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1 वर ऐकणारा फायरवॉल काहीही परवानगी देत असला तरी 10.66.0.1 वर पाठवलेल्या विनंतीला कधीच उत्तर देणार नाही। वाइल्डकार्ड पत्त्यावर ऐकणारा मात्र नियम अडवत नसेल तर उत्तर देतो। त्यामुळे कोणताही नियम पाहण्यापूर्वीच सॉकेट यादी अर्धे प्रकरण निकाली काढते। पोर्ट आणि पत्ता मिळून विनंती पोहोचू शकते का हे ठरवतात।

क्लायंट वापरत असलेल्या पत्त्याची तुलना सर्व्हरच्या बोगदा इंटरफेसवर प्रत्यक्षात असलेल्या पत्त्याशी करा। कोणत्याही बाजूला जुने कॉन्फिगरेशन अशी विनंती तयार करते जी योग्यरीत्या राउट होते पण ज्याच्याकडे तो पत्ता नाही अशा समवयस्काकडे जाते।

स्थानिक इनपुटसाठी नियम लागू करा, फॉरवर्डिंगसाठी नाही

पॅकेट आले आणि सॉकेट असेल, तर उरलेली सीमा इनपुट धोरण आहे। फॉरवर्डिंगला परवानगी देणारा नियम स्थानिक वितरणाला परवानगी देत नाही, आणि एका इंटरफेसपुरता मर्यादित नियम तुमच्या अपेक्षित बोगदा इंटरफेस नावाशी जुळणार नाही।

होस्ट उघडण्याऐवजी हेतू असलेल्या सेवेकडे एकाच परवानगी असलेल्या पोर्टने चाचणी करा। मग ॲप्लिकेशनची स्वतःची अधिकृती तपासा: परवानगी यादी, खात्याची आवश्यकता किंवा विशिष्ट होस्टनावाशी बांधणी यांनी नेटवर्कने यशस्वीपणे पोहोचवलेली विनंती नाकारली जाऊ शकते।

प्रमाणपत्र तपासण्या जागेवर ठेवा। अनपेक्षित प्रमाणपत्र ओळख ही कोणत्या होस्टने उत्तर दिले याची माहिती आहे, टाळायचा अडथळा नाही। त्यावर क्लिक करून पुढे जाणे चुकीची सेवा ओळखणारा एकमेव सुगावा लपवते।

नाव, आकार आणि ओळखीचे अपयश वेगळे करा

पत्त्याने चालणारी पण नावाने अयशस्वी होणारी सेवा DNS समस्या आहे, आणि दुरुस्ती फायरवॉलमध्ये नाही, क्लायंटला पाठवल्या जाणाऱ्या रिझॉल्व्हर कॉन्फिगरेशनमध्ये आहे। लहान विनंत्यांना उत्तर देणारी पण मोठ्या प्रतिसादांवर अडकणारी सेवा पॅकेट आकार आणि MTU कडे निर्देश करते, जी पूर्णपणे वेगळी चौकशी आहे।

चुकीचे होस्ट नाव देणारी HTTPS त्रुटी सामान्यतः अर्थ दाखवते की विनंती दुसऱ्या सेवेपर्यंत पोहोचली, बहुतेक वेळा प्रॉक्सी किंवा दुसरा ऐकणारा त्या पोर्टचा मालक असल्याने। प्रमाणपत्राचा विषय वाचा आणि तुम्हाला पोहोचायचे होते त्या होस्टशी तुलना करा। या तुलनेत काहीही खर्च होत नाही आणि बहुतेक वेळा चौकशी संपते।

कोणता तपासणी बिंदू अयशस्वी झाला ते नोंदवा: सॉकेट, इनपुट नियम किंवा ॲप्लिकेशन धोरण। ती एक ओळ नेटवर्क बिघाडाची अधिकृती निर्णयापासून वेगळी करते। पुढच्या व्यक्तीला कधीही समस्या नसलेले पोर्ट उघडण्यापासूनही ती रोखते।