Linux वर एकच प्रोग्राम VPN ला जोडणे ही मुख्यतः राउटिंगची समस्या आहे, आणि फायरवॉल नियम फक्त मार्ग निवडल्यानंतर काय होते ते ठरवतो. बोगद्याकडे डीफॉल्ट मार्ग येण्यापूर्वी तुम्ही OUTPUT मध्ये प्रोग्रामचा UID जुळवला, तर नियम तुम्हाला संरक्षित करायचा होता तोच रहदारी टाकून देतो. तोच नियम प्रोग्रामच्या DNS प्रश्नांना उत्तर देणाऱ्या रिझॉल्व्हर प्रक्रियेलाही पाहत नाही. क्रम बरोबर ठेवा आणि एक विशेषाधिकार नसलेले खाते विश्वासार्ह स्प्लिट-बोगदा निवडक बनते.

निर्णयापूर्वी खात्याला मार्ग द्या

मालक-जुळणी एका प्रश्नाचे उत्तर देते: या UID चे स्थानिक सॉकेटने पॅकेट तयार केले का? ते इंटरफेस निवडत नाही आणि मुख्य तक्ता आधीच भौतिक NIC मधून पाठवत असलेली रहदारी हलवू शकत नाही. म्हणून जुळता मार्ग नसलेला UID नियम प्रोग्राम वळवण्याऐवजी अडवतो.

खाते आधी त्याच्या स्वतःच्या तक्त्यातून जाऊ द्या, मग फायरवॉलने निकालाची पुष्टी करो. हे iproute2 ला uidrange समजणाऱ्या होस्टवर चालते, जे ip rule help एका ओळीत सांगते. तक्ता 100 बोगद्यातून डीफॉल्ट मार्ग ठेवतो, आणि नियम फक्त UID 1000 त्या तक्त्याकडे पाठवतो. बाकी सर्व मुख्य तक्त्यावर राहते आणि भौतिक दुवा वापरत राहते.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

वेगळा बोगदा लागणाऱ्या दुसऱ्या खात्याला तक्ता 101 आणि स्वतःचा नियम मिळतो, कारण दोन प्रोफाइल एकाच तक्त्यात डीफॉल्ट मार्गाचे मालक एकत्र होऊ शकत नाहीत. NetworkManager प्रोफाइल सिस्टम-व्यापी असतात, म्हणून हा भाग हातानेच राहतो, आणि रीबूटला नियम जातात, जोपर्यंत काही ते पुनर्संचयित करत नाही. बोगदा व्याख्येच्या शेजारी बूट स्क्रिप्टमध्ये तक्ते लिहा, म्हणजे पुन्हा जोडणी एक खाते चुकीच्या मार्गावर ठेवणार नाही.

loopback अपवाद बोगदा का मारतो

नियमाच्या बहुतेक कॉपी केलेल्या आवृत्त्या loopback मधून न जाणारे प्रत्येक पॅकेट टाकून देतात. बोगदा loopback नाही, म्हणून ते स्वरूप बोगद्याची रहदारीही टाकून देते, आणि निकाल फायरवॉलच्या चुकीसारखा नाही तर मृत VPN सारखा दिसतो.

OUTPUT चालू असताना कर्नल आधीच बाहेर जाणारा इंटरफेस निवडलेला असतो, म्हणून -o पॅकेट हेडरशी नाही तर मार्गाच्या उत्तराशी तुलना केली जाते. मालक-जुळणी फक्त OUTPUT आणि POSTROUTING मध्ये पाहिली जाते, आणि पुढे पाठवलेल्या पॅकेटमध्ये ती वाचू शकेल असा सॉकेट नसतो. या संयोगाचा अर्थ असा की अपवादाने loopback नाकारण्याऐवजी बोगद्याचा इंटरफेस नावाने सांगून ती जुळणी नाकारली पाहिजे.

