VPN सुरू असताना Android फायरवॉल नियम कुठे असावा
फक्त एकच VpnService सक्रिय असू शकतो, त्यामुळे फायरवॉल अ‍ॅप आणि VPN अ‍ॅप एकमेकांवर चढत नाहीत. एक कार्य विनंती पाहा आणि प्रत्येक नियम तिथे ठेवा जिथून त्याची रहदारी खरोखर जाते.
तुमच्याकडे एका वाक्याचे धोरण आहे: हे अ‍ॅप कामाच्या सेवेपर्यंत पोहोचू शकते, आणि दुसरे काहीही नाही. पुढील प्रश्न उत्पादन निवडीसारखा वाटतो, पण तो जागेचा प्रश्न आहे, कारण प्रत्येक संभाव्य अंमलबजावणी बिंदू फोनच्या रहदारीचा वेगळा भाग पाहतो. गेटवे फक्त सुरंगात जे प्रवेश करते ते पाहतो. फोनच्या बाजूचा गाळणी केवळ पाहण्यास परवानगी असलेले पाहतो. एक विनंती दोन्हींतून जाऊ दिल्यास उत्तर स्पष्ट होते.
उत्पादनापासून नाही, वाक्यापासून सुरुवात करा
काहीही निवडण्यापूर्वी आवश्यकता विस्तारित करा. याचा अर्थ पॅकेज आणि ते ज्या प्रोफाइलमध्ये चालते, कारण कामाच्या प्रोफाइलमधील अ‍ॅप वैयक्तिक प्रोफाइलमधील त्याच अ‍ॅपपेक्षा वेगळा वापरकर्ता आहे. याचा अर्थ गंतव्य: होस्ट, पोर्ट आणि प्रोटोकॉल, सेवेचे नाव नाही. याचा अर्थ ते नाव सोडवणारा DNS मार्ग, आणि सुरंग उपलब्ध नसताना काय व्हावे हेही.
लिहिल्यास उदाहरणाचे धोरण चार ओळी आहे: कामाचे अ‍ॅप कामाच्या सेवेपर्यंत पोहोचू शकते; ते दुसरीकडे पोहोचू शकत नाही; इतर अ‍ॅप अपरिवर्तित राहतात; सुरंग नसल्यास कामाचे अ‍ॅप थेट मार्गावर पडण्याऐवजी नाकारले जाते. प्रत्येक ओळीला मालक आहे, आणि सर्व एकच मालक नाहीत.
पायरी 1: फोन स्वतः काय लागू करू शकतो
रूट नसलेला Android फायरवॉल एक VpnService आहे जो रहदारी स्थानिक पातळीवर पकडतो, मागे दूरची सुरंग नसली तरीही. Android प्रति वापरकर्ता प्रोफाइल एकच सक्रिय VPN सेवा परवानगी देतो, त्यामुळे दुसरे फायरवॉल अ‍ॅप पहिल्याच्या मागे जोडले जात नाही. ते त्याची जागा घेते, आणि पहिले अ‍ॅप गाळत असलेला इंटरफेस नाहीसा होतो.
म्हणूनच VPN क्लायंटच्या शेजारी फायरवॉल स्थापित केल्यावर लोक अपेक्षित संयोजन क्वचितच मिळते. फायरवॉल सुरू झाले आणि VPN तुटले, तर काहीही जोडले गेले नाही; दोन्हींनी जागा बदलली. इंटरफेस बदलणे सहकार्य नाही, आणि लक्षण म्हणजे दुसरे अ‍ॅप उघडल्यावर सुरंग सतत पडणे.
समर्थित मांडणी अस्तित्वात आहेत: तुम्ही आधीच वापरत असलेल्या VPN क्लायंटमध्ये अंतर्भूत गाळणी, डिव्हाइस धोरण नियंत्रक किंवा कामाच्या प्रोफाइलद्वारे व्यवस्थापित प्लॅटफॉर्म नियंत्रणे, किंवा उत्पादकाने दस्तऐवजीकृत केलेली स्थापत्यरचना. बाकी सर्व प्रत्येक अ‍ॅप अद्यतनानंतर पुन्हा तपासावे लागणारे प्रयोग आहे.
पायरी 2: गेटवे काय लागू करू शकतो
दूरच्या टोकावर रहदारी डिक्रिप्ट झाल्यावर, गेटवे पुढे पाठवल्या जाणाऱ्या पॅकेटला मंजूर पत्ते, सेवा किंवा प्रमाणित VPN ओळखींपर्यंत मर्यादित करू शकतो. त्या मार्गाने बाहेर जाणाऱ्या प्रत्येक गोष्टीसाठी ही खरी अंमलबजावणी आहे, आणि खाजगी उपजाळांपर्यंत प्रवेश मर्यादित करण्याची योग्य जागा हीच आहे.
त्याला जे मिळत नाही ते म्हणजे प्रत्येक सामान्य IP पॅकेटला जोडलेली फोनच्या अ‍ॅपची ओळख. एकच सुरंग पत्ता सामायिक करणारी अनेक अ‍ॅप गेटवेसाठी एकच विषय आहेत, जोपर्यंत रचना त्यांना वेगळे पत्ते किंवा वेगळ्या प्रमाणित ओळखी देत नाही. म्हणून गेटवेवरील प्रति-वापरकर्ता नियम फोनवरील प्रति-अ‍ॅप नियम नाही, व्यवस्थापन कन्सोल काहीही म्हणो.
पायरी 3: कधीही न पोहोचणारे सूचीबद्ध करा
VPN मधून वगळलेले अ‍ॅप जवळच्या उपकरणाशी संपर्क साधल्यास गेटवेपर्यंत कधीही पोहोचत नाही, त्यामुळे बाहेर जाणारा फायरवॉल कधीही न मिळालेले पॅकेट नाकारू शकत नाही. व्यत्ययाच्या वेळी अनपेक्षित थेट मार्ग आणि स्थानिक प्रवेश जाळ्यावरील आवक झालेल्या संपर्कासाठीही हेच लागू.
उलटेही खरे: कनेक्शनला परवानगी देणारा स्थानिक नियम गेटवेच्या खाजगी जाळ्याच्या ACL मधून प्रवेश देत नाही. एक विनंती दोन्ही मर्यादांना अधीन असू शकते, आणि एक पूर्ण केल्याने दुसऱ्याबद्दल काहीच सांगता येत नाही.
पायरी 4: प्रत्येक नियम एका मार्गाला द्या
काहीही कॉन्फिगर करण्यापूर्वी निर्णय तक्त्यात ठेवा, कारण रिकाम्या खोक्याच रचना अपयशी होण्याची जागा आहेत.
| मार्ग | कोण लागू करू शकतो | अंध बिंदू |
|---|---|---|
| कामाचे अ‍ॅप ते कामाची सेवा, सुरंग सुरू | पत्ता आणि सेवेवर गेटवे ACL, शिवाय इतर मार्गांवर स्थानिक अडवणूक | कोणत्या अ‍ॅपने पॅकेट पाठवले हे गेटवे पाहू शकत नाही |
| कामाचे अ‍ॅप ते इतर गंतव्ये, सुरंग सुरू | अ‍ॅप-जाणते स्थानिक गाळणी, किंवा ती गंतव्ये तिथे पत्त्यांकित असल्यास गेटवे | स्थानिक गाळणीने सक्रिय VpnService असणे आवश्यक |
| सुरंग नसलेले कामाचे अ‍ॅप | स्थानिक नकार, अ‍ॅप थेट मार्ग घेऊ नये म्हणून | सुरंग गेल्यावरही गाळणी टिकली पाहिजे |
| जवळचे LAN उपकरण | फक्त स्थानिक धोरण | गेटवे ते कधीही पाहत नाही |
जे स्वरूप चालते ते दोन कामांसह दोन मर्यादा आहे. अ‍ॅप-जाणती स्थानिक मर्यादा फोनचे वर्तन नियंत्रित करते, थेट पडण्यासह, आणि गेटवेची मर्यादा दूरची संसाधने नियंत्रित करते. गेटवेची बाजू कामाच्या सेवेला परवानगी देऊन इतर प्रत्येक खाजगी उपजाळ नाकारू शकते, तर फोनच्या बाजूचे धोरण अ‍ॅप घेऊ शकणाऱ्या थेट मार्गाबद्दल स्वतः निर्णय घेते.
पायरी 5: वाहतूक जिवंत ठेवा, मग पडताळणी करा
तुम्ही कोणतेही स्थानिक धोरण निवडा, ते VPN प्रस्थापित करणाऱ्या आणि टिकवणाऱ्या वाहतुकीला परवानगी देणे आवश्यक आहे. ती वाहतूक अडवल्यास फोन सुरंग आणि धोरण दोन्हीशिवाय राहतो, जे काहीही सुसंगतपणे लागू करत नाही आणि निदान करणे कठीण आहे, कारण अ‍ॅपकडे जाळेच नाही.
मग एकूण झालेल्या छापीऐवजी मूळ वाक्याची प्रत्येक ओळ पडताळा: कामाचे अ‍ॅप कामाच्या सेवेपर्यंत पोहोचते, तेच अ‍ॅप दुसऱ्या गंतव्यावर नाकारले जाते, कामाचे नसलेले अ‍ॅप पूर्वीप्रमाणे वागते, आणि सुरंग थांबवल्यावर कामाचे अ‍ॅप थेट जोडणीवर पडत नाही. DNS मार्ग स्वतंत्रपणे तपासा, कारण खाजगी DNS किंवा एन्क्रिप्टेड सोडवणारा केवळ पत्ते तपासणाऱ्या गाळणीला चकवू शकतो.
यापैकी एकही पायरी फोनवर पूर्ण करता येत नसेल, तर आवश्यकता स्थापत्यरचनेचा प्रश्न आहे, फायरवॉल सेटिंग नाही. धोरण तुम्ही नियंत्रित करता त्या उपकरणात आणि गेटवेमध्ये विभागणे हे सामान्यतः प्रामाणिक उत्तर असते, आणि Android VPN कनेक्टिव्हिटी दस्तऐवज हे प्लॅटफॉर्म एका सेवेला काय परवानगी देईल आणि काय देणार नाही हे तपासण्याचे ठिकाण आहे.