संपूर्ण मशीन न वापरता, एकच ॲप VPN मधून कसे वळवावे
कोणतेही अनियंत्रित डेस्कटॉप प्रति-प्रक्रिया VPN स्विच देत नाही। ट्रॅफिक निवडणारा थर स्वतः ठरवा: बाऊंड सॉकेट, UID नियम, फायरवॉल प्रोफाइल किंवा SOCKS हॉप।
VPN क्लायंट जोडतो, ब्राउझर चालतो, आणि तुम्हाला खरोखर महत्त्वाची असलेली ती एक कमांड तरीही तुमच्या घरच्या कनेक्शनमधूनच बाहेर जाते। किंवा उलटे घडते: टनेल डीफॉल्ट मार्ग पकडतो आणि स्थानिक फाइल सर्व्हर डेस्कटॉपवरून नाहीसा होतो। एका बिल्ड एजंटबरोबर मला हे घडले, त्याला अंतर्गत आर्टिफॅक्ट मिररपर्यंत पोहोचायचे होते, तर उर्वरित होस्ट ऑफिस LAN वरच राहिला, आणि क्लायंटने नेमके दोनच पर्याय दिले, सर्व ट्रॅफिक किंवा काहीही नाही। दोन्ही बाजूंनी मागणी एकच आहे, हा प्रोग्राम आणि संपूर्ण मशीन नाही, आणि बहुतेक क्लायंटमध्ये यासाठी चेकबॉक्स नाही, कारण मार्ग सारणीला प्रोग्राम म्हणजे काय हे कधीच माहीत नव्हते।
मार्ग सारणी तुमचा प्रोग्राम का पाहू शकत नाही
प्रक्रिया पॅकेट पाठवते तेव्हा स्टॅक मार्ग सारणीत गंतव्य पत्ता शोधतो। एक्झिक्युटेबलचे नाव किंवा पोर्ट त्या शोधात येत नाही। डोमेन नावे त्याच कारणाने अयशस्वी होतात: टनेल ट्रॅफिकला पत्त्यावर नेते, आणि नाव पत्त्यात रूपांतरित होईपर्यंत कर्नेलकडे राहिलेला एकमेव लीव्हर म्हणजे मार्गनिर्देशन। म्हणूनच “फक्त या साइटसाठी VPN” म्हणजे प्रॉक्सी, आणि “फक्त या प्रोग्रामसाठी VPN” म्हणजे थोड्या यंत्रणांपैकी एक, असे होते।
| Mechanism | What selects | Covers | On tunnel drop |
|---|---|---|---|
| Socket bind | source address | a client you control | connections fail |
| UID rule (Linux) | owning user | every process of one account | connections fail |
| Firewall profile (Windows) | adapter profile | one program | fails closed |
| Network namespace | namespace membership | everything started inside | connections fail |
| SOCKS hop | app proxy setting | one app or one browser profile | connections fail |
यापैकी काहीही प्रति-प्रक्रिया मार्ग नाही। प्रत्येकजण निर्णय असा थराकडे हलवतो जो प्रोग्राम, वापरकर्ता किंवा ॲपची स्वतःची रचना पाहू शकतो।
एकच गंतव्य अजूनही मार्ग आहे, प्रोग्राम नियम नाही। macOS वर नेहमीची पद्धत म्हणजे “सर्व ट्रॅफिक VPN वरून पाठवा” अनचेक करून होस्ट मार्ग जोडणे: sudo route add -host internal-tuner.example -interface ppp0, आणि sudo route delete -host internal-tuner.example -interface ppp0 वापरून पुन्हा काढणे। प्रथम ifconfig वरून इंटरफेसचे नाव वाचा, कारण ppp0 फक्त उदाहरण आहे। होस्ट मार्गात वाइल्डकार्ड चालत नाहीत, म्हणून अनेक नावांशी बोलणाऱ्या सेवेसाठी प्रत्येक नावासाठी एक नोंद लागते, आणि हा नियम मशीनवरील प्रत्येक प्रक्रियेला लागू होतो, तुम्ही ठरवलेल्या एकालाच नाही।
सॉकेट टनेल पत्त्याला बाऊंड करा
तुम्ही क्लायंट नियंत्रित करता तेव्हा बाऊंड करणे हा सर्वात स्वस्त निवडकर्ता आहे। टनेलच्या स्थानिक पत्त्याला बाऊंड केलेला सॉकेट, त्या ठिकाणी गंतव्याचा मार्ग असेल तोपर्यंत त्या इंटरफेसातून बाहेर पडतो, आणि मशीनवरील बाकी सर्व काही आपला नेहमीचा मार्ग ठेवते। सूक्ष्म मुद्दा म्हणजे बाऊंड स्रोत पत्ता निवडते, पण मार्ग सारणी अजूनही बाहेर जाणारा मार्ग निवडते। फक्त बाऊंड टनेलमध्ये मार्ग नसलेला ट्रॅफिक हलवत नाही, आणि हीच “मी बाऊंड केले तरी ते चुकीच्या मार्गाने जाते” अशा बहुतेक अहवालांमागील चूक आहे।
import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))उच्च-स्तरीय साधने हीच कल्पना उघड करतात: curl --interface 10.8.0.2, PHP चे CURLOPT_INTERFACE, आणि Python च्या HTTP क्लायंटमधील source_address वितर्क। पत्ता टनेलचाच असावा, आणि येथे झालेली चूक मार्गाची तक्रार नसून सामान्य कनेक्शन त्रुटी म्हणून अयशस्वी होते। पत्त्याऐवजी डिव्हाइस नावावर बाऊंड करणे हा Linux मधील एक विशेषाधिकार असून Windows किंवा macOS वर तो चालत नाही, म्हणून पोर्टेबल स्क्रिप्ट पत्ता देतात।
Linux: प्रोग्रामचे नाव नाही, मालक जुळवा
कर्नेल सॉकेटच्या मालक वापरकर्त्याशी जुळवू शकते, म्हणून समर्पित खातेच निवडकर्ता बनते।
ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100टनेल आधीच डीफॉल्ट मार्ग नसेल तरच हे चालते। क्लायंट --route-nopull सह सुरू करा, किंवा --pull-filter ignore "redirect-gateway" ने ढकललेला रीडायरेक्ट OpenVPN 2.4 आणि नंतरच्या आवृत्तीवर गाळून टाका, मग सारणी नोंद स्वतः जोडा। अन्यथा दोन्ही डीफॉल्ट अस्तित्वात राहतात आणि कमी प्राधान्याचा जिंकतो। याचा जाणीवपूर्वक केलेला आवृत्ती म्हणजे डीफॉल्ट मार्ग टनेल गेटवेकडे वळवणे, किंवा डिस्कनेक्ट स्क्रिप्टमधून करणे: टनेल पडल्यावर ते ट्रॅफिक इंटरनेटपासून दूर ठेवते, पण तो निवडकर्ता नाही, किल स्विच आहे, आणि कोणी काढेपर्यंत तो राहतो।
अधिक मजबूत आवृत्ती म्हणजे नेटवर्क नेमस्पेस। ते तयार करा, क्लायंट आत चालवा, आणि ॲप्लिकेशन ip netns exec ने सुरू करा। नेमस्पेसबाहेरील कोणालाही टनेल इंटरफेस दिसत नाही, म्हणून ॲप्लिकेशन अपघाताने होस्ट मार्गावर परत जाऊ शकत नाही। किंमत खरी आहे: नेमस्पेसला भौतिक नेटवर्कपर्यंत पोहोचण्यासाठी veth जोडी आणि स्वतःची रिझोल्व्हर फाइल लागते, कारण माउंट नेमस्पेस होस्टच्या रिझोल्यूशन सेटिंग्ज सामायिक करत नाही।
दोन अयशस्वीता पद्धती बहुतेक गळती स्पष्ट करतात। नाव विश्लेषण अजूनही होस्टच्या रिझोल्व्हरमध्ये होते, म्हणून TCP कनेक्शन आत गेले तरी क्वेरी टनेलबाहेर जाते। IPv6 ला स्वतःचा ip -6 rule लागतो, कारण v4 नियम त्याला व्यापत नाही।
Windows आणि macOS: फायरवॉलची व्याप्ती ठरवा किंवा प्रॉक्सी द्या
Windows मध्येही प्रति-ॲप्लिकेशन मार्ग निवडकर्ता नाही, पण त्याचे फायरवॉल नियम प्रोफाइलपर्यंत मर्यादित करता येतात, आणि VPN अडॅप्टरला सार्वजनिक म्हणून वर्गीकृत करता येते, तर घरचा LAN खाजगी राहतो। खाजगी व डोमेन प्रोफाइलवर प्रोग्रामसाठी बहिर्गामी ब्लॉक नियम तयार करा, सार्वजनिक खुला ठेवा, मग ॲप्लिकेशनला केवळ टनेलमधून नेटवर्कपर्यंत पोहोचता येईल। प्रथम कनेक्शनची नेटवर्क श्रेणी ठरवा, मग फायरवॉलच्या मॉनिटर फलकात नियम जुळला याची खात्री करा। हे मार्ग नाही, ब्लॉक आहे: टनेल पडल्यावर तो बंद होऊन अयशस्वी होतो, आणि फायरवॉलकडे दुर्लक्ष करणाऱ्या ॲप्लिकेशनला तो थांबवू शकत नाही।
macOS तीच तर्कशास्त्र वेगळ्या साधनांसह अनुसरते। SSH वरून पोहोचणारा SOCKS श्रोता हा सर्वात कमी हस्तक्षेपाचा पर्याय आहे, कारण ssh -D 1080 user@host एक स्थानिक पोर्ट तयार करतो आणि तो वापरण्यासाठी सेट केलेली ॲप्लिकेशन्सच त्या मार्गाने जातात। pf नियम वापरकर्ता किंवा गटानुसार प्रोग्राम ब्लॉक करू शकतो, पण त्या प्रोग्रामसाठी एकटाच टनेल निवडू शकत नाही। Tunnelblick डोमेननुसार गाळणी करू शकत नाही, कारण मार्ग पत्त्यांवर चालतात; OpenConnect वापरकर्ते सर्व्हरने खूप रुंद उपसर्ग सूची ढकलली की vpn-slice कडे वळतात।
प्लॅटफॉर्म साधनांनी सोडलेल्या गोष्टी दोन उपाय भरून काढतात। डोमेननुसार प्रॉक्सी बदलणारे ब्राउझर एक्स्टेंशन “फक्त ही साइट” साठी व्यवहार्य उत्तर आहेत, कारण ते नावे अजूनही अस्तित्वात असलेल्या ॲप्लिकेशन थरावर काम करतात; ते एका ब्राउझरपुरतेच मर्यादित आहेत, इतर काहीही नाही। ढोबळ उपाय म्हणजे विक्रेत्याचा क्लायंट आभासी मशीनमध्ये चालवणे, म्हणजे पाहुणा मार्ग बदलाचा मालक राहतो आणि होस्ट आपला मार्ग ठेवतो, पण दोन नेटवर्क स्टॅक सांभाळण्याची किंमत मोजावी लागते।
बाऊंड पर्याय नसलेल्या साधनांसाठी SOCKS हॉप
इंटरफेसबद्दल काहीही न माहीत असले तरी बहुतेक ॲप्लिकेशन्सना HTTP किंवा SOCKS प्रॉक्सीकडे वळवता येते। SSH क्लायंट सर्व्हर बाजूला कोणताही बदल न करता एक देतो:
ssh -N -D 127.0.0.1:9999 [email protected]तो पोर्ट वापरण्यासाठी सेट केलेले सर्व काही बास्टियनमधून बाहेर पडते, तर उर्वरित डेस्कटॉप आपले सामान्य कनेक्शन ठेवते। टनेल पत्त्याला बाऊंड केलेला स्थानिक 3proxy इन्स्टन्स SSH शिवाय एका पोर्टसाठी हेच करतो, आणि stunnel TLS मध्ये गुंडाळलेला एकच पोर्ट व्यापतो। मर्यादा व्यवहार्य आहेत: प्रॉक्सी फक्त तो वापरण्यास जाणारे प्रोटोकॉल वाहतो, UDP ला SOCKS5 UDP सहयोग लागतो, जो बऱ्याच क्लायंटची “SOCKS5” सेटिंग सक्षम करत नाही, आणि DNS प्रॉक्सीनेच सोडवावा (curl मधील socks5h), नाहीतर नाव स्थानिक रिझोल्व्हरकडे गळते।
दुसऱ्या मशीनला गरज नसेल तर श्रोता लूपबॅकवरच ठेवा।
स्थिती संदेशाने नाही, कॅप्चरने मार्ग तपासा
ॲप्लिकेशन स्थिती खिडक्या सेटिंग वर्णन करतात, पॅकेट नाही। दोन्ही इंटरफेसवर कॅप्चर करा आणि तुलना करा:
tcpdump -i any -n port 443
ss -tnp | grep 443कनेक्शन टनेलवर जुळणारी नोंद नसताना भौतिक इंटरफेसवर दिसत असेल, तर क्लायंट काहीही अहवाल दे, निवडकर्ता अमलात नाही। IPv6 आणि रिझोल्व्हर स्वतंत्रपणे तपासा, आणि सहायक प्रक्रिया किंवा वारशाने मिळालेला सिस्टम प्रॉक्सी यासारखा दुसरा मार्गही तपासा।
मग गरजेशी जुळणारी सीमा निवडा: एका साइटसाठी प्रॉक्सी पुरेसा, एका खात्यासाठी UID नियम पुरेसा, कनेक्शन बंद होऊन अयशस्वी व्हावे असेल तर फायरवॉल प्रोफाइल पुरेसा, आणि बाहेरील सर्वांपासून टनेल लपवण्याचा एकमेव पर्याय नेमस्पेस आहे।