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 ಮತ್ತು ಸರ್ವರ್ ಸಿದ್ಧವೆಂದು ಖಾತರಿ ನೀಡಲಾರದು, ಮತ್ತು ಪ್ರತಿ ಮರುಸಂಪರ್ಕಕ್ಕೂ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ.

ಮೊದಲ ಮಿತಿ ಆಚರಣೆಯಲ್ಲಿ ಅತ್ಯಂತ ಮುಖ್ಯ. ಸರ್ವರ್ ಮಾಯವಾಗುವ ಷೇರ್ ಮೌಂಟ್ ಆದಂತೆ ಕಾಣುವ ಮತ್ತು ಪ್ರವೇಶದಲ್ಲಿ ನಿಲ್ಲುವ ಸಂಪುಟವನ್ನು ಬಿಟ್ಟುಹೋಗುತ್ತದೆ, ಮತ್ತು ಸಭ್ಯ ಪರಿಹಾರ ಯೋಜಿತ ಡಿಸ್ಕನೆಕ್ಟ್ಗೆ ಮೊದಲು ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮುಗಿಸಿ ಅದನ್ನು ಹೊರತೆಗೆಯುವುದು. ಎರಡನೆಯದು ಮೊದಲ ಪ್ರಯತ್ನಗಳ ಹೆಚ್ಚಿನ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ: ಟನೆಲ್ ಮೇಲಿದೆ ಆದರೆ ರೆಸಾಲ್ವರ್ ಇನ್ನೂ ತಲುಪಿಲ್ಲ, ಆದ್ದರಿಂದ ಕಾಯಿರಿ ಮತ್ತು ನಂತರ ಖಚಿತಪಡಿಸಲು ಒಮ್ಮೆ ಕೈಯಿಂದ ಮೌಂಟ್ ಮಾಡಿ. ಮೂರನೆಯದು ಮೊದಲು ಹೇಳಿದ ಪ್ರಶ್ನಿಸುವಿಕೆಯ ರಾಜಿ, ಸರಿಪಡಿಸಬೇಕಾದ ದೋಷವಲ್ಲ.

ಮೇಲ್ವಿಚಾರಣೆ ಇಲ್ಲದ ಯಂತ್ರಕ್ಕೆ ಅಥವಾ ನಿರ್ವಹಿತ ತಂಡಕ್ಕೆ ಈ ವಿನ್ಯಾಸ ತಪ್ಪು ಆಕಾರ. ಡೆಸ್ಕ್ಟಾಪ್ ಆಪ್ಲೆಟ್ ಅನ್ನು ವಿಶೇಷ ಅಧಿಕಾರದ ಸೇವೆಯಾಗಿ ವಿಸ್ತರಿಸುವ ಬದಲು ನಿರ್ವಾಹಕರ ಒಡೆತನದ ಮೌಂಟ್ ನೀತಿ ಬಳಸಿ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು