वेगळा इग्रेस: usb0 वर VPN पूल, eth0 वर गेटवे रहदारी

क्लायंट जोडतात आणि प्रमाणीकरण करतात, मग त्यांची रहदारी चुकीच्या वरच्या दुव्यातून बाहेर पडते, कारण यंत्रावरील एकमेव डीफॉल्ट मार्ग गेटवेचाच आहे। तो डीफॉल्ट बदलल्यास यंत्राचे स्वतःचे अपडेट्स आणि व्यवस्थापन प्रवेश तुटेल, म्हणून निवड «सर्व रहदारी»पेक्षा अरुंद असली पाहिजे। कार्यक्षम स्वरूप म्हणजे क्लायंट पूलच्या आतील स्रोत पत्त्यावर आधारित धोरण नियम, जो पर्यायी WAN चा मालक असलेल्या दुसऱ्या राउटिंग तक्त्याकडे निर्देश करतो। तिथून पुढे तपासणी यादी नियमाबद्दल नाही, तर पूर्णता आणि अपयशाच्या वर्तनाबद्दल आहे।

स्रोत पत्ता राउटिंग निर्णयापर्यंत टिकतो याची खात्री करा

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

इथेच स्थानिक चाचण्या दिशाभूल करतात। गेटवेवर चालवलेला curl हा गेटवेच्या पत्त्यासह स्थानिकपणे तयार झालेला प्रवाह आहे, त्यामुळे तो मुख्य तक्ता घेतो आणि क्लायंटच्या मार्गाबद्दल काहीही सिद्ध करत नाही। जोडलेल्या क्लायंटवरून चाचणी करा, किंवा पूलचा खरोखर भाग असलेल्या स्रोतासह रहदारी निर्माण करा।

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

पूर्ण असलेली निवडलेली तक्ता तयार करा

तक्ता हा मित्रासह डीफॉल्ट मार्ग नाही। प्रत्येक शोध त्याच्या आत सुटावा इतके मार्ग लागतात, त्यात WAN उपजाळाचा जोडलेला मार्गही, जेणेकरून पुढील हॉप पोहोचण्यायोग्य असेल। tun1 वरील 10.77.0.0/24 पूल, पुढील हॉप 203.0.113.1 असलेला WAN पत्ता 203.0.113.20/24, आणि तक्ता 600 साठी:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

नियम कोणत्याही विद्यमान सर्व-पकडणाऱ्या नियमापेक्षा खालच्या प्राधान्यावर बसतो, त्यामुळे जुळणारे क्लायंट प्रथम तक्ता 600 वर पोहोचतात आणि बाकी सर्व मुख्य तक्त्यात पडते। ip-rule संदर्भ क्रमबद्ध शोध मॉडेल आणि निवडकाची वाक्यरचना पूर्णपणे वर्णन करतो।

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

श्रोत्याची स्वतःची रहदारी धोरणाबाहेर ठेवा

OpenVPN श्रोत्याचे स्वतःचे बाह्य कनेक्शन असते, जे क्लायंट ज्या वरच्या दुव्यातून पोहोचला त्यातून वाहते। त्या रहदारीने आलेला परतीचा मार्ग टिकवला पाहिजे, आणि सर्व्हरच्या सार्वजनिक पत्त्याचा किंवा संपूर्ण टनेल इंटरफेसचा समावेश करणारा विस्तृत नियम ती पर्यायी तक्त्यात ओढू शकतो। नियम आतील पूलपुरता मर्यादित ठेवा, दुसऱ्या कशासाठीही नाही।

उलट मार्ग गाळणीही त्याच कारणासाठी पाहण्यासारखी आहे। जेव्हा क्लायंटना उत्तरे usb0 मधून जातात आणि विनंती दुसऱ्या दुव्यातून आली होती, तेव्हा कडक rp_filter मांडणी राउटिंग धोरण वैध मानते असे पॅकेट टाकून देऊ शकते। नियम अपयशी ठरला असे निष्कर्ष काढण्यापूर्वी दोन्ही इंटरफेसवरील प्रभावी sysctl मूल्ये तपासा।

यंत्रावरील इतर सर्व गोष्टींच्या तुलनेतही क्रम महत्त्वाचा आहे। Docker ब्रिज, दुसरे VPN आणि प्रदात्याच्या प्रतिमेतील आधीचे कोणतेही नियम सर्व प्राधान्ये जोडतात, म्हणून प्राधान्य 100 एकटे आहे असे गृहीत धरण्याऐवजी संपूर्ण नियम यादी वाचा।

