VPN बाहेर फक्त एक स्थानिक वेब सेवा पोर्टनुसार राउट करा

एका होस्ट सेवेने भौतिक अपलिंकवरून इंटरनेटला उत्तर द्यायचे आहे, तर मशीनवरील बाकी सर्व सुरंग वापरत राहतील। धोरण-आधारित राउटिंग हा भार पेलू शकते का हे तीन अटी ठरवतात, आणि नियम लिहिण्यापूर्वी प्रत्येकाची तपासणी स्वस्त आहे। सेवा DNAT किंवा फॉरवर्ड केलेल्या पोर्टमागे नाही, तर याच होस्टवर संपली पाहिजे, VPN च्या स्वतःच्या नियमांनी अपवादाला परवानगी द्यायला हवी, आणि तुम्ही विनंतीऐवजी प्रतिसाद जुळवला पाहिजे। तीनपैकी कोणतीही अट फसली तर खालील आदेश त्रुटीशिवाय लोड होतील, पण काहीही उपयुक्त करणार नाहीत।

नियम लिहिण्यापूर्वी तीन अटी तपासा

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

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

प्रतिसाद जुळवा, क्लायंटचा गंतव्य पोर्ट नाही

TCP 443 वर ऐकणाऱ्या सर्व्हरचा प्रतिसाद होस्टमधून स्रोत पोर्ट 443 सह बाहेर पडतो। त्याच होस्टवरील ब्राउझर दूरच्या HTTPS साइटला जोडताना तात्पुरता स्रोत पोर्ट आणि गंतव्य पोर्ट 443 पाठवतो। दोन्ही पोर्ट 443 ची रहदारी आहेत आणि त्यातील फक्त एकाने WAN तक्ता घ्यायला हवा, म्हणूनच गंतव्य-पोर्ट जुळणी चुकीचा अर्धा भाग पकडेल।

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

नियम त्याकडे निर्देश करण्यापूर्वी पूर्ण रिटर्न तक्ता तयार करा

रिकामा तक्ता म्हणजे मार्ग नाही, जो तुटलेल्या धोरणापेक्षा तुटलेल्या सेवेसारखा दिसतो। आधी तो भरा, होस्टवर दुसरे काहीही दावा न करणाऱ्या तक्ता क्रमांक आणि प्राधान्याने:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

आकडे कॉपी करण्याऐवजी जिवंत होस्टवरून वाचा। ip -4 rule show कोणती प्राधान्ये घेतली आहेत ते सांगते, आणि आधीपासून असलेल्या प्राधान्यावर नियम जोडल्यास स्वतंत्रपणे बरोबर दिसणाऱ्या दोन नियमांचा क्रम शांतपणे बदलतो।

इथे खरे काम दोन निवडक करतात। iif lo म्हणजे होस्टने स्वतः तयार केलेली पॅकेट कर्नल कशी कळवते ते, त्यामुळे नियम बाहेरून येणारी फॉरवर्ड रहदारी चुकून पकडू शकत नाही। ipproto tcp sport 443 ते एका ट्रान्सपोर्ट आणि एका पोर्टपर्यंत अरुंद करते, जे गरज परवानगी देते तितके घट्ट आहे। प्रोटोकॉल निवडक काढला तर नियम UDP 443 देखील पकडेल, जी वेगळ्या वर्तनाची वेगळी सेवा आहे।

खाजगी प्रतिसाद सुरंगेतच ठेवा

जर तोच श्रोता खाजगी बाजूच्या क्लायंटना देखील प्रतिसाद देत असेल, तर तक्ता 100 मध्ये सर्व पकडणारा WAN डीफॉल्ट ते प्रतिसाद अपलिंकवरून परत पाठवण्याचा प्रयत्न करेल। WAN डीफॉल्टचे अनुसरण न करणारे खाजगी उपसर्ग जोडा, किंवा त्यांना पुढील धोरण-नियमाकडे पडू द्या:

ip -4 route add table 100 throw 10.90.0.0/24

throw मार्ग या तक्त्यातील शोध संपवतो आणि पॅकेट नियमांच्या यादीकडे परत देतो, त्यामुळे पुढील VPN धोरणाला संधी मिळते। तो स्वतः सुरंगेत काहीही राउट करत नाही, आणि नंतरच्या कोणत्याही नियमाकडे जुळणारा मार्ग नसल्यास पॅकेट तरीही अयशस्वी होते; throw हा उपाय आहे असे गृहीत धरण्याऐवजी पुढील धोरण तपासा।

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

TCP, नंतर QUIC, नंतर रीबूट तपासा

अधिकृत बाह्य क्लायंटकडून एक आणि खाजगी बाजूकडून एक कनेक्शन उघडा, नंतर खऱ्या पत्ते आणि पोर्टसह प्रतिसाद-शोध तपासा। बाह्य प्रतिसाद तक्ता 100 घेतो आणि खाजगी प्रतिसाद घेत नाही, तर धोरण तुम्ही मागितलेलेच करत आहे।

HTTP/3 UDP वर दिले जाते आणि TCP नियमाशी जुळणार नाही, त्यामुळे QUIC श्रोत्याला स्वतःचा निवडक हवा, नाहीतर HTTPS चालू असतानाही ते सुरंग वापरत राहील। तुम्ही ज्या नियमांवर स्थिरावता ते इंटरफेसच्या मालक घटकाकडे साठवा, आणि पुन्हा जोडल्यानंतर किंवा DHCP नूतनीकरणानंतर त्यांची पुष्टी करा। रीबूटनंतर स्पर्धक व्यवस्थापक रनटाइम मार्ग काढून टाकत असेल, तर ती मुळाशी सोडवायची मालकीची समस्या आहे, वर अधिक विस्तृत NAT नियम जोडण्याचे कारण नाही।