ಸಂಪೂರ್ಣ ಟನೆಲ್ ಮಾರ್ಗವು ಅದನ್ನು ಸಾಗಿಸುವ ಸರ್ವರ್ ಅನ್ನು ಏಕೆ ಕಡಿತಗೊಳಿಸುತ್ತದೆ

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

ತನ್ನದೇ ಸಾಗಣೆಯನ್ನು ತಿನ್ನುವ ಮಾರ್ಗ

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

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

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

ಡೀಫಾಲ್ಟ್ಗಿಂತ ಮೊದಲು ಅಪವಾದವನ್ನು ಸ್ಥಾಪಿಸಿ

ಸರ್ವರ್ಗಾಗಿ ಒಂದೇ ವಿಳಾಸದ ಮಾರ್ಗವನ್ನು ರಚಿಸಿ, ಭೌತಿಕ ಗೇಟ್ವೇಯನ್ನು ಮುಂದಿನ ಹಾಪ್ ಆಗಿ ಇಟ್ಟುಕೊಂಡು, ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಚಲಿಸುವ ಮೊದಲು. ಕ್ರಮ ಮುಖ್ಯ: ನಂತರ ಸ್ಥಾಪಿಸುವುದು ಎಂದರೆ ಟೈಪ್ ಮಾಡುವಾಗ ಮುರಿದ ಟನೆಲ್ನೊಂದಿಗೆ ಬದುಕುವುದು.

ಹೆಚ್ಚಿನ ಕ್ಲೈಂಟ್ಗಳು ಇದನ್ನು ಕೇಳದೆಯೇ ಮಾಡುತ್ತವೆ. OpenVPN ದೂರದ ವಿಳಾಸವನ್ನು ಹುಡುಕಿ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇವನ್ನು ಮರುಬರೆಯುವ ಮೊದಲು ಅದನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದರ route-delay ಆಯ್ಕೆ ಆ ಕ್ರಮ ಸ್ಪರ್ಧಿಸುವ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳಿಗಾಗಿ ಇದೆ. wg-quick ಸಂಪೂರ್ಣ ಬೇರೆ ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಗುರುತಿಸಿ ನೀತಿ ನಿಯಮವನ್ನು ಸಂಪರ್ಕಿಸುವ ಮೂಲಕ ಅಪವಾದ ಸೇರಿಸುವ ಬದಲು. ಬೇರೆ ಬೇರೆ ಕಾರ್ಯವಿಧಾನಗಳು, ಒಂದೇ ಅವಶ್ಯಕತೆ: ಹೊರ ಪ್ಯಾಕೆಟ್ ತಾನು ಸೃಷ್ಟಿಸುವ ಟನೆಲ್ನಿಂದ ತಪ್ಪಿಸಿಕೊಳ್ಳಬೇಕು.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

ಹುಡುಕಾಟದ ಔಟ್ಪುಟ್ ಸ್ವೀಕಾರ ಪರೀಕ್ಷೆ. ಅದು ಭೌತಿಕ ಸಾಧನ ಮತ್ತು ಭೌತಿಕ ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು. ಆ ಉತ್ತರದಲ್ಲಿ ಟನೆಲ್ ಸಾಧನ ಇದ್ದರೆ ಅಪವಾದ ಕಾಣೆಯಾಗಿದೆ, ಅಥವಾ ಅದನ್ನು ಮೀರಿಸುವ ಯಾವುದೋ ಒಂದರ ನಂತರ ಇಡಲಾಗಿದೆ.

ಸರ್ವರ್ನಲ್ಲಿ ಕನ್ನಡಿ ಪ್ರತಿಬಿಂಬ

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

ಟನೆಲ್ ನಿರಂತರವಾಗಿ ಕದಿಯುವ ಅಪವಾದಗಳು

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

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

ಯಾರೂ ಬರೆಯದ ಅಪವಾದವು ಮುಂದಿನ ಮರುನಿರ್ಮಾಣವು ಮೌನವಾಗಿ ಬಿಟ್ಟುಬಿಡುವ ಅಪವಾದ.

ಮರುಸಂಪರ್ಕದ ನಂತರ ಸಾಬೀತು ಮಾಡಿ, ಮೊದಲು ಅಲ್ಲ

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

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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