VPN ఆన్లో ఉంది, VM అందుబాటులో లేదా? మార్గం బహుశా ఎప్పుడూ సమస్య కాదు
host-only నెట్వర్క్లోని అతిథిని దాచినందుకు మీరు టన్నెల్ను నిందించారు. సాధారణంగా మార్గం స్థానికంగానే ఉంటుంది, నిరోధించేది క్లయింట్ ఫిల్టర్ లేదా వినిపించే చిరునామా.
VPNని కనెక్ట్ చేయండి, ఒక నిమిషం క్రితం స్పందించిన డెవలప్మెంట్ VM నిశ్శబ్దమవుతుంది. స్పష్టమైన కథ తనంతట తానే రాయబడుతుంది: టన్నెల్ మార్గాన్ని తీసుకుంది, హోస్ట్ ఇప్పుడు అతిథి ట్రాఫిక్ను కార్పొరేట్ నెట్వర్క్కు పంపుతుంది, పరిష్కారం స్థిర మార్గాన్ని జోడించడం లేదా అడాప్టర్ను బ్రిడ్జ్ మోడ్కు మార్చడం. ఆ కథ కొన్నిసార్లు నిజం. కానీ అది సాధారణ కారణం కాదు, దాని ఆధారంగా మొదట చర్య తీసుకోవడం సాధారణంగా మరొకదాన్ని పాడు చేస్తుంది.
host-only నెట్వర్కింగ్ అనేది హోస్ట్ యాజమాన్యంలోని మరియు దాని అతిథులతో పంచుకునే సాఫ్ట్వేర్ నెట్వర్క్, ఏదైనా భౌతిక కనెక్షన్ నుండి వేరుగా ఉంటుంది. VPN క్లయింట్ యొక్క స్వంత ఇంటర్ఫేస్లో ఏదీ ఆ నెట్వర్క్ను మార్చదు, కాబట్టి దానిని తాకే ముందు, నాలుగు పొరలలో ఏది నిజంగా విఫలమైందో కనుగొనండి.
మార్గం సాధారణంగా ఇప్పటికీ స్థానికమే
రూటింగ్ పట్టిక మొదటి పేజీకి బదులు కెర్నెల్ను అడగండి. Linuxలో, ip route get 192.168.56.10 ఉపయోగించబడే ఖచ్చితమైన మార్గం, ఇంటర్ఫేస్ మరియు మూల చిరునామాను నివేదిస్తుంది, ఇది డిఫాల్ట్ మార్గాన్ని చదివి ఊహించడం కంటే భిన్నమైన సమాధానం. అవుట్పుట్ host-only ఇంటర్ఫేస్ను పేర్కొంటే, ఆ మార్గంలో టన్నెల్ అసలు పాల్గొనదు.
రెండు విషయాలు నిజంగా దానిని పాడు చేయగలవు, రెండూ VPN కాదు, చిరునామా సమస్యలు. host-only ప్రిఫిక్స్తో అతివ్యాప్తి చెందే దూర ఉపనెట్వర్క్ మరింత నిర్దిష్ట మార్గాన్ని గెలిపిస్తుంది, తక్కువ మెట్రిక్తో విస్తృత మార్గాన్ని ఇన్స్టాల్ చేసే VPN క్లయింట్ ప్రిఫిక్స్ను లాగగలదు. రెండూ ఒకే ఆదేశంలో కనిపిస్తాయి: అవుట్పుట్లో పేర్కొన్న ఇంటర్ఫేస్ టన్నెల్ అవుతుంది, సరిదిద్దడం ఆ చిరునామా ప్రణాళిక యజమానికి చెందుతుంది.
మార్గ ఎంపిక మరియు ప్యాకెట్ అనుమతి వేర్వేరు నిర్ణయాలు
మానసిక నమూనా సాధారణంగా జారిపోయే భాగం ఇది. పరిపూర్ణ స్థానిక మార్గంతో కూడా, VPN క్లయింట్ ప్యాకెట్ను తిరస్కరించగలదు. చాలా క్లయింట్లు టన్నెల్ వెలుపల ఏ గమ్యస్థానాలు అనుమతించబడతాయో నిర్ణయించే స్థానిక నెట్వర్క్ యాక్సెస్ విధానాన్ని అమలు చేస్తాయి, కనెక్ట్ చేయబడిన ఉపనెట్వర్క్ ఆ జాబితాను స్వయంచాలకంగా నవీకరించదు.
అందువల్ల వైఫల్యం అప్లికేషన్ వైపు నుండి రూటింగ్ సమస్యలాగానే కనిపిస్తుంది, క్లయింట్ వైపు నుండి పూర్తిగా భిన్నంగా. ip route get సరైన ఇంటర్ఫేస్ను పేర్కొన్నప్పటికీ కనెక్షన్ సమయం ముగిస్తే, మార్గాలను సవరించడం ఆపి బదులుగా క్లయింట్ యొక్క డాక్యుమెంట్ చేయబడిన స్థానిక యాక్సెస్ ప్రవర్తనను చదవండి. కొన్ని క్లయింట్లు స్థానిక ఉపనెట్వర్క్లకు అనుమతి జాబితాను అందిస్తాయి, కొన్ని టన్నెల్ కాని అన్నింటినీ నిరోధిస్తాయి, మరికొన్ని kill switch ప్రారంభమైనప్పుడు మాత్రమే నిరోధిస్తాయి.
ఆ భేదం ముఖ్యం ఎందుకంటే సరిదిద్దడాలు ఒకదానికొకటి మార్చుకోలేనివి. మార్గాన్ని జోడించడం ఫిల్టర్ను సంతృప్తిపరచదు, ఒక అతిథిని చేరుకోవడానికి ఫిల్టర్ను నిలిపివేయడం లక్షణం సూచించే దానికంటే చాలా పెద్ద నిర్ణయం.
అతిథికి కాదు అని చెప్పడానికి మూడు మార్గాలు ఉన్నాయి
ఇంటర్నెట్ బ్రౌజ్ చేయగల అతిథి మీకు కావాల్సిన సేవ గురించి ఏమీ నిరూపించలేదు. వినిపించేది అతిథి లోపల 127.0.0.1 కు బంధించబడి ఉండవచ్చు, అప్పుడు మార్గం ఎంత మంచిదైనా హోస్ట్ నుండి ఏ అభ్యర్థనా చేరుకోలేదు. అతిథిలో ss -ltn తో తనిఖీ చేయండి మరియు పోర్ట్ మాత్రమే కాదు, స్థానిక చిరునామా నిలువును చూడండి.
తర్వాత అతిథి యొక్క స్వంత ఫైర్వాల్. కఠినమైన డిఫాల్ట్ ఉన్న డెవలప్మెంట్ ఇమేజ్ హోస్ట్ ప్యాకెట్లను అంగీకరించి సేవ సరిహద్దులో వాటిని పడవేయగలదు, ఇది రూటింగ్ బ్లాక్ హోల్ లాగానే కనిపించే సమయ ముగింపును సృష్టిస్తుంది. చివరగా సేవ యొక్క స్వంత కాన్ఫిగరేషన్ ఉంది: నిర్దిష్ట హోస్ట్నామ్కు బంధించబడిన వెబ్ యాప్, లేదా అనుమతించబడిన క్లయింట్ చిరునామాల జాబితా, ప్రతి ప్యాకెట్ చేరుకున్నా host-only ఉపనెట్వర్క్ నుండి వచ్చిన అభ్యర్థనను తిరస్కరిస్తుంది.
VM యొక్క నెట్వర్క్ మోడ్ను మార్చడం గురించి ఆలోచించే ముందు ఈ మూడింటిని పూర్తి చేయండి. ప్రతి ఒక్కటి అతిథి కనెక్షన్ను పునఃరూపకల్పన చేయడం కంటే చిన్న మార్పు, ప్రతి దానికి స్పష్టమైన పరీక్ష ఉంది.
బ్రిడ్జ్ నిజంగా ఏమిటి, దాని ఖర్చు ఎంత
అడాప్టర్ను బ్రిడ్జ్ మోడ్కు మార్చడం host-only మార్గానికి మరమ్మతు కాదు. ఇది అతిథిని మరొక నెట్వర్క్లో, సాధారణంగా భౌతిక LANలో ఉంచే నిర్ణయం, అక్కడ అతను అక్కడ నివసించే మిగతా అన్నింటికీ కనిపిస్తాడు. అది మీకు కావాల్సినదే కావచ్చు. కానీ అసలు కాన్ఫిగరేషన్ చేస్తున్నది అది కాదు.
అతిథి నిజంగా ఆ LANలో సమాన సభ్యుడిగా ఉండాల్సిన అవసరం ఉన్నప్పుడు మరియు బహిర్గతం ఆమోదించబడినప్పుడు దాన్ని ఉపయోగించండి. ఒకే సేవ స్పందించడం ఆపేసిందని దాన్ని ఉపయోగించకండి, ఎందుకంటే మార్పు అతిథిని అతనికి వ్యతిరేకంగా అభివృద్ధిని సురక్షితం చేసిన ఒంటరితనం నుండి బయటకు తీసుకురాగలదు.
ఏదైనా ఆమోదించబడిన సరిదిద్దడం తర్వాత నిర్దిష్ట క్రమంలో పరీక్షించండి: హోస్ట్ నుండి అతిథికి కొత్త అభ్యర్థన, టన్నెల్ ద్వారా అవసరమైన కార్పొరేట్ వనరు, మరియు టన్నెల్ ఆఫ్ ఉన్నప్పుడు ఉద్దేశించిన తిరస్కరణ ప్రవర్తన. చివరిది ఇకపై ఉండకపోతే, సరిదిద్దడం సమస్యను దాటి వెళ్లింది.
VirtualBox యొక్క host-only నెట్వర్కింగ్ విభాగం హోస్ట్ వైపు సాఫ్ట్వేర్ ఇంటర్ఫేస్ను మరియు అది బ్రిడ్జ్ కనెక్షన్ నుండి ఎలా భిన్నమో వివరిస్తుంది, రెండు మోడ్లు మార్చుకోగలవని భావించే ముందు చదవదగిన సందర్భం ఇది.