loopback अजूनही DROP वर स्वतःचा ACCEPT हक्काचा आहे, कारण प्रोग्रामचे पहिले DNS पॅकेट lo मधून स्थानिक स्टबकडे जाते. दोन्ही नियम या क्रमाने ठेवा, आणि खाते स्टबपर्यंत पोहोचते, मग बोगद्यापर्यंत, आणि दुसरीकडे कुठेही नाही.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 वेगळा नियम-संच आहे, आणि फक्त v4 साठीची जोडी ip6tables ला स्पर्श न करता ठेवते. AAAA रेकॉर्डना प्राधान्य देणारा प्रोग्राम मग DROP पर्यंत कधीही न पोहोचता भौतिक दुव्याने बाहेर जाईल. दोन्ही नियम ip6tables मध्ये प्रतिबिंबित करा, किंवा बोगदा v6 पत्ता घेत नसेल तेव्हा होस्टवर IPv6 बंद करा. हाताने जोडलेले नियमही रीबूटला जातात, म्हणून ते netfilter-persistent save ने जतन करा किंवा तोच तर्क बूट युनिट लोड करणाऱ्या nftables तक्त्याप्रमाणे पुन्हा बांधा.

DNS उत्तरे दुसऱ्या प्रक्रियेतून येतात

प्रोग्रामची 127.0.0.53 कडे केलेली विचारणा loopback ACCEPT मधून जाते, आणि तिथेच UID जुळणी थांबते. स्टब रिझॉल्व्हर आपल्या सेवा-खात्यातून वर पाठवतो, म्हणून vpnapp ला जोडलेला नियम दुसरी विचारणा कधीच पाहत नाही. रिझॉल्व्हरने दुव्यासाठी LAN सर्व्हर निवडला, तर उत्तरे भौतिक NIC मधून परत येतात, आणि प्रोग्रामचे स्वतःचे पॅकेट बोगद्यात राहतात. दिसणारा निकाल म्हणजे तुटलेल्या नावांसह चालणारा बोगदा, किंवा तुम्ही न निवडलेल्या सर्व्हरने उत्तर दिलेली नावे.

नाव-निराकरण प्रोग्राममध्ये नाही तर बोगद्याच्या दुव्यावर सुधारा. बोगदा प्रोफाइलला DNS सर्व्हर आणि राउटिंग डोमेन द्या, मग resolvectl query आणि resolvectl status tun0 ने रिझॉल्व्हर महत्त्वाच्या नावांसाठी तो वापरतो याची खात्री करा. नेटवर्क नाव-जागेच्या आत समस्या नाहीशी होते, कारण जागेचा रिझॉल्व्हर फक्त बोगदा ओळखतो.

खात्यातूनच नियम तपासा

UID ला कोणता मार्ग मिळतो हे कर्नलला विचारा, मग त्या खात्याने विनंती करा आणि बाहेर जाणारा पत्ता तुमच्या स्वतःच्या खात्याशी तुलना करा. दोन्ही एकच पत्ता सांगत असतील, तर नियम तुम्ही तपासलेल्या रहदारीशिवाय दुसऱ्या कशाशी जुळत आहे. खालील पहिला आदेश पॅकेट न पाठवता मार्ग-शोध दाखवतो, जो राउटिंग चूक फायरवॉल चुकीपासून वेगळी करतो.

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

काउंटर दाखवतात की नियम कधी चालला का. iptables -vnL OUTPUT चालवा, प्रत्येक नियमाच्या शेजारी पॅकेट-संख्या वाचा, आणि खऱ्या रहदारीनंतर DROP च्या शेजारच्या शून्याला जुळणीची चूक समजा.

पुढे पाठवलेली रहदारी या रचनेबाहेर आहे. पुलाच्या मागील कंटेनर किंवा VM कडे vpnapp च्या मालकीचे स्थानिक सॉकेट नाही, म्हणून मालक-जुळणी कधीही चालत नाही आणि ती पॅकेट FORWARD धोरणाचे पालन करतात. जर तो भार झाकायचा असेल, तर तो वेगळा तपासा आणि पूल किंवा कंटेनर-पत्त्याशी जोडलेले धोरण लिहा. रचना तेव्हाच टिकते जेव्हा तक्ता, इंटरफेस अपवाद, रिझॉल्व्हर आणि v6 नियम सर्व एकाच दिशेने दाखवतात; यापैकी कोणताही एक सोडला तर खाते गळते किंवा जोडणी गमावते.

संबंधित लेख