VPN క్లయింట్కు నెట్వర్క్ను తిరిగి కాన్ఫిగర్ చేయడానికి ప్రత్యేక అధికారాల సహాయం అవసరం, మరియు ఆ వాస్తవం దాని చుట్టూ ఉన్న ప్రతిదానికీ చాలా విస్తృతంగా వర్తింపజేయబడుతుంది. ఫైల్ షేర్ను మౌంట్ చేసే స్క్రిప్ట్కు root అవసరం లేదు, ఎందుకంటే షేర్ సైన్-ఇన్ అయిన వినియోగదారు సెషన్కు మరియు ఆ వినియోగదారు ఆధారాలకు చెందుతుంది. మౌంట్ను ప్రత్యేక అధికారాల మార్గం నుండి బయటకు తీయడం sudo నియమాలు, root హుక్లు మరియు తోడుగా వచ్చే యాప్లలో మార్పుల అవసరాన్ని తొలగిస్తుంది. మిగిలేది ఒక చిన్న యాప్లెట్, అది తెరిచే ఉంటుంది, ఒక ప్రొఫైల్ను గమనిస్తుంది మరియు ఒకే ఒక ప్రయత్నం చేస్తుంది.

ఇది వినియోగదారు సెషన్లో ఎందుకు ఉంటుంది

మౌంట్ చేయబడిన వాల్యూమ్ దాన్ని మౌంట్ చేసిన సెషన్ యొక్క లక్షణం. మరో వినియోగదారు సెషన్ దాన్ని చూడదు, మరియు root స్వంతమైన మౌంట్ Finder సృష్టించిన దానికంటే భిన్నంగా ప్రవర్తిస్తుంది. మౌంట్ను వినియోగదారు సెషన్లో ఉంచడం ఆ అర్థాన్ని కాపాడుతుంది.

ప్రత్యేక అధికారాల సహాయకులు నిజంగా అవసరమైన భాగాల కోసమే ఉన్నాయి: టన్నెల్ ఇంటర్ఫేస్ సృష్టించడం, మార్గాలను మార్చడం, రిజాల్వర్ను నవీకరించడం. SMB షేర్ను మౌంట్ చేయడం ఆ భాగాల్లో ఒకటి కాదు. దాన్ని అలాగే భావించి వ్యవహరిస్తే పాస్వర్డ్ లేని sudo మరియు ఎవరూ లేని సమయంలో నడిచే root స్క్రిప్ట్ మధ్య ఎంపిక చేసుకోవాల్సి ఉంటుంది. రెండూ సమస్యను సమర్థించే దానికంటే పెద్ద ప్రమాదాలు, మరియు వినియోగదారు సెషన్ విధానం ఆ ఎంపికను పూర్తిగా నివారిస్తుంది.

Tunnelblick యొక్క సొంత కనెక్షన్ హుక్లు ఇక్కడ ప్రత్యామ్నాయం కావు, ఎందుకంటే అవి డెస్క్టాప్ సెషన్ వెలుపల నడుస్తాయి మరియు క్లయింట్ స్క్రిప్ట్లతో వాటి క్రమం నిర్వచించబడలేదు. వినియోగదారు యాప్లెట్ నుండి స్థితిని అడగడం తక్కువ ఊహలతో కూడిన చిన్న యంత్రాంగం.

మొదట చేతితో షేర్ పనిచేస్తుందని నిరూపించండి

ఆటోమేషన్ లేని మార్గాన్ని, అనుమతిని లేదా ఖాతాను ఇవ్వలేదు. ఏదైనా స్క్రిప్ట్ రాసే ముందు VPNకు చేతితో కనెక్ట్ అయి, షేర్ను Finderలో తెరవండి. అది విఫలమైతే స్క్రిప్ట్ మరింత గందరగోళంగా విఫలమవుతుంది.

