ಪುನರಾವರ್ತಿತ ರೂಟಿಂಗ್: ಟನೆಲ್ ತನ್ನದೇ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಹಿಡಿದಾಗ

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

ಮೊದಲು ಹೊರಗಿನ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಆಟದಲ್ಲಿ ಎರಡು ಪ್ಯಾಕೆಟ್ಗಳಿವೆ, ಒಂದಲ್ಲ. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸೇರಿದ್ದು ಮತ್ತು ಗೂಢಲಿಪೀಕರಣಗೊಳ್ಳಬೇಕು, ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ ಸರ್ವರ್ಗೆ ವಿಳಾಸಗೊಂಡಿದ್ದು ಟನೆಲ್ ಮೇಲೆ ಅವಲಂಬಿತವಲ್ಲದ ಮಾರ್ಗದಲ್ಲಿ ಅಲ್ಲಿಗೆ ತಲುಪಬೇಕು.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

ಸೆಷನ್ ಕ್ಷಣಮಾತ್ರ ಏಕೆ ಉಳಿಯುತ್ತದೆ

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

ಈ ಕ್ರಮವೇ ಟನೆಲ್ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ರೂಟರ್ನಲ್ಲಿ ವಿಫಲವಾಗುವುದು ಏಕೆ, ಮತ್ತು ವೈಫಲ್ಯ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಅಲ್ಲದೆ ಸಂಚಾರ ಆರಂಭವಾದಾಗ ಏಕೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದು ಲೂಪ್ ಅನ್ನೂ ವಿವರಿಸುತ್ತದೆ: ಪ್ರತಿ ಮರುಪ್ರಾರಂಭವೂ ಸೆಷನ್ ಅನ್ನು ಮಾರ್ಗವು ಅಸಾಧ್ಯಗೊಳಿಸುವ ಮೊದಲೇ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ.

ಎಂಡ್ಪಾಯಿಂಟ್ ವಿನಾಯಿತಿಯ ಮಾಲೀಕರು ಯಾರೆಂದು ಕಂಡುಹಿಡಿಯಿರಿ

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

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

ನೆಟ್ವರ್ಕ್ ಬದಲಾದ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

Wi-Fi ಗೇಟ್ವೇ ಮೂಲಕ ಹೋಸ್ಟ್ ಮಾರ್ಗ ಯಂತ್ರವು ಬೇರೆ ನೆಟ್ವರ್ಕ್ಗೆ ಹೋಗುವವರೆಗೆ ಸರಿಯಾಗಿರುತ್ತದೆ. ಆಗ ಅದೇ ಲಕ್ಷಣ ಯಾವುದೇ ಸಂರಚನಾ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಮರಳಿ ಬರುತ್ತದೆ.

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

ಹೊಸ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳಿಸಿ ಓದುವಿಕೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ವಿನಾಯಿತಿ ಮತ್ತೆ ಇಲ್ಲದಿದ್ದರೆ, ಸರಿಪಡಿಸುವಿಕೆ ಅದನ್ನು ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್ನಲ್ಲಿದೆ, ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಒಂದು-ಬಾರಿಯ ಆದೇಶದಲ್ಲಿ ಅಲ್ಲ.