VPN ఆన్ ఉన్నప్పుడు Android firewall నియమం ఎక్కడ ఉండాలి
ఒకే ఒక VpnService మాత్రమే క్రియాశీలంగా ఉండగలదు, కాబట్టి firewall యాప్ మరియు VPN యాప్ ఒకదానిపై ఒకటి పేరుకోవు. ఒక పని అభ్యర్థనను అనుసరించి ప్రతి నియమాన్ని దాని ట్రాఫిక్ నిజంగా వెళ్లే చోట ఉంచండి.
మీకు ఒక వాక్య విధానం ఉంది: ఈ యాప్ పని సేవను చేరుకోవచ్చు, మరేదీ కాదు. తదుపరి ప్రశ్న ఉత్పత్తి ఎంపికలా కనిపిస్తుంది, కానీ అది స్థానం గురించిన ప్రశ్న, ఎందుకంటే ప్రతి సంభావ్య అమలు బిందువు ఫోన్ ట్రాఫిక్లో వేరే ఉపసమితిని చూస్తుంది. ఒక gateway టన్నెల్లోకి ప్రవేశించేది మాత్రమే చూస్తుంది. ఫోన్ వైపు ఫిల్టర్ తనకు గమనించడానికి అనుమతి ఉన్నది మాత్రమే చూస్తుంది. ఒక అభ్యర్థనను రెండింటి గుండా నడిపించడం సమాధానాన్ని స్పష్టం చేస్తుంది.
ఉత్పత్తితో కాదు, వాక్యంతో ప్రారంభించండి
ఏదీ ఎంచుకునే ముందు అవసరాన్ని విస్తరించండి. దాని అర్థం ప్యాకేజీ మరియు అది నడిచే ప్రొఫైల్, ఎందుకంటే పని ప్రొఫైల్ యాప్ వ్యక్తిగత ప్రొఫైల్లోని అదే యాప్ కంటే వేరే వినియోగదారు. దాని అర్థం గమ్యం: host, port మరియు protocol, సేవ పేరు కాదు. దాని అర్థం ఆ పేరును పరిష్కరించే DNS మార్గం, మరియు టన్నెల్ అందుబాటులో లేనప్పుడు ఏమి జరగాలో కూడా.
రాసినప్పుడు, ఉదాహరణ విధానం నాలుగు పంక్తులు: పని యాప్ పని సేవను చేరుకోవచ్చు; పని యాప్ మరేదీ చేరుకోకూడదు; ఇతర యాప్లు మారవు; టన్నెల్ లేకుండా, పని యాప్ నేరుగా మార్గానికి మారకుండా తిరస్కరించబడుతుంది. ప్రతి పంక్తికి ఒక యజమాని ఉంటారు, అందరూ ఒకే యజమాని కాదు.
దశ 1: ఫోన్ తానే అమలు చేయగలదు
root లేని Android firewall అనేది వెనుక దూరపు టన్నెల్ లేకపోయినా ట్రాఫిక్ను స్థానికంగా పట్టుకునే VpnService. Android ఒక వినియోగదారు ప్రొఫైల్కు ఒక క్రియాశీల VPN సేవను మాత్రమే అనుమతిస్తుంది, కాబట్టి రెండవ firewall యాప్ మొదటి దాని వెనుక జతకట్టదు. అది దానిని భర్తీ చేస్తుంది, మొదటి యాప్ ఫిల్టర్ చేసిన ఇంటర్ఫేస్ మాయమవుతుంది.
అందుకే VPN క్లయింట్ పక్కన firewall ఇన్స్టాల్ చేయడం ప్రజలు ఆశించే కలయికను అరుదుగా ఇస్తుంది. firewall ప్రారంభమై VPN డిస్కనెక్ట్ అయితే, ఏదీ కలవలేదు; ఆ రెండూ స్థానాలు మార్చుకున్నాయి. ఇంటర్ఫేస్ భర్తీ సహకారం కాదు, లక్షణం ఏమిటంటే మరో యాప్ తెరిచిన ప్రతిసారీ పదేపదే పడిపోయే టన్నెల్.
మద్దతు ఉన్న ఏర్పాట్లు ఉన్నాయి: మీరు ఇప్పటికే నడిపే VPN క్లయింట్లో నిర్మిత ఫిల్టరింగ్, పరికర విధాన నియంత్రకం లేదా పని ప్రొఫైల్ ద్వారా నిర్వహించబడే ప్లాట్ఫారమ్ నియంత్రణలు, లేదా విక్రేత డాక్యుమెంట్ చేసే నిర్మాణం. మిగతావన్నీ ప్రతి యాప్ అప్డేట్ తర్వాత మళ్లీ ధృవీకరించాల్సిన ప్రయోగం.
దశ 2: gateway అమలు చేయగలదు
దూరపు చివర ట్రాఫిక్ డీక్రిప్ట్ అయిన తర్వాత, gateway ఫార్వర్డ్ చేసిన ప్యాకెట్లను ఆమోదించిన చిరునామాలు, సేవలు లేదా ధృవీకరించిన VPN గుర్తింపులకు పరిమితం చేయగలదు. అది దాని గుండా బయటకు వెళ్లే ప్రతిదానికీ నిజమైన అమలు, ప్రైవేట్ సబ్నెట్లకు ప్రవేశాన్ని పరిమితం చేయడానికి సరైన స్థలం కూడా.
అది పొందనిది ప్రతి సాధారణ IP ప్యాకెట్కు జోడించిన ఫోన్ యాప్ గుర్తింపు. ఒక టన్నెల్ చిరునామాను పంచుకునే అనేక యాప్లు gatewayకు ఒకే విషయం, రూపకల్పన వాటికి వేర్వేరు చిరునామాలు లేదా వేర్వేరు ధృవీకరించిన గుర్తింపులు ఇస్తే తప్ప. కాబట్టి gatewayలో వినియోగదారుకు నియమం ఫోన్లో యాప్కు నియమం కాదు, నిర్వాహక కన్సోల్ దానిని ఎలా పిలిచినా.
దశ 3: ఎప్పటికీ రానిది జాబితా చేయండి
VPN నుండి మినహాయించబడిన యాప్ దగ్గరలోని పరికరాన్ని సంప్రదిస్తే gatewayకు ఎప్పటికీ చేరదు, కాబట్టి నిష్క్రమణ firewall తాను ఎప్పటికీ పొందని ప్యాకెట్ను తిరస్కరించలేదు. అంతరాయం సమయంలో అనుకోని నేరుగా మార్గానికి మరియు స్థానిక ప్రవేశ నెట్వర్క్లో లోపలికి బహిర్గతం కావడానికి కూడా ఇదే వర్తిస్తుంది. అవి నిర్వచనం ప్రకారం స్థానిక సరిహద్దులు.
దీనికి విరుద్ధం కూడా నిజం: కనెక్షన్ను అనుమతించే స్థానిక నియమం gateway యొక్క ప్రైవేట్ నెట్వర్క్ ACL ద్వారా ప్రవేశాన్ని ఇవ్వదు. ఒక అభ్యర్థన రెండు సరిహద్దులకు లోబడి ఉండవచ్చు, ఒకదాన్ని నెరవేర్చడం మరొకదాని గురించి ఏమీ చెప్పదు.
దశ 4: ప్రతి నియమానికి మార్గం కేటాయించండి
ఏదీ కాన్ఫిగర్ చేసే ముందు నిర్ణయాన్ని పట్టికలో పెట్టండి, ఎందుకంటే ఖాళీ గడులు రూపకల్పనలు విఫలమయ్యే చోటు.
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
పనిచేసే ఆకారం రెండు పనులతో రెండు సరిహద్దులు. యాప్లను తెలిసిన స్థానిక సరిహద్దు నేరుగా ఫాల్బ్యాక్తో సహా ఫోన్ ప్రవర్తనను నియంత్రిస్తుంది, gateway సరిహద్దు దూరపు వనరులను నియంత్రిస్తుంది. gateway వైపు పని సేవను అనుమతించి మిగతా ప్రతి ప్రైవేట్ సబ్నెట్ను తిరస్కరించగలదు, అదే సమయంలో ఫోన్ వైపు విధానం యాప్ లేకపోతే తీసుకునే నేరుగా మార్గం గురించి తానే నిర్ణయించుకుంటుంది.
దశ 5: రవాణాను సజీవంగా ఉంచి, తర్వాత ధృవీకరించండి
మీరు ఎంచుకున్న స్థానిక విధానం VPNను ఏర్పాటు చేసి నిర్వహించే రవాణాను అనుమతించాలి. ఆ రవాణాను నిరోధించడం ఫోన్ను టన్నెల్ లేకుండా, విధానం లేకుండా వదిలివేస్తుంది, ఇది ఏదీ స్థిరంగా అమలు చేయదు మరియు యాప్కు నెట్వర్క్ లేకపోవడంతో నిర్ధారణ కష్టం.
తర్వాత మొత్తం అనుభూతికి బదులుగా అసలు వాక్యం యొక్క ప్రతి పంక్తిని ధృవీకరించండి: పని యాప్ పని సేవను చేరుకుంటుంది, అదే యాప్ మరో గమ్యంలో తిరస్కరించబడుతుంది, పని కాని యాప్ మునుపటిలా ప్రవర్తిస్తుంది, టన్నెల్ ఆపివేసినప్పుడు పని యాప్ నేరుగా కనెక్షన్కు మారదు. DNS మార్గాన్ని విడిగా తనిఖీ చేయండి, ఎందుకంటే ప్రైవేట్ DNS లేదా గుప్తీకరించిన రిజాల్వర్ చిరునామాలను మాత్రమే పరిశీలించే ఫిల్టర్ను బైపాస్ చేయగలవు.
ఆ దశలలో ఒకటి ఫోన్లో నెరవేర్చలేకపోతే, అవసరం నిర్మాణ ప్రశ్న, firewall సెట్టింగ్ కాదు. మీరు నియంత్రించే పరికరానికి మరియు మీరు నియంత్రించే gatewayకి మధ్య విధానాన్ని విభజించడం సాధారణంగా నిజాయితీ సమాధానం, మరియు Android VPN కనెక్టివిటీ డాక్యుమెంటేషన్ ప్లాట్ఫారమ్ ఒక సేవకు ఏమి అనుమతిస్తుంది, ఏమి అనుమతించదు అని నిర్ధారించే స్థలం.