दोन सेल्युलर साइट, आत येणारे पोर्ट नाहीत: काम करणारा हब तयार करा

सेल्युलर अपलिंकवरील दोन साइट दोन्ही दिशांनी एकाच अडचणीला सामोरे जातात: कोणीही न मागितलेले IPv4 कनेक्शन स्वीकारू शकत नाही, म्हणून कोणीही थेट टनेलमध्ये सर्व्हरची भूमिका घेऊ शकत नाही. जे आर्किटेक्चर चालते ते मध्यभागी पोहोचण्यायोग्य तिसरी बाजू ठेवते: प्रत्येक साइट बाहेर डायल करते आणि मधला भाग तुम्ही मंजूर केलेली रहदारीच पुढे पाठवतो. तो मधला भाग तुम्ही चालवता तो राउटर किंवा पीअरची ओळख करून देणारे उत्पादन असू शकतो, आणि या दोन्ही एकच नाहीत. खालील टप्पे अशा क्रमाने आहेत की पुढचा त्यावर अवलंबून राहण्यापूर्वी प्रत्येक पुरावा देतो.

कोणत्याही साइटला डायल करता येत नाही, म्हणून दोन्हींनी बाहेर डायल केले पाहिजे

रचना करण्यापूर्वी मर्यादा निश्चित करा. जर ऑपरेटर WAN इंटरफेसला खाजगी पत्ता देत असेल, तर साइटच्या स्वतःच्या राउटरवरील कोणतेही पोर्ट फॉरवर्डिंग तिला पोहोचण्यायोग्य करणार नाही, कारण भाषांतर वरच्या टप्प्यावर होते. त्याच लिंकवर सार्वजनिक IPv6 पत्ता असू शकतो आणि रचना पूर्णपणे बदलू शकतो, म्हणून तपासणी दोन्ही कुटुंबांना समाविष्ट करते. प्रत्येक साइटसाठी उत्तर लिहून ठेवा, कारण दोन्ही एकच ऑपरेटर सामायिक करत असल्यासही त्यांच्या मर्यादा क्वचितच सारख्याच असतात.

नेहमीची सेल्युलर स्थिती ऑपरेटरच्या भाषांतरित श्रेणीतील पत्ता आणि त्यातून जाणारा डीफॉल्ट मार्ग अशी दिसते. हा दुरुस्त करावयाचा दोष नाही; हब अस्तित्वात असण्याचे कारण हेच आहे. तुम्ही अशा कोणत्याही पत्त्याचा शोध घेत आहात जिथे साइटने आधी न बोलता तिसरी बाजू पोहोचू शकेल.

तुमच्या समोरच्या साइटच्या पत्त्याच्या प्रश्नाला दोन आदेश उत्तर देतात. ते साइटच्या राउटरवर चालवा, त्याच्या मागील लॅपटॉपवर नाही:

ip -4 addr show scope global
ip -6 addr show scope global

कोण पीअरची ओळख करून देतो आणि कोण पॅकेट वाहून नेतो

ओळख आणि वाहतूक या वेगळ्या गोष्टी आहेत, ज्या उत्पादने सीमा दाखवून न देता एकत्र बांधतात. भेटीची यंत्रणा दोन पीअरना संभाव्य मार्ग शोधण्यास मदत करते; थेट मार्ग नसल्यास रिले त्यांची पॅकेट वाहून नेते. पीअरची ओळख करून देणारी सेवा खरेदी केल्याने तुम्हाला राउटर मिळत नाही, आणि हा फरकच रचनेला हबची गरज आहे की नाही हे ठरवतो.

ट्रॅव्हर्सलची स्वतःची शब्दसंग्रह आहे, आणि शब्द भूमिका सांगतात, हमी नाही. ICE तपशील उमेदवार आणि कनेक्टिव्हिटी तपासण्या वर्णन करते, STUN पत्ता भाषांतराबद्दल जाणून घेण्याचा एक मार्ग वर्णन करते, आणि TURN ते लागू करणाऱ्या अनुप्रयोगांसाठी रिले वाहतूक वर्णन करते. यापैकी कोणतीही यंत्रणा नेहमीच्या गेटवेवर दिसत नाही, कारण तुम्ही ते शोध पत्त्याकडे वळवले आहे. ट्रॅव्हर्सल उत्पादन क्षमता म्हणून तपासा, आणि चाचणी उलटे दाखवेपर्यंत रिले गृहीत धरा.

प्रत्येक साइटसाठी एक मार्ग, पीअरच्या मालकीचा

हबला प्रत्येक साइटसाठी एक टनेल, प्रत्येकाच्या मागे वेगळा LAN प्रीफिक्स, आणि प्रत्येक प्रीफिक्ससाठी त्याच्या मालकाचे नाव सांगणारा मार्ग लागतो. उदाहरणात हब 10.61.0.1 आहे, साइट A म्हणजे LAN 10.60.10.0/24 असलेला 10.61.0.11, आणि साइट B म्हणजे 10.61.0.12 आणि त्याचा LAN 10.60.20.0/24 आहे. खालील प्रत्येक मार्ग टनेलच्या इंटरफेसकडे नाही, प्रीफिक्स असलेल्या पीअरकडे निर्देश करतो:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

