ಅತಿಥಿ VPN ಮತ್ತು ಹೋಸ್ಟ್ VPN: ಯಾವ ಮಾರ್ಗವು ನಿಜವಾಗಿ ಗೆಲ್ಲುತ್ತದೆ

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

ಮೊದಲು ಅತಿಥಿಯ ಸಂಪರ್ಕವನ್ನು ದಾಖಲಿಸಿ

ಅತಿಥಿಯು ತನ್ನ VPN ಸರ್ವರ್ಗೆ ಹೈಪರ್ವೈಸರ್ ನೀಡಿದ ಮಾರ್ಗದ ಮೂಲಕ ತಲುಪುತ್ತದೆ: ಹೋಸ್ಟ್ನ ಹಿಂದೆ NAT, ಭೌತಿಕ ವಿಭಾಗಕ್ಕೆ ಸೇತುವೆ, ಅಥವಾ ಮೇಲೆ ರೂಟಿಂಗ್ ಸೇರಿಸಿದ ಹೋಸ್ಟ್-ಮಾತ್ರ ನೆಟ್ವರ್ಕ್. ಪ್ರತಿ ಸಂಪರ್ಕವೂ ಅತಿಥಿಯು ಏನನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಹೋಸ್ಟ್ ಅದರ ಸಂಚಾರದೊಂದಿಗೆ ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. NAT ಅಡಿಯಲ್ಲಿ ಅತಿಥಿಯ ಪ್ಯಾಕೆಟ್ಗಳು ಹೋಸ್ಟ್ನಿಂದ ಬಂದಂತೆ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ನ ಸ್ವಂತ ಸುರಂಗವು ಅವುಗಳನ್ನು ಅತಿಥಿಗೆ ಏನೂ ತಿಳಿಯದಂತೆ ಸಾಗಿಸಬಹುದು. ಸೇತುವೆಯ ಅಡಿಯಲ್ಲಿ ಅತಿಥಿಗೆ ವಿಭಾಗದಲ್ಲಿ ತನ್ನದೇ ಇರುವಿಕೆ ಮತ್ತು ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಇರುತ್ತದೆ.

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

ಅತಿಥಿಯ ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಹೊರಕ್ಕೆ ಅನುಸರಿಸಿ

ಅತಿಥಿ VPN ಗೆ ಬೇರೆ ಯಾವುದಾದರೂ ಕೆಲಸ ಮಾಡುವ ಮೊದಲು ತನ್ನ ಸರ್ವರ್ಗೆ ಬಳಸಬಹುದಾದ ಮಾರ್ಗ ಬೇಕು. ಹೋಸ್ಟ್ನ ಸುರಂಗ ಚಾಲನೆಯಲ್ಲಿದ್ದು ಅತಿಥಿಯು NAT ಹಿಂದೆ ಕುಳಿತಾಗ, ಅತಿಥಿಯ ಕೈಹಿಡಿತ ಹೋಸ್ಟ್ನ ಸುರಂಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ, ಅದು ಒಂದೋ ವಿನ್ಯಾಸ, ಇಲ್ಲವೇ ಯಾರೂ ದಾಖಲಿಸದ ಅಪಘಾತ. ಹೋಸ್ಟ್ನ ಸುರಂಗ ಬಿದ್ದು ಅತಿಥಿಯು ಅದನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಅತಿಥಿಯ ಕಡೆ ಒಂದೇ ಒಂದು ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಅತಿಥಿ ಸಂಪರ್ಕ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಹೊರಕ್ಕೆ ಅನುಸರಿಸಿದರೆ ಆ ಎರಡರಲ್ಲಿ ಯಾವುದು ನಿಜವಾಗಿ ನಿಮ್ಮಲ್ಲಿದೆ ಎಂದು ತಿಳಿಯುತ್ತದೆ.

ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಅಗಲವಾದ ಮಾರ್ಗವು ಇನ್ನೊಂದು ಕ್ಲೈಂಟ್ ನಿರೀಕ್ಷಿಸಿದ ಸಂಚಾರವನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಅತಿಥಿಯ ಒಳಗಿನ 0.0.0.0/0 ಮಾರ್ಗ ಮತ್ತು ಪೂರ್ಣ ಸುರಂಗದ ಹೋಸ್ಟ್ ಕ್ಲೈಂಟ್ ಎರಡೂ ಎಲ್ಲದಕ್ಕೂ ಹಕ್ಕು ಸಲ್ಲಿಸುತ್ತವೆ, ಮತ್ತು ಕೊನೆಗೆ ಅನ್ವಯವಾದದ್ದು ಗೆಲ್ಲುತ್ತದೆ. ಅತಿಥಿಯ ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ಗಳು, ಸ್ಥಳೀಯ LAN ಮತ್ತು ದೂರದ ನೆಟ್ವರ್ಕ್ಗಳ ನಡುವಿನ ಅತಿಕ್ರಮಣವು ಖಾಸಗಿ ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಗೆ ಅದೇ ಪರಿಣಾಮವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ವೈಫಲ್ಯಗಳು ದೃಢೀಕರಣ ಸಮಸ್ಯೆಗಳಂತೆ ಕಾಣುತ್ತವೆ; ವಿಳಾಸ ಅನುವಾದದ ವರ್ತನೆಯು ಕಂಟೇನರ್ ನೆಟ್ವರ್ಕಿಂಗ್ ಗಾಗಿ ವಿವರಿಸಿದಂತೆಯೇ ಇರುತ್ತದೆ.

