क्या आपके वेब सर्वर पर VPN क्लाइंट उसके उत्तर तोड़ देता है?

साइट उसी नेटवर्क पर एक लैपटॉप से लोड होती है और बाकी हर जगह से समय-सीमा पार कर जाती है, और होस्ट अपने ही आउटबाउंड ट्रैफ़िक के लिए VPN क्लाइंट भी चलाता है। यह संयोजन एक विशिष्ट विफलता पैदा करता है: इनबाउंड कनेक्शन आता है, उत्तर गलत रास्ते से निकल जाता है, और बाहर का क्लाइंट कभी उत्तर नहीं देखता। दोनों आधे एक ही पैकेट कैप्चर में दिखते हैं, इसलिए घटनाओं का क्रम वह हिस्सा है जो पढ़ने लायक है।

स्रोत-आधारित रूट नियम अक्सर लक्षण को ठीक कर देता है। यह आम तौर पर उस साइट से अधिक ट्रैफ़िक को भी छूट देता है जिसने इसे जन्म दिया, और नियम सहेजने से पहले समझने लायक हिस्सा यही है।

लक्षण: यह स्थानीय रूप से उत्तर देता है और बाहर से नहीं

नेटवर्क के भीतर उत्तर को सुरंग पार नहीं करनी पड़ती, इसलिए पेज लोड होता है और सेवा स्वस्थ दिखती है। बाहर से अनुरोध होस्ट तक पहुँचता है और उत्तर VPN में रूट हो जाता है, जहाँ दूर के सिरे के पास उसे स्वीकार करने का कोई कारण नहीं है। ब्राउज़र इंकार के बजाय समय-सीमा देखता है, जो बंद पोर्ट नहीं बल्कि एकतरफ़ा रास्ते की पहचान है।

रूटिंग बदलने से पहले आकार की पुष्टि करें: श्रोता चालू है, स्थानीय अनुरोध सफल होता है, और बाहरी अनुरोध कोई उत्तर नहीं देता। ये तीन अवलोकन मिलकर वेब सर्वर कॉन्फ़िगरेशन की नहीं बल्कि लौटने के रास्ते की ओर इशारा करते हैं। इतनी साफ़ असममिति किसी भी लॉग पंक्ति से अधिक उपयोगी है, क्योंकि यह एक भी त्रुटि संदेश पढ़ने से पहले श्रोता को बाहर कर देती है।

काम करते समय एक स्वतंत्र प्रशासनिक रास्ता खुला रखें। जो नियम आपके अपने SSH सत्र को तोड़ देता है, वह दस मिनट की मरम्मत को शारीरिक दौरे में बदल देता है।

स्रोत चयनकर्ता वास्तव में किससे मेल खाता है

Linux नीति रूटिंग में, from 192.168.50.2 जैसा नियम उन पैकेटों से मेल खाता है जिनका स्रोत वह पता है। यह इस तथ्य को कूटबद्ध नहीं करता कि पैकेट उस बातचीत को जारी रख रहा है जो घरेलू राउटर से आई थी, और यह नहीं जानता कि किस प्रक्रिया ने इसे बनाया। उस उदाहरण का पता उदाहरणात्मक है; उसे उस पते से बदलें जो आपका होस्ट वास्तव में उपयोग करता है। पंक्ति को पतों के बारे में एक कथन मानें और इससे अधिक कुछ नहीं।

यदि चुनी गई तालिका एक सामान्य डिफ़ॉल्ट रूट देती है, तो उस स्रोत को ले जाने वाला हर पैकेट वही छूट ले सकता है। उसी पते से बंधी दूसरी सेवा उसे विरासत में पाती है, और जो अनुप्रयोग जानबूझकर उस पते से बंधता है वह भी उसे पाता है। नीति नियम संदर्भ स्रोत, गंतव्य, प्रोटोकॉल, पोर्ट, मार्क और प्राथमिकता को अलग-अलग चयनकर्ताओं के रूप में सूचीबद्ध करता है, जो याद दिलाता है कि अकेला स्रोत उपलब्ध सबसे मोटा है।

