ಒಂದೇ Linux ಯಂತ್ರದಲ್ಲಿ ಎರಡು VPN: ಫಲಿತಾಂಶಗಳನ್ನು ಬೆರೆಸದೆ ಪ್ರತಿಯೊಂದನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ
ಎರಡು ಹಸಿರು ಐಕಾನ್ಗಳು ಹೋಲಿಕೆ ಅಲ್ಲ. ಪ್ರತಿ ಟನೆಲ್ ಅನ್ನು ಅದರದೇ ನಾಮಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ, ನಿರೀಕ್ಷೆಯನ್ನು ಮೊದಲು ಬರೆಯಿರಿ, ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ನಂಬುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಸಾಬೀತು ಮಾಡಿ.
ಎರಡು ಹಸಿರು ಸಂಪರ್ಕ ಐಕಾನ್ಗಳು ಹೋಲಿಕೆಯಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಕೇವಲ ಕಾಕತಾಳೀಯ. ಪರೀಕ್ಷಾ ವಿನಂತಿಯು ಎರಡೂ ಟನೆಲ್ಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಬಳಸಬಹುದಾಗಿದ್ದರೆ, ಫಲಿತಾಂಶವು ಉತ್ತಮ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವುದನ್ನೂ ವಿವರಿಸುವುದಿಲ್ಲ. ಪ್ರತಿ ವೀಕ್ಷಣೆಗೆ ಜಾಲಬಂಧ ಸಂದರ್ಭ, ಉದ್ದೇಶಿತ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪರೀಕ್ಷೆ ಆರಂಭವಾಗುವ ಮೊದಲು ಬರೆದ ನಿರೀಕ್ಷೆಯನ್ನು ನೀಡಿ. ನೀವೇ ನಿರ್ವಹಿಸುವ Linux ಯಂತ್ರದಲ್ಲಿ, ಹೆಸರಿಸಿದ ಜಾಲಬಂಧ ನಾಮಸ್ಥಳಗಳೇ ಆ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಪಡೆಯುವ ಅಗ್ಗದ ದಾರಿ.
ಎರಡು ಹಸಿರು ದೀಪಗಳು ಹೋಲಿಕೆ ಅಲ್ಲ
ನಾಮಸ್ಥಳವು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳು, ಇಂಟರ್ಫೇಸ್ಗಳು ಮತ್ತು ಜಾಲಬಂಧ ಸ್ಟ್ಯಾಕ್ನ ಸ್ಥಿತಿಯನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದರೊಳಗೆ ಆರಂಭವಾದ ವಿನಂತಿಯು ಮತ್ತೊಂದರ ಟನೆಲ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಎರವಲು ಪಡೆಯಲಾಗದು. ಅದು ಬೇರ್ಪಡಿಸದಿರುವುದು ಪ್ರೊಸೆಸರ್, ಭೌತಿಕ ಮೇಲ್ಮುಖ ಕೊಂಡಿ ಅಥವಾ ಆತಿಥೇಯದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಹೆಸರು ಪರಿಹಾರಕ ಸೇವೆ. ಈ ಕೊನೆಯ ಸಂದಿನಲ್ಲಿ ಈ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಯಾರಿಗೂ ಗಮನಕ್ಕೆ ಬಾರದೆ ವಿಫಲವಾಗುತ್ತವೆ. ನಾಮಸ್ಥಳವನ್ನು ಬಿಟ್ಟು ಆತಿಥೇಯದ ಪರಿಹಾರಕವನ್ನು ಕೇಳುವ ಹುಡುಕಾಟವು ಪರೀಕ್ಷೆಯಲ್ಲಿರುವ ಟನೆಲ್ಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ಉತ್ತರವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
ಈ ವಿಧಾನವು ಈಗಾಗಲೇ ಸಿದ್ಧಪಡಿಸಲಾದ ಮತ್ತು ಅನುಮೋದಿಸಲಾದ ಎರಡು ಪರೀಕ್ಷಾ ನಾಮಸ್ಥಳಗಳು, ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬಾಹ್ಯ ಸಂಪರ್ಕ ಮತ್ತು ಬೆಂಬಲಿತ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಊಹಿಸುತ್ತದೆ. ಅದು ಏನನ್ನೂ ರಚಿಸುವುದಿಲ್ಲ, ಏನನ್ನೂ ನೋಂದಿಸುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಸಂರಚನೆಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ಗೆ ಪೂರ್ಣ ಡೆಸ್ಕ್ಟಾಪ್ ಅಧಿವೇಶನ ಬೇಕಾದಾಗ ಅಥವಾ ಅದರ ಹೊರಗೆ ಚಾಲನೆ ಮಾಡಲು ನಿರಾಕರಿಸಿದಾಗ ಪ್ರತ್ಯೇಕ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳೇ ಪ್ರಾಮಾಣಿಕ ಆಯ್ಕೆ.
ಮೊದಲ ಓಟಕ್ಕಿಂತ ಮೊದಲು ನಿರೀಕ್ಷೆಯನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ
ಪ್ರತಿ ಸಂದರ್ಭಕ್ಕೂ ಯಶಸ್ಸು ಹೇಗೆ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ: ಪರಿಹಾರಕ, ಸೇವೆಯ ಹೆಸರು, ನಿರೀಕ್ಷಿತ ವಿಳಾಸ ಮತ್ತು ಟನೆಲ್ ಬಿದ್ದಾಗ ಅಗತ್ಯವಾದ ವರ್ತನೆ. ಆ ಯೋಜಿತ ಮೌಲ್ಯಗಳನ್ನು ಅವುಗಳದೇ ಅಂಕಣದಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಯೋಜನೆ ಮತ್ತು ವೀಕ್ಷಣೆಯನ್ನು ಬೆರೆಸುವ ದಾಖಲೆ ಸಮಯಮುದ್ರೆಯುಳ್ಳ ಕಲ್ಪನೆ. ಕೆಳಗಿನ ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯೇ ದಾಖಲೆಗೆ ಬೇಕಾದ ರೂಪ, ಮತ್ತು ಮೊದಲ ಸಂಪರ್ಕಕ್ಕಿಂತ ಮೊದಲು ಪ್ರತಿ ಸಾಲು ತುಂಬಬಹುದಾದದ್ದಾಗಿರಬೇಕು.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
ಪರಿಹಾರಕದ ತಂತಿ ಜೋಡಣೆಗೆ ಆ ದಾಖಲೆಯಲ್ಲಿ ತನ್ನದೇ ಸಾಲು ಬೇಕು, ಏಕೆಂದರೆ ಸುಳ್ಳು ಹೇಳುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚಿರುವ ಕ್ಷೇತ್ರ ಅದೇ. ನಾಮಸ್ಥಳಕ್ಕೆ ಬದ್ಧವಾದ ಫೈಲ್ಗಳು, ಉದಾಹರಣೆಗೆ /etc/netns/vpn-a/resolv.conf ಆಜ್ಞೆ ನಾಮಸ್ಥಳದ ಒಳಗೆ ಚಾಲನೆಯಾದಾಗ ಅವುಗಳ ಸಾಮಾನ್ಯ ಮಾರ್ಗಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಎಂಬುದನ್ನು iproute2 ನ ನಾಮಸ್ಥಳ ಉಲ್ಲೇಖ ವಿವರಿಸುತ್ತದೆ, ಆದರೆ ಹೆಸರು ಸೇವಾ ಬದಲಾವಣೆಯ ಸಂರಚನೆ ಮತ್ತು ಅದು ಆರಂಭಿಸುವ ಯಾವುದೇ ಸ್ಥಳೀಯ ಪರಿಹಾರಕವು ಹುಡುಕಾಟವನ್ನು ಆತಿಥೇಯದತ್ತ ಮರಳಿ ಎಳೆಯಬಹುದು.
ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಟನೆಲ್, ಇನ್ನೊಂದು ಸಂಪರ್ಕ ಕಡಿತ
B ಕೆಳಗಿರುವಾಗ A ಅನ್ನು ಅದರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾಲೀಕರ ಮೂಲಕ ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಆಡಳಿತ ಸಂದರ್ಭದಿಂದ ನೀತಿ, ರೂಟ್ಗಳು ಮತ್ತು ಆಯ್ಕೆಯಾದ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ. ಕೆಳಗಿನ ಆಜ್ಞೆಗಳಲ್ಲಿ ಮೂರು ಸ್ಥಿತಿಯನ್ನು ಓದುತ್ತವೆ; ಕೊನೆಯದು ಮಾತ್ರ ಹೆಸರು ಸೇವೆಯನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅನ್ವಯ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ.
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalರೂಟ್ ಹುಡುಕಾಟವು ಗಮ್ಯಸ್ಥಾನದ ಬಗ್ಗೆ ಕಾಲ್ಪನಿಕ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸೇವೆ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸಲಾಗದು. ಈ ಎರಡು ರೀತಿಯ ಸಾಕ್ಷ್ಯವನ್ನು ಪ್ರತ್ಯೇಕ ಅಂಕಣಗಳಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕದ ಪಕ್ಕದಲ್ಲಿ ಆರೋಗ್ಯಕರ ರೂಟ್ ನೈಜ ಮತ್ತು ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶ. ನಂತರ ನಿಜವಾದ ಅನ್ವಯದೊಂದಿಗೆ ಒಂದು ಹಾನಿರಹಿತ ಅಧಿಕೃತ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ, ಅದು A ಯ ಸಂದರ್ಭದಲ್ಲಿ ಅದರ ಸಾಮಾನ್ಯ ವಿಶೇಷಾಧಿಕಾರವಿಲ್ಲದ ಬಳಕೆದಾರನಾಗಿ ಆರಂಭವಾಗುತ್ತದೆ, ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಮತ್ತು ಅನ್ವಯ ದೃಢೀಕರಣ ಅಕ್ಷತವಾಗಿ, ಮತ್ತು ಸೇವೆ ಕಂಡ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಿ. A ಅನ್ನು ಅದರ ಮಾಲೀಕರ ಮೂಲಕ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿ ಮತ್ತು B ಗೆ ಇಡೀ ಮೂಲರೇಖೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ನೀವು ಮಾಡುವ ಯಾವುದೇ ಸಂರಚನಾ ಬದಲಾವಣೆಯನ್ನು ಗಮನಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಎರಡೂ ಮೂಲರೇಖೆಗಳು ಹೋಲಿಸಲಾಗದಂತಾಗುತ್ತವೆ.
ಎರಡೂ ಮೇಲೆ, ನಂತರ ಒಂದೊಂದಾಗಿ ಕೆಳಗೆ
ಸ್ಥಿರ ಸ್ಥಿತಿ ಸುಲಭ ಭಾಗ. ಎರಡೂ ಟನೆಲ್ಗಳು ಸಂಪರ್ಕಗೊಂಡಿರುವಾಗ ಪ್ರತಿ ಸಂದರ್ಭದ ಹುಡುಕಾಟ ಮತ್ತು ಅನ್ವಯ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ನಂತರ ಒಂದು ಟನೆಲ್ ಮುರಿದು ಇನ್ನೊಂದನ್ನು ಪರಿಶೀಲಿಸಿ. ಸಂಪರ್ಕದ ಕ್ರಮವೇ ಪ್ರಶ್ನೆಯಾದಾಗ ಹಿಮ್ಮುಖ ಕ್ರಮದಲ್ಲಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ.
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20ಸೆರೆಹಿಡಿಯುವಿಕೆ ಅನ್ವಯ ಫಲಿತಾಂಶವು ನಿರ್ಧರಿಸಲಾಗದ ಚರ್ಚೆಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: ವಿನಂತಿ ನೀವು ನಿರೀಕ್ಷಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಟಿತೇ ಅಥವಾ ಸಂಪೂರ್ಣ ಬೇರೆ ಯಾವುದೋ ಮೂಲಕ ಹೊರಟಿತೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಪ್ರತಿ ಪರಿವರ್ತನೆಗೆ ಮಾಲೀಕರ ಕ್ರಿಯೆ, ಸಮಯಮುದ್ರೆ, ರೂಟ್ ಫಲಿತಾಂಶ, ಹೆಸರು ಫಲಿತಾಂಶ ಮತ್ತು ಅನ್ವಯ ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಿ. ನಂತರ ಬಾಧಿತ ನಾಮಸ್ಥಳದ ಒಳಗೆ ಸುರಕ್ಷಿತ ಮುಚ್ಚುವಿಕೆಯ ಅಗತ್ಯವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತ್ಯೇಕತೆ ಕಿಲ್ ಸ್ವಿಚ್ ಅಲ್ಲ. ನಾಮಸ್ಥಳವು ಎರಡು ಟನೆಲ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ; ಅದರ ಪ್ರೊಫೈಲ್ ಸಂಚಾರ ನಿಲ್ಲಬೇಕು ಎಂದು ಹೇಳಿದಾಗ ಅದು ಯಾವುದನ್ನೂ ಸಂಚಾರ ಸಾಗಿಸದಂತೆ ತಡೆಯುವುದಿಲ್ಲ.
ಈ ದಾಖಲೆ ಏನನ್ನು ಪ್ರತಿಪಾದಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ
ಒಂದು ಉತ್ತೀರ್ಣತೆ ಈ ವ್ಯವಸ್ಥೆಗೆ, ಈ ಆತಿಥೇಯದಲ್ಲಿ, ಆ ಸಮಯದಲ್ಲಿ ಆ ವೀಕ್ಷಣೆಗಳನ್ನು ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಒಂದೇ ಡೆಸ್ಕ್ಟಾಪ್ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಇಬ್ಬರು ಕ್ಲೈಂಟ್ಗಳ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡೂ ಟನೆಲ್ಗಳು ಹೊರೆ ಹೊತ್ತಾಗಿನ ಥ್ರೂಪುಟ್ ಬಗ್ಗೆಯೂ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಅವು ಪ್ರತ್ಯೇಕ ಪರೀಕ್ಷೆಗಳಿರುವ ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ಹೋಲಿಕೆ ಪ್ರತಿ ಸಾಲಿಗೆ ಜೋಡಿಸಿದ ಸಂದರ್ಭದಷ್ಟೇ ಒಳ್ಳೆಯದು.
ವಿಫಲತೆಗಳನ್ನು ದಾಖಲೆಯಲ್ಲಿ ಯಶಸ್ಸುಗಳ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಆ ಸಮಯದಲ್ಲಿ ಯಾವ ಟನೆಲ್ ಮೇಲಿತ್ತು ಎಂದು ಗುರುತಿಸಿ. ಮಾಪನದ ಸಮಯದ ಸ್ಥಿತಿಯನ್ನು ಮರೆಮಾಡುವ ಸ್ವಚ್ಛ ಪುಟ ಅದನ್ನು ತೋರಿಸುವ ವಿಕಾರವಾದ ಪುಟಕ್ಕಿಂತ ಕೆಟ್ಟದು. ದಾಖಲೆಯನ್ನು ನಂತರ ಮತ್ತೆ ಬಳಸಬಹುದಾದಂತೆ ಮಾಡುವುದು ಸಂದರ್ಭ, ಅಂಕಗಳಲ್ಲ.
ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಎರಡು ಟನೆಲ್ಗಳನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೋಲಿಸಬಹುದು, ಆದರೆ ನೀವು ನಿಜವಾಗಿ ನಿಯಂತ್ರಿಸಿದಷ್ಟೇ ಸಂದರ್ಭಗಳ ಒಳಗೆ ಮಾತ್ರ. ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿನದು ಪಕ್ಕದಲ್ಲಿ ಹಸಿರು ಐಕಾನ್ ಇರುವ ಆಸೆ.