फॉरवर्डिंग सुरू असणे आवश्यक आहे, अन्यथा पॅकेट हबवर थांबतात आणि कारण दाखवणारी त्रुटी मिळत नाही. शेवटचा आदेश खऱ्या प्रश्नाचे उत्तर देतो, कारण स्रोत शोधात समाविष्ट करून साइट A च्या LAN वरून साइट B च्या LAN पर्यंत पॅकेट कोणता मार्ग घेईल हे तो विचारतो. टनेलच्या इंटरफेसचे नाव सांगणाऱ्या शोधाला पुरावा माना, आणि डीफॉल्ट मार्गावर पडणाऱ्याला कोडे नाही तर गहाळ मार्ग माना. नंतर संक्रमण जाणीवपूर्वक मर्यादित करा, कारण प्रत्येक पीअरमध्ये फॉरवर्ड करणारा हब दोन साइटना सपाट जाळ्यात बदलतो आणि तुम्हाला वाटणारे प्रवेश धोरण लागू राहत नाही.

एन्क्रिप्शन कुठे संपते हेही ठरवा. जेव्हा हब दोन्ही टनेलची टोके धरतो, तेव्हा त्या मशीनचा ऑपरेटर आणि त्याचे कामाचे ओझे विश्वास आणि उपलब्धता या प्रतिमानात सामील होते, आणि त्याची बँडविड्थ मार्गाचा भाग होते.

प्रत्येक मॅपिंग ऑपरेटरमार्फत जिवंत ठेवा

प्रत्येक साइट स्वतःचे टनेल सुरू करते, आणि प्रत्येकाने भाषांतर मॅपिंग जिवंत ठेवले पाहिजे, अन्यथा ऑपरेटर ते विसरतो. सुरुवात करणाऱ्या बाजूचा कीपअलाइव्ह संदेश ते मॅपिंग हातमिळवणीदरम्यान टिकवतो. मंजूर प्रीफिक्स हबच्या पत्त्यापर्यंत आणि दूरच्या LAN पर्यंत मर्यादित करा, जेणेकरून तडजोड झालेला पीअर आपल्याकडे नसलेल्या प्रीफिक्सचा दावा करू शकणार नाही:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

दुसऱ्या साइटवर तिच्या स्वतःच्या दूरच्या प्रीफिक्ससह ब्लॉकचे प्रतिबिंब बनवा, आणि संपूर्ण टनेल श्रेणी मंजूर करण्याच्या इच्छेला प्रतिकार करा. थांबून नवीन स्रोत पोर्टवरून पुन्हा सुरू होणारी हातमिळवणी मुदत संपलेल्या मॅपिंगची सही आहे, आणि हातमिळवणीच्या वेळा ती घडल्याचा पुरावा आहेत. ऑपरेटरच्या कालमर्यादेपेक्षा लहान अंतर मुदत संपण्यास प्रतिबंध करते, नंतर ती दुरुस्त करत नाही. ऑपरेटरने भाषांतराचे वर्तन बदलल्यास, त्या वेळाही त्याच्यासोबत बदलतील अशी अपेक्षा ठेवा.

दोन्ही दिशा सिद्ध करा, नंतर पुनर्प्राप्ती सिद्ध करा

पडताळणी दिशात्मक आहे, म्हणून A ते B ping रचनेचा अर्धा भाग सिद्ध करते आणि परतण्याच्या मार्गाबद्दल काहीही नाही. हबवर त्याच स्रोत-जागरूक शोधाने प्रतिसादाचा मार्ग तपासा, नंतर दुसऱ्या बाजूने चाचणीची पुनरावृत्ती करा. नवीन हातमिळवण्याही पुराव्यात येतात, कारण एक तास निष्क्रिय टनेल जुने मॅपिंग तपासत असू शकते:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

नंतर तुम्हाला हवे असलेले यश नाही, अपेक्षित अयश पाहण्याचा प्रयत्न करा. एका साइटची लिंक पुन्हा सुरू करा आणि कोणत्याही टोकाला माणसाने स्पर्श न करता टनेल परत येते याची खात्री करा, कारण ऑपरेटरकडील प्रत्येक बदलानंतर ऑपरेटर लागणारी रचना अपूर्ण आहे. मुख्य मार्ग, असल्यास IPv6 पर्याय, आणि हब उपलब्ध नसतानाचे वर्तन नोंदवा. हब आता तुमच्या उपलब्धता प्रतिमानाचा भाग आहे, म्हणून ते व्यत्ययाच्या वेळी शोधण्याऐवजी लिहून ठेवा.