VPN ಆನ್ ಆಗಿದೆ, VM ತಲುಪಲಾಗುತ್ತಿಲ್ಲವೇ? ಮಾರ್ಗವು ಬಹುಶಃ ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ
host-only ನೆಟ್ವರ್ಕ್ನ ಅತಿಥಿಯನ್ನು ಮರೆಮಾಡಿದ್ದಕ್ಕಾಗಿ ನೀವು ಸುರಂಗವನ್ನು ದೂಷಿಸಿದಿರಿ. ಸಾಮಾನ್ಯವಾಗಿ ಮಾರ್ಗವು ಸ್ಥಳೀಯವಾಗಿಯೇ ಇರುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಫಿಲ್ಟರ್ ಅಥವಾ ಆಲಿಸುವ ವಿಳಾಸವು ತಡೆಯುತ್ತದೆ.
VPN ಸಂಪರ್ಕಿಸಿ, ಮತ್ತು ಒಂದು ನಿಮಿಷದ ಹಿಂದೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದ್ದ ಅಭಿವೃದ್ಧಿ VM ಸದ್ದಿಲ್ಲದೆ ಆಗುತ್ತದೆ. ಸ್ಪಷ್ಟ ಕಥೆ ತಾನೇ ಬರೆಯುತ್ತದೆ: ಸುರಂಗವು ಮಾರ್ಗವನ್ನು ಹಿಡಿಯಿತು, ಹೋಸ್ಟ್ ಈಗ ಅತಿಥಿ ಸಂಚಾರವನ್ನು ಕಾರ್ಪೊರೇಟ್ ನೆಟ್ವರ್ಕ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಪರಿಹಾರವೆಂದರೆ ಸ್ಥಿರ ಮಾರ್ಗ ಸೇರಿಸುವುದು ಅಥವಾ ಅಡಾಪ್ಟರ್ ಅನ್ನು ಸೇತುವೆ ಮೋಡ್ಗೆ ಬದಲಿಸುವುದು. ಆ ಕಥೆ ಕೆಲವೊಮ್ಮೆ ನಿಜ. ಆದರೆ ಅದು ಸಾಮಾನ್ಯ ಕಾರಣವಲ್ಲ, ಮತ್ತು ಅದರ ಮೇಲೆ ಮೊದಲು ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಏನನ್ನಾದರೂ ಮುರಿಯುತ್ತದೆ.
host-only ನೆಟ್ವರ್ಕಿಂಗ್ ಹೋಸ್ಟ್ನ ಒಡೆತನದಲ್ಲಿರುವ ಮತ್ತು ಅದರ ಅತಿಥಿಗಳೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುವ ಸಾಫ್ಟ್ವೇರ್ ನೆಟ್ವರ್ಕ್ ಆಗಿದೆ, ಯಾವುದೇ ಭೌತಿಕ ಸಂಪರ್ಕದಿಂದ ಪ್ರತ್ಯೇಕ. VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಯಾವುದೂ ಆ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ನಾಲ್ಕು ಪದರಗಳಲ್ಲಿ ಯಾವುದು ನಿಜವಾಗಿ ವಿಫಲವಾಯಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.
ಮಾರ್ಗವು ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ನೂ ಸ್ಥಳೀಯವಾಗಿರುತ್ತದೆ
ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಮೊದಲ ಪುಟದ ಬದಲು ಕರ್ನೆಲ್ ಅನ್ನು ಕೇಳಿ. ಲಿನಕ್ಸ್ನಲ್ಲಿ 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 ನೆಟ್ವರ್ಕಿಂಗ್ ವಿಭಾಗ ಹೋಸ್ಟ್ ಕಡೆಯ ಸಾಫ್ಟ್ವೇರ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಅದು ಸೇತುವೆ ಸಂಪರ್ಕದಿಂದ ಹೇಗೆ ಭಿನ್ನ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಇದು ಎರಡು ಮೋಡ್ಗಳು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದು ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಓದಲು ಯೋಗ್ಯವಾದ ಉಲ್ಲೇಖ.