ನಿಮ್ಮ VM ಹೋಸ್ಟ್ನ VPN ಬಳಸುತ್ತದೆಯೇ? ಗೆಸ್ಟ್ನ ಒಳಗಿನಿಂದ ಪರೀಕ್ಷಿಸಿ

ನೀವು ಹೋಸ್ಟ್ನ ಸಾರ್ವಜನಿಕ IP ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತೀರಿ, ಅದು VPN ತೋರಿಸುತ್ತದೆ, ಮತ್ತು VM ರಕ್ಷಿತವಾಗಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತೀರಿ. ಆ ತೀರ್ಮಾನಕ್ಕೆ ಈ ಪರೀಕ್ಷೆ ಆಧಾರ ನೀಡುವುದಿಲ್ಲ. ಗೆಸ್ಟ್ಗೆ ಅದರದೇ ರೂಟಿಂಗ್ ಟೇಬಲ್, ಅದರದೇ ರೆಸಾಲ್ವರ್ ಮತ್ತು ಅದರದೇ ಇಂಟರ್ಫೇಸ್ಗಳಿವೆ, ಮತ್ತು ಹೋಸ್ಟ್ನ ನಿರ್ಗಮನ ವಿಳಾಸವು ಅವುಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಪರೀಕ್ಷೆಯು ಗೆಸ್ಟ್ನ ಒಳಗೆ ನಡೆಯಬೇಕು, ಮತ್ತು ಏನನ್ನು ಅಳೆಯಲಾಗಿದೆ ಎಂಬುದನ್ನು ಹೆಸರಿಸಬೇಕು.

ಗೆಸ್ಟ್ನ ಒಳಗಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಹೋಸ್ಟ್ನ ಬ್ರೌಸರ್ನಿಂದ ಅಲ್ಲ

ಮೊದಲು ಹೈಪರ್ವೈಸರ್ನ ನೆಟ್ವರ್ಕ್ ಮೋಡ್ ಅನ್ನು ದಾಖಲಿಸಿ: NAT, bridged, host-only ಅಥವಾ macvtap. NAT ಮೋಡ್ನಲ್ಲಿ ಹೋಸ್ಟ್ ಗೆಸ್ಟ್ನ ಸಂಚಾರವನ್ನು ರೂಟ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ರೂಟ್ಗಳನ್ನು ಹೇಗೆ ಸ್ಥಾಪಿಸುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ಹೋಸ್ಟ್ನ ಟನೆಲ್ ಅನ್ವಯವಾಗಬಹುದು ಅಥವಾ ಇಲ್ಲ. Bridged ಮೋಡ್ನಲ್ಲಿ ಗೆಸ್ಟ್ ಭೌತಿಕ LAN ನಲ್ಲಿ ಸಮಾನ ಸ್ಥಾನದಲ್ಲಿದೆ ಮತ್ತು ಹೋಸ್ಟ್ನ ಟನೆಲ್ ಅಪ್ರಸ್ತುತ. ಈ ಎರಡು ಮೋಡ್ಗಳು ಒಂದೇ ಹೋಸ್ಟ್ ಸಂರಚನೆಯಿಂದ ವಿರುದ್ಧ ಉತ್ತರಗಳನ್ನು ನೀಡುತ್ತವೆ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೋಡ್ ಅನ್ನು ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಫಲಿತಾಂಶದ ಅರ್ಥವನ್ನು ಅದೇ ನಿರ್ಧರಿಸುತ್ತದೆ.

ಗಮ್ಯಸ್ಥಾನ ತಿಳಿದಿರುವ ಒಂದು ವಿನಂತಿ ಮಾಡಿ

ತಾನು ನೋಡಿದ ಮೂಲ ವಿಳಾಸವನ್ನು ವರದಿ ಮಾಡುವ ಸೇವೆಗೆ ನಿರುಪದ್ರವ ವಿನಂತಿ ಕಳುಹಿಸಿ. ನಂತರ ಆ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಗೆಸ್ಟ್ನದೇ ರೂಟಿಂಗ್ ನಿರ್ಧಾರವನ್ನು ಪರಿಶೀಲಿಸಿ: ip route get 203.0.113.5 ಗೆಸ್ಟ್ ಬಳಸುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಗೇಟ್ವೇ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.