స్క్రిప్ట్ ఉపయోగించే మూడు విలువలను నమోదు చేయండి: ప్రొఫైల్ పేరు Tunnelblick చూపించే విధంగానే, షేర్ URL మరియు మౌంట్ తర్వాత Finder చూపించే వాల్యూమ్ పేరు. వాల్యూమ్ పేరు ముఖ్యం ఎందుకంటే ఉన్న మౌంట్ను తనిఖీ చేయడం దాన్నే ఉపయోగిస్తుంది, మరియు పేరు మీద మాత్రమే ఆధారపడిన తనిఖీ సౌలభ్య రక్షణే తప్ప సర్వర్ గుర్తింపుకు రుజువు కాదు. మెషీన్పై ప్రత్యేకమైన పేరును ఉపయోగించండి. తర్వాత సర్వర్ ఏమైనా ప్రతిస్పందిస్తుందా అని నిర్ధారించండి.

smbutil view //files.corp.example
osascript -e 'tell application "Tunnelblick" to get state of first configuration whose name is "Office"'
mount | grep -i smbfs

మొదటి ఆదేశం సర్వర్ ప్రతిస్పందిస్తుందని, రెండవది ప్రొఫైల్ పేరు పరిష్కారమవుతుందని నిరూపిస్తాయి, మూడవది విజయవంతమైన మౌంట్ ఎలా ఉంటుందో చూపిస్తుంది. ఏదైనా ఆటోమేట్ చేసే ముందు మూడింటినీ నమోదు చేయండి.

Tunnelblick నుండి ప్రొఫైల్ స్థితిని చదవండి

Tunnelblick తన కాన్ఫిగరేషన్లను మరియు వాటి స్థితులను AppleScript ద్వారా బహిర్గతం చేస్తుంది, మరియు ఈ రూపకల్పనకు కావలసిన ఏకైక హుక్ అదే. ముఖ్యమైన స్థితి ఆ ఒక ప్రొఫైల్ కోసం నివేదించబడే స్ట్రింగ్, యాప్ ఉనికి కాదు.

ప్రశ్నించడానికి కొన్ని ధరలు ఉన్నాయి, వాటిని పేర్కొనవలసి ఉంటుంది. విరామం కంటే చిన్న పునఃకనెక్షన్ గమనించబడకుండా జరిగిపోవచ్చు, మరియు యాప్లెట్ ఆ మార్పును అసలు చూడదు. మౌంట్ కాపలాదారుకు ఇది ఆమోదయోగ్యం, ప్రతి సంఘటనకు ప్రతిస్పందించాల్సిన ఏదైనా విషయానికి ఆమోదయోగ్యం కాదు. సంఘటన-స్థాయి ఖచ్చితత్వం కావాలంటే ఇది తప్పు యంత్రాంగం, టైమర్ను తగ్గించాల్సిన యంత్రాంగం కాదు. విరామాన్ని ఎంచుకునేటప్పుడు ఈ రాజీని గుర్తుంచుకోండి.

property attempted : false

on idle
    set profileName to "Office"
    set shareURL to "smb://files.corp.example/OfficeTeam"
    set volName to "OfficeTeam"
    tell application "Tunnelblick" to set vpnState to state of first configuration whose name is profileName
    if vpnState is not "CONNECTED" then
        set attempted to false
        return 20
    end if
    tell application "Finder" to set mounted to (exists disk volName)
    if (not mounted) and (not attempted) then
        set attempted to true
        try
            mount volume shareURL
        end try
    end if
    return 20
end idle

తెరిచి ఉండే ఎంపికతో దాన్ని అప్లికేషన్గా ఎగుమతి చేయండి, తర్వాత sudo బదులు సైన్-ఇన్ అయిన సెషన్లో ప్రారంభించండి.

ఒకసారి మౌంట్ చేయండి, తర్వాత ప్రయత్నం ఆపండి

ప్రయత్నించారు అనే ఫ్లాగ్ ఇది ఆధారాలను ఊహించే లూప్గా మారకుండా నిరోధిస్తుంది. యాప్లెట్ ప్రయత్నించిన తర్వాత మళ్లీ ప్రయత్నించే ముందు కనెక్షన్ స్థితి మారడానికి వేచి ఉంటుంది.