प्राथमिकता परिणाम तय करती है। खोजें क्रम में चलती हैं और परिणाम देने वाली पहली तालिका खोज समाप्त कर सकती है, इसलिए बहुत जल्दी रखा गया नियम उस अधिक विशिष्ट मार्ग को छिपा सकता है जो बाद की तालिका देती। पूरी क्रमबद्ध सूची पढ़ें, केवल वह एक पंक्ति नहीं जो आपने जोड़ी। जो नियम कभी मेल नहीं खाता उसकी कोई कीमत नहीं, जबकि जो बहुत जल्दी मेल खाता है वह अपने पीछे का सब कुछ चुपचाप बदल देता है।

लौटने का रास्ता और वह ट्रैफ़िक जाँचें जिसकी आपने नहीं सोची थी

नियम और तालिकाएँ पढ़ें, फिर कर्नेल से पूछें कि कोई विशिष्ट स्रोत-गंतव्य जोड़ी कौन-सा मार्ग लेगी। होस्ट से ही परीक्षण करना बाहर से परीक्षण करने के समान नहीं है, इसलिए दोनों करें।

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

फिर एक नया बाहरी कनेक्शन स्वीकार करें और अलग से वह अनुरोध जिसे अभी भी VPN से बाहर जाना है। यदि दूसरा अब सीधे बाहर जाता है, तो छूट उस समस्या से व्यापक है जिसे आप हल कर रहे थे, और असली परीक्षण वही है जिसे आप बदलना नहीं चाहते थे।

ब्राउज़र में सार्वजनिक पता जाँच केवल उन अनुरोधों की सूचना देती है जो उस ब्राउज़र ने किए। यह वेब सर्वर के उत्तरों के बारे में, किसी अन्य स्थानीय अनुप्रयोग के स्रोत चयन के बारे में, या अगले VPN पुनःकनेक्शन के बाद प्रबंधन ट्रैफ़िक का क्या होता है, इस बारे में कुछ नहीं कहती।

तय करें कि छूट कितनी संकरी हो सकती है

दो डिज़ाइन रक्षात्मक हैं और उन्हें जानबूझकर चुना जाना चाहिए। यदि होस्ट इसी सेवा को प्रकाशित करने के लिए है और उसका आउटबाउंड ट्रैफ़िक महत्वपूर्ण नहीं है, तो केवल WAN नीति वाला समर्पित स्थानीय पता उचित व्यवस्था है, बशर्ते आप पूरा दायरा स्वीकार करें। यदि केवल विशिष्ट इनबाउंड कनेक्शन योग्य होने चाहिए, तो पता चयन बहुत मोटा है और उसके आगे कनेक्शन-सजग डिज़ाइन होना चाहिए।

जिस अनुबंध पर आप निर्भर हैं उसे दर्ज करें: सार्वजनिक मैपिंग, वह होस्ट पता जिस पर अनुरोध पहुँचाया जाता है, और वह मार्ग जो उत्तर को लेना चाहिए। VPN प्रदाता के माध्यम से प्रकाशित इनबाउंड सेवा घरेलू राउटर के माध्यम से प्रकाशित से भिन्न अनुबंध है, और एक उदाहरण से नकल किया गया अपवाद अक्सर दूसरे के लिए गलत होता है।

नीति को उस घटक में रखें जिसके पास रूटिंग है, न कि स्टार्टअप फ़ाइल में कमांड चिपकाएँ। नियमों का क्रम, नेटवर्क बदलने के बाद सफ़ाई और रीबूट के बाद पुनरावृत्ति सभी को टिकना है, और बिना जाँची स्टार्टअप फ़ाइल आम तौर पर उसी क्षण विफल होती है जब आप नहीं देख रहे होते। उस स्वीकृति परिणाम के साथ समाप्त करें जिसका आप बचाव कर सकें: एक प्रकाशित साइट बहाल और एक असंबंधित प्रवाह अपरिवर्तित।