ಮೊದಲು ಮತ್ತು ನಂತರದ ದಾಖಲೆಯನ್ನು ಹೋಲಿಸಿ

ಹೋಸ್ಟ್ನ ಸುರಂಗ ಆಫ್ ಇರುವ ಸ್ಥಿತಿಯಲ್ಲಿ, ಅಥವಾ ನಿಮ್ಮ ನೀತಿ ಅನುಮತಿಸುವ ಯಾವುದೇ ನಿಯಂತ್ರಿತ ಸ್ಥಿತಿಯಲ್ಲಿ ಆಧಾರರೇಖೆ ತೆಗೆದುಕೊಂಡು ಅತಿಥಿಯ ಮಾರ್ಗ ಮತ್ತು ಪರಿಹಾರಕವನ್ನು ದಾಖಲಿಸಿ. ನಂತರ ಸಂಯೋಜಿತ ಸಂರಚನೆಯನ್ನು ಅನ್ವಯಿಸಿ ಎರಡೂ ದಾಖಲೆಗಳನ್ನು ಹೋಲಿಸಿ, ಗೋಪ್ಯತೆಯ ಅಗತ್ಯಗಳನ್ನು ಅಕ್ಷತವಾಗಿ ಇರಿಸಿ. ನೇರ ಆಧಾರರೇಖೆ ಸೂಕ್ತವಲ್ಲದಿದ್ದರೆ, ಹೋಲಿಕೆಯನ್ನು ಬಿಟ್ಟುಬಿಡುವ ಬದಲು ಆ ಮಿತಿಯನ್ನು ದಾಖಲೆಯಲ್ಲಿ ಬರೆಯಿರಿ.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

ಮಾರ್ಗ ಪ್ರಶ್ನೆಯು ನಿರ್ದಿಷ್ಟ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸಾಗಿಸುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಈ ತನಿಖೆಯಲ್ಲಿ ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಸಾಲು. ನಿಯಮಗಳ ಪಟ್ಟಿ ಕೆಲವು ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಎರಡನೇ ಕೋಷ್ಟಕದ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಪರಿಹಾರಕದ ಔಟ್ಪುಟ್ DNS ಅತಿಥಿಯ ಸುರಂಗವನ್ನು ಅನುಸರಿಸಿತೇ ಅಥವಾ ಹೋಸ್ಟ್ನ ಮಾರ್ಗದಲ್ಲೇ ಉಳಿಯಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಅದೇ ಮೂರು ಆದೇಶಗಳನ್ನು ಬದಲಾವಣೆಯ ಮೊದಲು ಮತ್ತು ನಂತರ ಚಲಾಯಿಸಿ, ವ್ಯತ್ಯಾಸವೇ ಅಪರಾಧಿಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

ಮರುಪ್ರಾರಂಭಗಳ ನಡುವೆ ಮಾಲೀಕತ್ವವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ

ಹೋಸ್ಟ್ ಕ್ಲೈಂಟ್ನ ಸ್ಥಳೀಯ ಪ್ರವೇಶ ನಿರ್ಬಂಧವು ವರ್ಚುವಲ್ NAT ಅಥವಾ ಸೇತುವೆಗೆ ಸಂಚಾರವನ್ನು ತಡೆಯಬಹುದು, ಮತ್ತು ಆ ನಿರ್ಬಂಧವನ್ನು ಹೆಚ್ಚಾಗಿ ಅತಿಥಿಯ ರುಜುವಾತು ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸಲಾಗುತ್ತದೆ. ಪರೀಕ್ಷೆ ಪಾಸಾಗಲು ನಿರ್ಬಂಧವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್ನ ದಾಖಲಿತ ವರ್ತನೆಯನ್ನು ಓದಿ. ಬೆಂಬಲಿತ ತಿದ್ದುಪಡಿಯ ನಂತರ ಅತಿಥಿ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ನೀವು ಬಯಸುವ ವೈಫಲ್ಯ ನೀತಿಯನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ. ಯಶಸ್ವಿಯಾಗಿ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಹೋಸ್ಟ್ ಅತಿಥಿಯ ಮಾರ್ಗ ಅಥವಾ ಪರಿಹಾರಕದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಯಾವ ಬದಿಯದ್ದು ಎಂದು ನಿರ್ಧರಿಸಿ ಅದನ್ನು ಕಾರ್ಯಾಚರಣಾ ಪುಸ್ತಕದಲ್ಲಿ ಬರೆಯಿರಿ. ಅತಿಥಿಯ ಮರುಪ್ರಾರಂಭ ಅಥವಾ ಹೋಸ್ಟ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಬದಲಾವಣೆ ಮಾಲೀಕತ್ವವನ್ನು ಸದ್ದಿಲ್ಲದೆ ತಿರುಗಿಸಿದರೆ, ಎಂದೂ ತಪ್ಪಿತಸ್ಥವಲ್ಲದ VPN ಬಗ್ಗೆ ದೋಷ ವರದಿ ಬರುತ್ತದೆ. ಏರ್ಪಾಡು ಮರುಬೂಟ್ ಅನ್ನು ಯಾರೂ ಏಕೆ ಕೆಲಸ ಮಾಡಿತು ಎಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳದೆಯೇ ದಾಟಬೇಕು.