ఈ ప్రవర్తన ఉద్దేశపూర్వకం. మౌంట్ను నిరాకరించే షేర్ సాధారణంగా మళ్లీ ప్రయత్నించడం ద్వారా సరిచేయలేని కారణం వల్ల నిరాకరిస్తుంది, మరియు పునరావృత ప్రయత్నాలు ఒక అభ్యర్థనను వాటి వరుసగా మారుస్తాయి. ప్రొఫైల్ కనెక్ట్ అయిన స్థితి నుండి బయటకు వెళ్లినప్పుడు ఫ్లాగ్ రీసెట్ అవుతుంది, కాబట్టి నిజమైన పునఃకనెక్షన్ సరిగ్గా ఒక కొత్త ప్రయత్నాన్ని ఇస్తుంది. యాప్లెట్ నుండి బయటకు వెళ్లి మళ్లీ ప్రారంభించడం కూడా దాన్ని రీసెట్ చేస్తుంది, అదే చేతితో చేసిన జోక్యం. ఏ మార్గమూ వైఫల్యాన్ని దాచదు; రెండూ దాన్ని Finderలో కనిపించేలా ఉంచుతాయి.

స్క్రిప్ట్ ఎలాంటి పాస్వర్డ్ను తీసుకెళ్లదు, అలాగే ఉండాలి. మౌంట్ చర్య అడగనివ్వండి, మరియు కీచెయిన్ సంస్థ మద్దతు ఇచ్చేది చేయనివ్వండి. URLలో ఆధారాన్ని పొందుపరచడం సౌలభ్య స్క్రిప్ట్ను తిప్పవలసిన రహస్యంగా మారుస్తుంది.

సహాయకుడు చేయలేని పనులు

మూడు పరిమితులు యాప్లెట్ పక్కన రాయదగినవి. నెట్వర్క్ వైఫల్యం తర్వాత బిజీ వాల్యూమ్ను బయటకు తీయలేదు, స్థితి కనెక్ట్ అయింది అని చెప్పినప్పుడు DNS మరియు సర్వర్ సిద్ధంగా ఉన్నారని హామీ ఇవ్వలేదు, మరియు ప్రతి పునఃకనెక్షన్కు ప్రతిస్పందించదు.

మొదటి పరిమితి ఆచరణలో అత్యంత ముఖ్యమైనది. సర్వర్ మాయమయ్యే షేర్ మౌంట్ అయినట్టు కనిపించి యాక్సెస్ సమయంలో నిలిచిపోయే వాల్యూమ్ను వదిలివేస్తుంది, మరియు మర్యాదపూర్వక పరిష్కారం ప్రణాళికాబద్ధమైన డిస్కనెక్ట్కు ముందు ఫైల్ కార్యకలాపాలను పూర్తి చేసి దాన్ని బయటకు తీయడం. రెండవది చాలా మొదటి ప్రయత్నాల వైఫల్యాలను వివరిస్తుంది: టన్నెల్ పైన ఉంది కానీ రిజాల్వర్ ఇంకా చేరుకోలేదు, కాబట్టి వేచి ఉండి, నిర్ధారించుకోవడానికి ఒకసారి చేతితో మౌంట్ చేయండి. మూడవది ముందు చెప్పిన ప్రశ్నించే రాజీ, సరిచేయాల్సిన బగ్ కాదు.

పర్యవేక్షణ లేని మెషీన్కు లేదా నిర్వహించబడే సమూహానికి ఈ రూపకల్పన తప్పు ఆకారం. డెస్క్టాప్ యాప్లెట్ను ప్రత్యేక అధికారాల సేవగా విస్తరించడం బదులు నిర్వాహకుడి స్వంతమైన మౌంట్ విధానాన్ని ఉపయోగించండి.

సంబంధిత వ్యాసాలు