फक्त VPN साठी iptables होस्ट: tun उपकरणाचे नाव द्या, tun+ नाही

-o tun+ लिहिणे अचूक सूचनेसारखे वाटते आणि प्रत्यक्षात ते कर्नेलकडे असलेल्या प्रत्येक बोगद्याशी जुळणारे वाइल्डकार्ड आहे। दुसरा VPN क्लायंट, कंटेनर ब्रिज किंवा कोसळलेल्या सत्राने मागे ठेवलेला इंटरफेस — सर्व ते पूर्ण करतात, आणि मग होस्ट धोरणाने रोखायचे होते तो रहदारीला परवानगी देतो। खालील प्रक्रिया एक उपकरण नाव निश्चित करते, बोगदा प्रत्यक्षात तयार होईल अशा क्रमाने अपवाद मांडते आणि नियम चुकीचे बसल्यास परत जाण्याचा मार्ग ठेवते। प्रत्येक टप्पा स्वतंत्रपणे रद्द करता येईल इतका छोटा आहे।

टप्पा 1: आता असलेले नियम नोंदवा

डीफॉल्ट धोरण बदलण्यापूर्वी सध्याची स्थिती जतन करा, म्हणजे रोलबॅक आठवण नाही तर आदेश होईल। iptables-save > /root/iptables.pre प्रत्येक तक्ता तुम्ही पुनर्संचयित करू शकता अशा फाइलमध्ये लिहितो, आणि तुम्ही सेट करणारे धोरण ते वाहणारे कनेक्शन तोडते तेव्हा उघडे root सत्र असलेले दुसरे टर्मिनल अतिभय नाही। तुम्ही दुरून काम करत असल्यास flush देखील आपत्कालीन स्विच म्हणून नियोजित करा।

मग इंटरफेसची यादी करा, कारण तुम्ही गृहीत धरलेले नाव हे वाचायला हवे होते ते नाव आहे: ip -br link आता काय आहे ते दाखवतो, आणि बोगदा वर येईपर्यंत दिसणार नाही। वाचतानाच उपकरणांची नावे लिहून घ्या।

टप्पा 2: बोगद्याला त्याचे स्वतःचे नाव द्या

OpenVPN क्लायंट संरचनेत dev tun_work स्वीकारतो, आणि मग Linux tun0 वाटून देण्याऐवजी तंतोतंत त्या नावाने इंटरफेस तयार करतो। दुसरे काही त्यावर हक्क सांगत नाही तोपर्यंत पुन्हा जोडण्यांमध्ये नाव स्थिर राहते, आणि उपकरणाचे नाव घेणारा नियम अर्थपूर्ण बनवतो तेच।

जिथे नाव नियंत्रित करता येत नाही, तिथे बोगद्याचा पत्ता किंवा पॅकेट खुणेशी जुळवा। दोन्ही काम करतात, दोन्ही वाचायला कठीण आहेत, आणि बोगदा पुन्हा क्रमांकित झाल्यावर दोन्ही अधिक शांतपणे अयशस्वी होतात। कोणत्याही परिस्थितीत एकाच गोष्टीशी जुळवा आणि कोणती ते स्पष्ट सांगा।

टप्पा 3: endpoint अपवाद आधी ठेवून धोरण लिहा

फक्त VPN असलेला होस्ट म्हणजे छोट्या अपवाद यादीसह डीफॉल्ट-नकार होस्ट, आणि सर्वात महत्त्वाचा अपवाद बोगद्याला अस्तित्वात राहू देणारा आहे। बोगदा-उपकरण नियमापूर्वी endpoint नियम ठेवून हा क्रम ठेवा, म्हणजे हातमिळवणीला जाण्यास जागा मिळेल:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

राउटरवर तेच स्वरूप त्याच्या मागील क्लायंटसाठी FORWARD शृंखलेत जाते, आणि राउटरच्या स्वतःच्या रहदारीला स्वतःचे नियम लागतात। फक्त पुढे पाठवलेल्या पॅकेटवर देखरेख ठेवणारा नियमसंच SSH आणि DNS जुन्या मार्गावर ठेवतो, आणि बोगदा वर येण्याच्या क्षणी राउटर अगम्य होतो ते यामुळेच।

टप्पा 4: केवळ उपस्थिती नाही, क्रम तपासा

नियम क्रमाने मूल्यांकन केले जातात, त्यामुळे आधी येणारा ACCEPT नंतर जोडलेला REJECT फक्त लपवतो। established आणि related जुळणीमुळेच सामान्य आवक मार्ग न उघडता तुमच्या स्वतःच्या जावक विनंत्यांना उत्तरे परत येऊ शकतात, आणि ती बोगदा-स्वीकृतीनंतर ठेवल्यास पडलेला बोगदा तरीही स्वतःच्या इंटरफेसवर परतीची रहदारी पार करतो।

नियमांची संख्या एका स्क्रीनवर वाचता येईल इतकी छोटी ठेवा। ज्या नियमसंचाचे ऑडिट तुम्ही करू शकत नाही तोच तुम्ही वर अपवाद जोडून डागाळाल, आणि डीफॉल्ट-नकार धोरणे हळूहळू डीफॉल्ट-परवानगीची कड मिळवतात ते अशाच प्रकारे। बदलापूर्वी आणि नंतर ACCEPT मोजा।

टप्पा 5: बूट आणि पत्ता कुटुंब दोन्ही टिकून राहील असे करा

हाताने दिलेले नियम रीबूटवर नाहीसे होतात, म्हणून ते वितरणाच्या फायरवॉल सेवेतून किंवा बोगदा इंटरफेस तयार झाल्यानंतर चालणाऱ्या unit मधून लोड करा। OpenVPN सुरू होण्यापूर्वी चालणाऱ्या स्क्रिप्टमध्ये tun_work चा संदर्भ देणे म्हणजे पडलेल्या रहदारीचा बूट लूप तयार करण्याचा सामान्य मार्ग।

मग IPv6 वेगळे तपासा, कारण IPv4 साठी चांगले डीफॉल्ट-नकार धोरण दुसऱ्या कुटुंबाबद्दल काहीही सांगत नाही। ip -6 route होस्टकडे फक्त IPv4 हाताळणाऱ्या बोगद्याभोवती रहदारी नेऊ शकेल असा मार्ग आहे का ते सांगेल, आणि ip6tables किंवा nftables ला स्वतःचे समतुल्य नियम लागतात। नियमसंचाच्या सममितीवर विश्वास ठेवण्याऐवजी IPv6-only गंतव्याने चाचणी करा।

टप्पा 6: पडताळणी करा आणि पुनर्संचयित करण्यास तयार राहा

बोगदा वर आणा, तुमची इच्छित सेवा चालते याची खात्री करा, मग धोरणाने नाकारायला हवे असे काहीतरी वापरून पहा। उत्तर तुम्हाला चकित करत असल्यास iptables-restore < /root/iptables.pre ने पुनर्संचयित करा, आणि त्यानंतरच नियम संपादित करायला सुरुवात करा। टिकाऊपणा आणि चाचणी केलेला पुनर्संचयन मार्ग यामुळेच हे दोन वेळा करता येणारा बदल बनतो।