केवळ पोर्ट 25 सुरंगात पाठवा, होस्ट नाही

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

पोर्ट नियम डीफॉल्ट मार्ग नाही

स्थानिक पातळीवर तयार झालेल्या TCP ला उद्दिष्ट पोर्ट 25 शी जुळवणारा नियम ती रहदारी तुम्ही नाव दिलेल्या तक्त्यात पाठवतो। नियम स्वतः काहीही तयार करत नाही: तो निवडतो, आणि तक्त्यात पॅकेट वाहून नेऊ शकेल असा मार्ग असणे आवश्यक आहे। दोन्ही एकत्र केल्यास केवळ एका प्रोटोकॉलची बाहेर जाणारी दिशा व्यापली जाते, म्हणून इतर होस्टसाठी फॉर्वर्डिंग, येणारे मेल कनेक्शन आणि IPv6 या रचनेबाहेर राहतात। याला VPN डीफॉल्टऐवजी पोर्ट-विशिष्ट धोरण म्हणणे ती सीमा प्रामाणिक ठेवते।

wg-quick ची दोन सेटिंग्ज पूर्वअटी आहेत, धोरणाचा भाग नाहीत। AllowedIPs = 0.0.0.0/0 पीअरला अनियंत्रित IPv4 उद्दिष्टे वाहून नेऊ देतो, आणि Table = off त्या प्रीफिक्ससाठी wg-quick ला स्वतःचा डीफॉल्ट मार्ग स्थापित करण्यापासून थांबवतो। हे निर्देश स्वतःचे मार्ग धोरण लागू करणाऱ्या व्यवस्थापकासोबत मिसळू नका, कारण दोघे मुख्य तक्ता कोणाचा यावर सहमत होणार नाहीत।

मार्ग, निवडक आणि रक्षक लिहा

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

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo नियम स्थानिक उगमाच्या रहदारीपुरता मर्यादित करतो, आणि ipproto tcp dport 25 कनेक्शनची दिशा ओळखतो; ip-rule संदर्भ दोन्ही निवडकांची नोंद करतो। ते सध्याच्या कर्नेल आणि iproute2 आवृत्त्यांमध्ये आहेत, आणि जुन्या प्रणालीवर नियम पूर्णपणे नाकारला जातो, जे लोड होऊन कोणाशीही जुळत नसलेल्या नियमापेक्षा स्पष्ट अपयश आहे।

पुढील प्राधान्यावरील unreachable नियम हा रक्षक आहे। त्याशिवाय, तक्ता 51825 मधील अनुपस्थित मार्ग सामान्य डीफॉल्टमध्ये पडतो, आणि सुरंग खंडित असताना मेल भौतिक दुव्यातून बाहेर पडतो, ही नेमकी तीच स्थिती आहे जी रोखण्यासाठी धोरण तयार केले होते।

स्रोत पत्ता जुळला पाहिजे

मार्गाची src प्राधान्यता केवळ अशा कनेक्शनसाठी स्रोत भरते ज्यांनी स्वतःचा स्रोत बांधला नाही। हे भाषांतर नाही, आणि स्पष्ट बाइंडिंगला मागे टाकत नाही, म्हणून भौतिक पत्त्याशी बांधलेला डेमन त्याच पत्त्यावरून पाठवत राहतो। असेच आढळल्यास, डेमनची स्वतःची सेटिंग बदला किंवा जाणीवपूर्वक भाषांतर धोरण तयार करा, कारण उशिरा केलेले सर्वव्यापी masquerade वेगळ्या परिणामांसह वेगळा उपाय आहे।

गेटवेवर, क्लायंटच्या पीअरने प्रत्यक्षात मिळणाऱ्या स्रोताला अधिकृत करणे आवश्यक आहे, तो रुंद उद्दिष्ट प्रीफिक्स नाही तर 10.77.0.2/32 आहे। क्लायंटचे 0.0.0.0/0 प्रत्येक गेटवे पीअरमध्ये कॉपी केल्यास कोणता पीअर कोणत्या रहदारीचा मालक आहे हे गोंधळते। गेटवेला फॉर्वर्डिंग, प्रवाहाला परवानगी देणारे फायरवॉल धोरण, आणि परतीचा मार्ग देखील आवश्यक आहे, ज्यात अपस्ट्रीम खाजगी सुरंग पत्ता राउट करू शकत नाही तेव्हा बाहेर जाणाऱ्या भाषांतराचा समावेश आहे।

परतीचा मार्ग तपासा, नंतर टिकाऊपणा

कोणत्याही गोष्टीवर विश्वास ठेवण्यापूर्वी लुकअप वाचा, कारण ते प्रत्येक दिशेला कोणता तक्ता आणि कोणता स्रोत मिळतो हे दाखवतात। पोर्ट 25 वर एक उद्दिष्ट आणि पोर्ट 443 वर तेच उद्दिष्ट पुरेसे आहे:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

पहिल्या लुकअपमध्ये wg0 आणि इच्छित स्रोत असावा, आणि दुसऱ्याने सामान्य अपलिंक टिकवावा। जेव्हा अॅप्लिकेशन स्वतःचा पत्ता बांधते, तेव्हा त्या पत्त्यासह from लुकअपमध्ये जोडा। जी उत्तर-दिशा wg0 पर्यंत पोहोचून नंतर स्थानिक पातळीवर टाकली जाते ती IPv4 रिव्हर्स-पाथ फिल्टरिंगकडे निर्देश करते, कारण केवळ बाहेर जाणाऱ्या पोर्टचा नियम रिव्हर्स लुकअपला सुरंग निवडण्यास भाग पाडत नाही।

जिथे असममित राउटिंग अधिकृत आहे, तिथे net.ipv4.conf.wg0.rp_filter=2 द्वारे इंटरफेस-मर्यादित सैल मोड योग्य असू शकतो, आणि आधी all आणि इंटरफेस मूल्यांची प्रभावी कमाल तपासणे योग्य आहे। शॉर्टकट म्हणून सत्यापन जागतिक स्तरावर बंद करू नका। नंतर तक्ता, प्राधान्ये आणि रक्षक संरचनेच्या मालकाकडे सुपूर्द करा, आणि पुन्हा कनेक्ट झाल्यानंतर नवीन कनेक्शन उघडून निवड अजूनही टिकते याची खात्री करा। लक्षात ठेवा की स्थानिक SMTP श्रोत्याची उत्तरे स्रोत पोर्ट 25 वाहतात, उद्दिष्ट पोर्ट 25 नाही, जो वेगळा धोरण-प्रश्न आहे।