Windows లో VPN స్థానిక LAN ను నిరోధిస్తుంది: మార్గమా లేక క్లయింట్ విధానమా?
Windows లో స్థానిక LAN యాక్సెస్ రెండు వేర్వేరు కారణాల వల్ల విరిగిపోతుంది: లేని మార్గం, లేక సబ్నెట్ను విసిరే గేట్వే విధానం. మూడు తనిఖీలు ఏదో చెబుతాయి.
మీ స్వంత డెస్క్పై ఉన్న ప్రింటర్, NAS లేక డెవలప్మెంట్ మెషిన్ పని VPN కనెక్ట్ అయిన క్షణంలోనే స్పందించడం ఆపేస్తుంది. కొన్నిసార్లు ఒక మార్గ ఆదేశం దాన్ని సెకన్లలో సరిచేస్తుంది; కొన్నిసార్లు అదే మార్గం సరైనదైనా ప్యాకెట్లు ఇప్పటికీ మాయమవుతాయి, అంటే మీరు సమాన లక్షణాలున్న మరో సమస్యను చూస్తున్నారు. నిర్ణయం మూడు ప్రశ్నలకు వస్తుంది, వాటిని తప్పు క్రమంలో అడగడమే ప్రజలు సాయంత్రమంతా మార్గాలను తొలగించి మళ్లీ జోడించడంలో గడపడానికి కారణం.
ఏ ఆదేశానికైనా ముందు మూడు ప్రశ్నలు
మొదటిది: స్థానిక ప్రిఫిక్స్ కోసం ఎంట్రీ ఉందా, అది భౌతిక అడాప్టర్ను సూచిస్తుందా? రెండవది: కనెక్ట్ అయ్యేటప్పుడు క్లయింట్ గేట్వే నుండి స్థానిక నెట్వర్క్ అనుమతి లేక నిరాకరణ పొందుతుందా? మూడవది: మీకు LANకి బయటకు వెళ్లే యాక్సెస్ మాత్రమే కావాలా, లేక ఇంటర్నెట్లోని ఏదైనా మీ మెషిన్పై నడుస్తున్న సేవను కూడా చేరుకోవాలా?
మొదటి ప్రశ్న రూటింగ్ లోపాన్ని ఫిల్టరింగ్ లోపం నుండి వేరు చేస్తుంది. రెండవది మార్గ సవరణకు అసలు పని చేయడానికి అనుమతి ఉందా అని చెబుతుంది. మూడవది మరమ్మత్తును మారుస్తుంది: మార్గం బయటకు వెళ్లే ట్రాఫిక్ను సరిచేస్తుంది, అయితే చేరుకోలేని లోపలికి వచ్చే సేవ సాధారణంగా లిజనర్ బైండింగ్ మరియు తిరిగి వెళ్లే మార్గ సమస్య, మార్గం దాన్ని మరింత దిగజార్చుతుంది.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
ప్రశ్న ఒకటి: మార్గం, ఫిల్టర్ లేక పేరు
ఏదైనా జోడించే ముందు పట్టికను చదవండి. ఇంటర్ఫేస్ ఇండెక్స్ ముఖ్యం, ఎందుకంటే క్రింది ప్రతి మార్గ ఆదేశం దానికే అనుసంధానించబడి ఉంది:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric
నేరుగా కనెక్ట్ అయిన సబ్నెట్ టన్నెల్ పైన ఉన్నప్పటికీ సాధారణంగా ఆన్-లింక్ మార్గాన్ని ఉంచుకుంటుంది, కాబట్టి ఎంట్రీ ఉండవచ్చు మరియు ట్రాఫిక్ ఇప్పటికీ విఫలం కావచ్చు. ఆ కలయిక రూటింగ్ తర్వాత నడిచే ఫిల్టర్ సంతకం, మరియు మరింత నిర్దిష్టమైన రెండవ మార్గం ఏమీ మార్చని సందర్భం అదే.
చిరునామా ప్రకారం మరియు పేరు ప్రకారం విడివిడిగా పరీక్షించండి. ping 192.168.1.50 స్పందిస్తే మరియు net view 192.168.1.50 స్పందించకపోతే, రూటింగ్ పట్టిక ఎప్పుడూ సమస్య కాదు: టన్నెల్ రిజాల్వర్ను మార్చింది మరియు స్థానిక పేరు ఇక పరిష్కారం కాదు. దాని కోసం మార్గం జోడించడం వృథా పని.
ప్రశ్న రెండు: గేట్వే స్థానిక LAN యాక్సెస్ను అనుమతిస్తుందా?
వాణిజ్య క్లయింట్ మార్గాల కంటే ఎక్కువ ఇన్స్టాల్ చేస్తుంది. కనెక్ట్ అయ్యేటప్పుడు విధానాన్ని పొందుతుంది, ఆ విధానంలో స్థానిక నెట్వర్క్ కోసం స్పష్టమైన అనుమతి ఉండవచ్చు. Cisco IPsec అమరికల్లో సమూహ విధానం split-tunneling సెట్టింగ్ను మరియు స్థానిక LAN యాక్సెస్ కోసం ప్రత్యేక జెండాను కలిగి ఉంటుంది; క్లయింట్లోని చెక్బాక్స్ గేట్వే తిరస్కరించగల అభ్యర్థన. AnyConnectలో ప్రొఫైల్ split చేర్చడం మరియు మినహాయింపు జాబితాలను మరియు అదే అనుమతిని నియంత్రిస్తుంది. Windows RRASలో సమానమైనవి ప్రొఫైల్లోని డిఫాల్ట్ గేట్వే ఎంపిక మరియు సర్వర్ కేటాయించే స్థిర మార్గాలు.
జెండా ఆఫ్ ఉన్నప్పుడు, డాక్యుమెంట్ చేయబడిన ప్రవర్తన ఏమిటంటే, చెల్లుబాటు అయ్యే, మరింత నిర్దిష్టమైన మార్గం ఉన్నప్పటికీ క్లయింట్ నేరుగా కనెక్ట్ అయిన సబ్నెట్కు ట్రాఫిక్ను నిరోధిస్తుంది. అందుకే క్లయింట్ యాజమాన్యంలో లేని మార్గాలు కూడా జోడించిన కొన్ని సెకన్ల తర్వాత మాయమవుతాయి: క్లయింట్ తనకు చెప్పిన స్థితిని తిరిగి నిర్మిస్తున్నది, మీతో పోరాడడం లేదు.
క్లయింట్ లాగ్ కనెక్ట్ అయ్యేటప్పుడు నిర్ణయాన్ని నమోదు చేస్తుంది, దాన్ని చదవడం మెషిన్పై ఏ ప్రయోగం కంటే వేగం. లాగ్ స్థానిక యాక్సెస్ నిరోధించబడిందని చెబితే, ఆపండి: ఏ కమాండ్-లైన్ సవరణ దాన్ని జయించదు, మిగిలిన మార్గాలు విధాన మార్పు, టన్నెల్ ద్వారా వనరును చేరుకోవడం, లేక క్లయింట్ను వర్చువల్ మెషిన్లో ఉంచి హోస్ట్ను స్థానిక నెట్వర్క్లో వదిలేయడం.
ప్రశ్న మూడు: మీకు ఏ దిశ కావాలి?
సమీప పరికరానికి బయటకు వెళ్లే ట్రాఫిక్ రూటింగ్ ప్రశ్న. LAN ప్రిఫిక్స్ను స్థానిక గేట్వే వైపు టన్నెల్ డిఫాల్ట్ మార్గాన్ని ఓడించగల తగినంత తక్కువ మెట్రిక్తో మళ్లించండి:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p
రెండవ రూపం ఒకే పరికరాన్ని పిన్ చేస్తుంది, ఒక చిరునామాయే మొత్తం అవసరమైనప్పుడు మీకు కావాల్సింది అదే. netsh సమానమైనది అదే నిర్ణయాన్ని ఇండెక్స్కు బదులుగా ఇంటర్ఫేస్ పేరుతో నమోదు చేస్తుంది:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent
చిరునామా మరియు మాస్క్ సరిపోలకపోతే మార్గ ఆదేశాలు పరామితి తప్పుతో విఫలమవుతాయి, ఉదాహరణకు /24 మాస్క్తో హోస్ట్ చిరునామా. సబ్నెట్ మార్గానికి నెట్వర్క్ చిరునామాను, ఒకే హోస్ట్కు హోస్ట్ మాస్క్ను ఉపయోగించండి.
లోపలికి వచ్చేది భిన్నం. అదే మెషిన్పై ఉన్న VNC లేక SSH సర్వర్, లోపలికి వచ్చే కనెక్షన్కు సమాధానాలు VPN గేట్వే ద్వారా బయటకు వెళ్లి ఎప్పుడూ తిరిగి రాకపోతే చేరుకోలేనిదవుతుంది. మార్గాలను తాకే ముందు సేవ ఏమి వింటుందో తనిఖీ చేయండి:
netstat -ano | findstr :5900
ఒక నిర్దిష్ట చిరునామాకు బద్ధమైన లిజనర్ మరొక ఇంటర్ఫేస్పై స్పందించదు. దాన్ని అన్ని ఇంటర్ఫేస్లకు బద్ధం చేయడం మీరు నమ్మే నెట్వర్క్కు పరిమితమైన ఫైర్వాల్ నియమంతో కలిసి తీసుకునే ఉద్దేశపూర్వక నిర్ణయం. ఆ తర్వాతే మార్గ మరమ్మత్తు తిరిగి వెళ్లే మార్గాన్ని పునరుద్ధరిస్తుంది.
సరిపోయే అతి చిన్న మార్పును వర్తించండి
మరో సాధారణ చర్య IPv4 అధునాతన లక్షణాల్లో “రిమోట్ నెట్వర్క్లో డిఫాల్ట్ గేట్వేను ఉపయోగించు” అనే టిక్కును తీసివేయడం. ఇది ఇంటర్నెట్ ట్రాఫిక్ను స్థానికంగా ఉంచుతుంది, కానీ ఒకేసారి రెండు పనులు చేస్తుంది: VPN డిఫాల్ట్ మార్గం కాదు, మరియు క్లయింట్ రిమోట్ నెట్వర్క్ కోసం మార్గాలను, multicast సహా, పొందడం ఆపేస్తుంది. టిక్కు తీసివేస్తే, సర్వర్ ప్రతి క్లయింట్కు అవసరమైన నిర్దిష్ట రిమోట్ ప్రిఫిక్స్లను తోస్తే తప్ప రిమోట్ LAN మాయమవుతుంది.
ఆ అసమానత పని క్రమాన్ని నిర్ణయిస్తుంది. రిమోట్ వైపు పూర్తిగా చేరుకోగలిగి ఉండాలంటే, సర్వర్ నుండి రిమోట్ సబ్నెట్లను తోయండి మరియు స్థానిక డిఫాల్ట్ను అలాగే వదిలేయండి. సర్వర్ను మార్చలేకపోతే, టన్నెల్ కేటాయించిన చిరునామా ద్వారా రిమోట్ ప్రిఫిక్స్కు శాశ్వత మార్గాన్ని జోడించి, route print తో ప్రిఫిక్స్ VPN ఇంటర్ఫేస్కు మరియు డిఫాల్ట్ ఇప్పటికీ భౌతిక గేట్వేకు సూచిస్తున్నాయా అని తనిఖీ చేయండి.
తర్వాత మరమ్మత్తు తిరిగి కనెక్ట్ అవ్వడాన్ని తట్టుకుంటుందని నిర్ధారించండి, ఎందుకంటే శాశ్వతం కాని మార్గాలు అడాప్టర్తో మరణిస్తాయి, ప్రతి కనెక్షన్ తర్వాత నడిచే స్క్రిప్ట్ వాటికి నిజాయితీ ప్రదేశం. అదే సెషన్లో ఒక స్థానిక పరికరాన్ని మరియు ఒక రిమోట్ వనరును పరీక్షించి, డిస్కనెక్ట్ చేసి, మళ్లీ కనెక్ట్ చేసి మళ్లీ పరీక్షించండి. మార్గం సరిగ్గా కనిపిస్తున్నా స్థానిక పరికరం ఇప్పటికీ విఫలమైతే, ప్రశ్న రెండుకు తిరిగి వెళ్లండి: క్లయింట్ ఫిల్టర్ చేస్తోంది, సమాధానం విధాన మార్పు, రెండవ పోటీ మార్గం కాదు.