फॉरवर्डिंग आणि भाषांतर मार्गाशी जुळवा

राउटिंग वरचा दुवा निवडते; ते फॉरवर्ड करण्याची परवानगी देत नाही। कर्नेलमध्ये IPv4 फॉरवर्डिंग सक्षम असले पाहिजे, आणि फायरवॉलने क्लायंटपासून WAN दिशा व परत येणारी रहदारी स्वीकारली पाहिजे। प्रवाह टाकून देणाऱ्या FORWARD साखळीसह योग्य तक्ता हाणी नसलेल्या मार्गासारखेच लक्षण देते, म्हणून दोन्ही एकाच फेरीत तपासले जातात।

दुसरा WAN खाजगी पूल तुमच्याकडे परत राउट करणार नसेल, तर त्या इग्रेसवर स्रोताचे भाषांतर करा। गतिमान पत्त्याच्या इंटरफेससाठी पूल व इंटरफेसपुरता मर्यादित अरुंद masquerade नियम हा नेहमीचा पर्याय आहे:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

इथे लक्ष्यापेक्षा व्याप्ती महत्त्वाची आहे। कोणत्याही बाहेर जाणाऱ्या इंटरफेसशी जुळणारा masquerade नियम eth0 मधून योग्यरीत्या जाणारी रहदारीही पुन्हा लिहील, आणि यामुळे राउटिंग चुका दुरुस्त करण्याऐवजी लपतात। भाषांतर राउटिंग निर्णयानंतर चालते, त्यामुळे चुकीच्या वरच्या दुव्यावर पाठवलेले पॅकेट ते कधीही दुरुस्त करू शकत नाही।

मार्ग वेगळे झाल्यावर टनेलचा अतिरिक्त भारही लक्ष देण्यासारखा आहे। क्लायंट मोठ्या TCP MSS वर सहमत झाले आणि पर्यायी WAN चा MTU कमी असेल किंवा त्यात टनेल असेल, तर मोठे विभाग अडकतात आणि लहान चालतात। फॉरवर्डिंग मार्गावर MSS क्लॅम्प केल्यास ते अधूनमधून अडकण्याऐवजी अंदाजयोग्य वर्तन होते।

usb0 गायब झाल्यावर काय होईल ते ठरवा

रिकामी तक्ता ही अपयशात बंद होणारी अवस्था नाही। जुळणारा मार्ग गायब झाल्यास शोध पुढील नियमाकडे सुरू राहतो, मुख्य तक्त्यापर्यंत पोहोचतो आणि eth0 चा डीफॉल्ट घेतो। दुसऱ्या WAN मधून जायची होती ती रहदारी शांतपणे पहिल्यातून जाते, आणि धोरण-राउटेड उपयोजनात सहसा हाच तुम्हाला सर्वात कमी हवा असलेला निकाल असतो।

जिथे हे मागे पडणे अस्वीकारार्ह आहे, तिथे तक्ता 600 मध्ये स्पष्ट टर्मिनल मार्ग जोडा, उदाहरणार्थ blackhole डीफॉल्ट, किंवा इंटरफेस बंद असताना फायरवॉलमध्ये पूल टाकून द्या। दोन्हींपैकी कोणतेही हे असे निर्णय आहे जे तुम्ही लिहून ठेवू शकता; शांतता नाही।

टिकाऊपणा हा शेवटचा मुद्दा आहे। दोन्ही दुव्यांचा मालक कोणीही असो, मग तो नेटवर्क व्यवस्थापक असो, डिस्पॅचर स्क्रिप्ट असो किंवा कनेक्शनचे जीवनचक्र, त्याने प्रत्येक पुनर्जोडणीत नकल न जोडता मार्ग व नियम पुन्हा तयार केले पाहिजेत। खऱ्या क्लायंटकडून विनंती आणि गेटवेकडून स्वतंत्र विनंतीने पडताळणी करा, दोन्हीत दिसलेला इग्रेस पुष्टी करा, नंतर दुसरा WAN ओढून काढा आणि तुम्ही आखलेल्या दोन निकालांपैकी कोणता प्रत्यक्षात होतो ते पाहा। IPv6 ला स्वतःचा तक्ता, नियम व भाषांतर लागते; वरील IPv4 नियम त्याबद्दल काहीही सांगत नाही।