एका मार्गाचा पुरावा देणारी दोन पीअरची WireGuard चाचणी कशी बनवावी

डीफॉल्ट मार्ग, LAN प्रीफिक्स, DNS आणि फायरवॉल अपवाद घेऊन जाणारी WireGuard चाचणी त्यापैकी काय तुटले हे सांगू शकत नाही। ती दोन पीअर, एक पत्ता जोडी आणि एका परवानगी असलेल्या सेवेपर्यंत कमी करा, मग अपयशाला लपण्याची जागा राहणार नाही। कंटाळवाणा पायाच निदान आहे। तो आधी बनवा; त्याला पंधरा मिनिटे लागतात आणि अनुमानात घालवलेली दुपार वाचते।

पाया जे सिद्ध करतो ते बहुतेक लोकांच्या अपेक्षेपेक्षा अरुंद आहे। दोन ओळखी जुळतात, UDP ऐकणाऱ्या पोर्टपर्यंत पोहोचतो आणि एक परवानगी असलेले ठिकाण विनंती वाहून नेते एवढेच तो सिद्ध करतो। फॉर्वर्डिंग, NAT, LAN मार्ग आणि DNS नंतर एकामागून एक जोडली जाणारी स्वतंत्र वैशिष्ट्ये आहेत।

किल्ल्या, पत्ते आणि एकमेव एंडपॉइंट

प्रत्येक सिस्टमवर की जोडी तयार करा आणि त्यांच्यामध्ये फक्त सार्वजनिक अर्धे भाग हलवा। wg genkey | tee privatekey | wg pubkey > publickey हा दस्तऐवजीकृत एक-ओळीचा आदेश आहे, आणि तो खाजगी किल्ली नंतर संरक्षित करता येईल अशा फाइलमध्ये सोडतो। तुमच्या इतर कोणत्याही संरचनेत न दिसणाऱ्या श्रेणीतून बोगद्याचे पत्ते निवडा, उदाहरणार्थ 10.99.0.1/24 आणि 10.99.0.2/24। कोणता पत्ता कोणत्या मशीनचा आहे ते लिहून ठेवा, कारण पुढील प्रत्येक तपासणी त्या जोडणीवर अवलंबून आहे।

खाजगी किल्ल्या कधीही प्रवास करत नाहीत। चाचणीला एक किल्ली दुसऱ्या बाजूला कॉपी करायची असेल, तर चाचणी आधीच चुकली आहे। जेव्हा दोन्ही सिस्टम NAT मागे असतात, तेव्हा किमान एकाला पोहोचण्यायोग्य UDP पोर्ट लागतो आणि दुसरे त्याकडे निर्देश करणारा Endpoint घेऊन जाते, आणि सार्वजनिक पत्ता व पोर्ट तुमच्या नोंदींमध्ये असावेत, 51820 बद्दलच्या तुमच्या गृहीतांमध्ये नाही।

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

wg शी संबंधित फील्ड आणि जे नाहीत

मुख्य फील्ड संच लहान आहे: Interface खाली PrivateKey आणि ListenPort, Peer खाली PublicKey, AllowedIPs आणि Endpoint। Address आणि DNS wg ला नाही तर wg-quick ला आहेत, आणि तीच संरचना दुसऱ्या साधनात गेल्याक्षणी हा फरक चावतो।

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs एकाच वेळी दोन कामे करते। कोणती गंतव्ये बोगद्यात जातात हे निवडते, आणि आगमनाच्या वेळी ते स्रोत पत्ते वापरण्याचा अधिकार पीअरला देते। त्यामुळे दुसऱ्या बाजूची आरशासारखी नोंद तुमच्या बोगद्याचा पत्ता नेमका नमूद करायला हवी; चुकीच्या पीअरसाठी /32 मार्गविषयक समस्या म्हणून वाचला जातो आणि अधिकाराच्या समस्येसारखा वागतो। WireGuard झटपट सुरुवात फील्डची नावे तुलना करायची असल्यास तोच दोन-पीअर आकार प्रमाणित शब्दरचनेसह दाखवते।

