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

कंटेनर tun उपकरण तयार करू शकतो याची खात्री करा

बोगदा इंटरफेस अस्तित्वातच राहू शकत नसेल तर बाकी काहीही महत्त्वाचे नाही। /dev/net/tun आहे आणि चाचणी उपकरण तयार करणे यशस्वी होते हे तपासा, कारण अनेक प्रदाते कंटेनरमध्ये tun डीफॉल्टने बंद ठेवतात। कधीही तयार न झालेल्या उपकरणाची भरपाई कोणतेही firewall काम करत नाही।

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

या इंटरफेसवर MASQUERADE काय करते ते ठरवा

सामान्य व्हर्च्युअल मशीनवर नेहमीचा इग्रेस नियम मुख्य इंटरफेसकडून POSTROUTING MASQUERADE असतो। OpenVZ कंटेनरमध्ये दिसणारे उपकरण बहुतेक वेळा venet0 असते, म्हणजे होस्टने व्यवस्थापित व्हर्च्युअल इंटरफेस, रूट केलेले NIC नाही, आणि MASQUERADE तिथे ट्युटोरियल गृहीत धरतात त्याप्रमाणे नेहमी वागत नाही।

व्यवहार्य स्वरूप म्हणजे क्लायंट आधीच पोहोचत असलेल्या पत्त्यावर स्पष्ट भाषांतर, दोन्ही दिशांना फॉरवर्डिंगला परवानगी देऊन। सर्व्हर कॉन्फिगरेशनमधून pool बदलणे पत्ता बदलण्याइतकेच महत्त्वाचे आहे। पेस्ट करण्यापूर्वी प्रत्येक ओळ वाचा।

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

फॉरवर्डिंग नियमांशिवाय भाषांतर तरीही होते आणि कर्नेल तरीही फॉरवर्ड करण्यास नकार देते। हे संयोजन अशी गोंधळलेली स्थिती निर्माण करते जिथे NAT नियमाचे काउंटर वाढतात पण क्लायंटला काहीही मिळत नाही। दोन्ही FORWARD ओळीही त्याच साखळीतील कोणत्याही व्यापक drop नियमापूर्वी असाव्यात। क्रम कॉन्फिगरेशनचा भाग आहे, अंमलबजावणीचा तपशील नाही।

नियम एका pool आणि एका इंटरफेसपुरता मर्यादित करा

दुसऱ्या लक्षणाचे कारण वेगळे आहे: स्रोत किंवा आउटपुट निर्बंध नसलेला POSTROUTING नियम। असा नियम होस्ट सोडणारे प्रत्येक पॅकेट पुन्हा लिहितो।

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

उपाय म्हणजे जुळणी बोगदा pool आणि इग्रेस इंटरफेसपर्यंत संकुचित करा, नंतर अनेक झाकण्यासाठी एक नियम रुंदावण्याऐवजी प्रत्येक pool साठी एक नियम जोडा।

नियम कायमस्वरूपी करा आणि ते अजून कोणाच्या मालकीचे आहेत ते शोधा

हाताने जोडलेले नियम रीबूटवर नाहीसे होतात, म्हणून ते iptables-save ने जतन करा किंवा ते जिथे स्थापित आहे तिथे netfilter-persistent द्वारे व्यवस्थापित करा। पुनर्संचयन OpenVPN सुरू होण्यापूर्वी चालते याची खात्री करा। नंतर घटनेच्या वेळी अंतर शोधण्याऐवजी जाणूनबुजून एकदा रीबूट करा।

कंटेनर होस्टवर, टिकाऊपणाची फाइल लिहिण्यायोग्य कंटेनर स्टोरेजमध्ये आहे आणि प्रदाता बूटवर फिल्टरिंग बदलत नाही याचीही खात्री करा। काही प्लॅटफॉर्म कंटेनरबाहेर धोरण व्यवस्थापित करतात, जिथे स्थानिक नियम एकतर दुर्लक्षित होतात किंवा होस्टच्या स्वतःच्या नियमांशी भिडतात।

काउंटर आणि एका कॅप्चर केलेल्या फ्लोने पडताळणी करा

जोडलेल्या क्लायंटवरून, बाह्य सेवा जाहीर करते तो सार्वजनिक पत्ता तपासा। तो सर्व्हरच्या पत्त्याशी जुळत असेल तर भाषांतर काम करते; जुळत नसेल तर पॅकेट दुसऱ्या मार्गाने बाहेर पडत आहे किंवा अजिबात पडत नाही। नंतर सर्व्हरवर होस्ट केलेली सेवा आणि सार्वजनिक इंटरनेटवरील सेवा दोन्ही तपासा, कारण त्या एकाच नियमसंचातून वेगवेगळ्या मार्गांनी जातात।

सर्व्हरवर iptables -t nat -L -v -n ने NAT आणि FORWARD नियमांवरील पॅकेट काउंटर वाचा आणि कॅप्चरमध्ये एक फ्लो पाहा। कॅप्चरमध्ये क्लायंटचा पत्ता दिसला आणि उत्तर आले नाही तर अंतर परतीच्या मार्गावर किंवा प्रदात्याच्या फिल्टरिंगमध्ये आहे, क्लायंट प्रोफाइलमध्ये नाही। कॅप्चर केलेल्या स्रोताची तुलना नियम ज्या पत्त्यावर भाषांतर करतो त्याशी करा, कारण जुळत नसणे म्हणजे आधी दुसरा नियम जुळला। एक पाहिलेला फ्लो कॉन्फिगरेशन वाचण्याच्या एका पानापेक्षा जास्त गोष्टी निकाली काढतो।

pool, भाषांतरित पत्ता आणि इंटरफेसचे नाव बदल नोंदीत एकत्र ठेवा। एका pool साठी बरोबर असलेला नियम पुढच्याचे चुकीचे भाषांतर करतो।

संबंधित लेख