ಇಂಟರ್ಫೇಸ್ ಗೆಸ್ಟ್ನ ಸಾಮಾನ್ಯ NIC ಆಗಿದ್ದರೆ, ಆ ಸಂಚಾರವು ಗೆಸ್ಟ್ನ ಒಳಗಿನ ಟನೆಲ್ ಮೂಲಕ ಹೋಗುತ್ತಿಲ್ಲ.

ಎರಡನೇ ಅಡಾಪ್ಟರ್, ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಅಥವಾ ಗೆಸ್ಟ್ ಬದಿಯ VPN ಕ್ಲೈಂಟ್ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ಗೆ ಉತ್ತರವನ್ನು ಬದಲಿಸಬಹುದು, ಇನ್ನೊಂದಕ್ಕೆ ಇಲ್ಲ. ಶೆಲ್ನಿಂದ ಸಾಮಾನ್ಯ ವಿನಂತಿಯನ್ನು ಅಲ್ಲ, ನಿಮಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ.

ರೆಸಾಲ್ವರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

ಬದಲಾದ ನಿರ್ಗಮನ ವಿಳಾಸವು ಆ ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಯಾವ ರೆಸಾಲ್ವರ್ ನಿರ್ವಹಿಸಿತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗೆ ಹೊಂದುವ ಸಾಧನದಿಂದ ಹೆಸರನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಶ್ನಿಸಿ ಮತ್ತು ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ. Split DNS ಎಂದರೆ ರೆಸಾಲ್ವರ್ ಪ್ರಶ್ನೆ ಮತ್ತು ರೂಟಿಂಗ್ ಪ್ರಶ್ನೆಗೆ ಬೇರೆ ಬೇರೆ ಉತ್ತರಗಳಿರುತ್ತವೆ.

ಅವೆರಡು ಯಾವುದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಭಿನ್ನವಾಗಬಹುದು, ಮತ್ತು ಆ ಭಿನ್ನತೆಯೇ ಹೆಚ್ಚಾಗಿ ನಿಜವಾದ ದೋಷವಾಗಿರುತ್ತದೆ.

systemd ಹೋಸ್ಟ್ನಲ್ಲಿ, resolvectl query ಉತ್ತರದ ಹಿಂದಿನ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು DNS ಸರ್ವರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಹಳೆಯ ಸಂರಚನೆಗಳು ಸರ್ವರ್ ಅನ್ನು dig ಔಟ್ಪುಟ್ನಲ್ಲಿ ತೋರಿಸುತ್ತವೆ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ, ಉತ್ತರ ಬಂದಿತೇ ಎಂಬುದಲ್ಲ, ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂಬುದನ್ನು ನೋಡುವುದು ಮುಖ್ಯ.

ಯಶಸ್ಸನ್ನು ಮಾತ್ರವಲ್ಲ, ವಿಫಲತೆಯ ನೀತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ಟನೆಲ್ ಬಿದ್ದಾಗ ಭೌತಿಕ NIC ಗೆ ಹಿಂತಿರುಗುವ ಗೆಸ್ಟ್ ನಿಖರವಾಗಿ NAT ಮೋಡ್ ಅನುಮತಿಸುವುದನ್ನೇ ಮಾಡುತ್ತಿದೆ.

ಮೋಡ್ ಮತ್ತು ವ್ಯಾಪ್ತಿಯನ್ನು ದಾಖಲಿಸಿ

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

IPv4 ಟನೆಲ್ ಅನ್ನು ಅನುಸರಿಸಿದ್ದರೆ, ಅದನ್ನು ಹೇಳಿ. ಹೇಳಿಕೆಯನ್ನು IPv6, ಬೇರೆ ನೇಮ್ಸ್ಪೇಸ್ ಅಥವಾ ಬೇರೆ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಬೇರೆ VM ಗೆ ವಿಸ್ತರಿಸಬೇಡಿ.