चिन्हाऐवजी हँडशेक वाचणे

इंटरफेस ज्याच्याकडे आहे त्यामार्फत वर करा, मग स्थिती दिवा नाही तर स्थिती वाचा। wg show प्रत्येक पीअरचा नवीनतम हँडशेक बाइट काउंटरसह छापते, आणि गेल्या काही मिनिटांत हँडशेक झाला म्हणजे किल्ल्या, एंडपॉइंट आणि UDP मार्ग सर्व चालू आहेत। फक्त एका दिशेने वाढणारा काउंटर स्वतःच उत्तर आहे, आणि तो कधीच न होणाऱ्या हँडशेकसारखा तोच अपयश नाही।

दोन अपयशे वेगवेगळ्या तपासण्या सुचवतात। हँडशेक अजिबात न होणे किल्लीची विसंगती, चुकीचा Endpoint, अडवलेला UDP किंवा हँडशेकच फेकून देणारा फायरवॉल याकडे निर्देश करते। हँडशेक यशस्वी होऊनही डेटा कुठेही न जाणे AllowedIPs, बोगद्याच्या पत्त्यावर न ऐकणारी सेवा, किंवा LAN साठी पोर्ट स्वीकारणारा पण बोगदा इंटरफेससाठी न स्वीकारणारा होस्ट फायरवॉल याकडे निर्देश करते। हे सिस्टमचे वेगवेगळे अर्धे भाग आहेत, आणि नियम बदलण्यापूर्वी पाया त्यांना वेगळे करतो।

एक परवानगी असलेली सेवा सिद्ध करणे, मग उलट दिशा

दुसऱ्या पीअरच्या बोगदा पत्त्यावर उत्तर देण्याची अपेक्षा असलेल्या सेवेवर विनंती पाठवा, आणि ping पेक्षा चांगले काहीतरी निवडा। ICMP उत्तर नसणे हे बोगद्याचे दोष नसून होस्ट फिल्टरिंग असू शकते, म्हणून शांत ping कोणतीही दिशा सिद्ध करत नाही। तुम्हाला माहीत असलेल्या उघड्या पोर्टवर TCP जोडणी, किंवा डेटा परत देणारी विनंती, तुम्हाला अर्थ लावता येईल असे उत्तर देते।

उलट दिशा स्वतःच्या निकालासह वेगळी चाचणी म्हणून चालवा, कारण दोन्ही दिशांना स्वतंत्र फायरवॉल आणि AllowedIPs नोंदी आहेत आणि त्या स्वतंत्रपणे अपयशी होऊ शकतात। हँडशेक चालतो पण विनंती चालत नाही, तर समस्या बोगद्यात नसून डेटा मार्गात आहे: AllowedIPs, ऐकणारी सेवा, किंवा होस्ट फायरवॉल। फॉर्वर्डिंग, NAT किंवा DNS जोडण्यापूर्वी ते दुरुस्त करा, नाहीतर कधीही दोषी नसलेल्या वैशिष्ट्याचे डीबग करण्यात दुपार जाईल।

पाया संदर्भ म्हणून ठेवणे

चालणारी टोपोलॉजी आणि प्रोफाइल स्रोत जिथून पुनर्संचयित करता येईल तिथे साठवा, आणि सार्वजनिक सेवेशी सिंक होणाऱ्या कोणत्याही फोल्डरबाहेर ठेवा। मग एका वेळी एक वैशिष्ट्य जोडा, प्रत्येकानंतर मूळ विनंती पुन्हा करा: फॉर्वर्डिंग, NAT, LAN मार्ग, आणि त्यानंतरच DNS। चाचणी तोडणारी प्रत्येक जोडणी आता ओळखता येते, कारण दुसरे काहीच हलले नाही।

फक्त चिन्ह हिरवे करणारा पाया पुढील अपयश कोणत्या जोडणीने आणले याबद्दल काहीच सांगत नाही। एकमेव परवानगी असलेला मार्ग संदर्भ म्हणून चालू ठेवा, आणि पुढील प्रत्येक बदल त्याच्याशी तुलना करून मोजला जातो।