ನಿಮ್ಮ ಹಳೆಯ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು OpenVPN ನಂತರವೂ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಉಳಿಯುತ್ತದೆ
ಎರಡು /1 ಮಾರ್ಗಗಳು ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬದಲಿಸದೆಯೇ ಅದಕ್ಕಿಂತ ಮೇಲಿರುತ್ತವೆ. ಒಂದು ಗಮ್ಯಸ್ಥಾನವು ನಿಜವಾಗಿ ಯಾವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಹಳೆಯ ಗೇಟ್ವೇಯನ್ನು ಅದರ ಜಾಗದಲ್ಲೇ ಬಿಡಿ.
ನೀವು ಟನೆಲ್ ಸಂಪರ್ಕಿಸಿ, ip route ಚಲಾಯಿಸುತ್ತೀರಿ, ಮತ್ತು ಮೂಲ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಇನ್ನೂ ಅಲ್ಲಿಯೇ ಇರುತ್ತದೆ. ಮುಂದಿನ ಯೋಚನೆ ಎಂದರೆ ಕ್ಲೈಂಟ್ ಮಾರ್ಗವನ್ನು ವಹಿಸಿಕೊಳ್ಳಲಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಕೈಯಿಂದ ಅಳಿಸಿ ಸಂಪರ್ಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಆ ನಮೂದು ಉಳಿಯಬೇಕಿತ್ತು. redirect-gateway def1 ಜೊತೆಗೆ OpenVPN ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬದಲಿಸುವ ಬದಲು ಅದಕ್ಕಿಂತ ಮೇಲಿರುವ ಎರಡು ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಹಳೆಯ ಗೇಟ್ವೇ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.
def1 ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ
ಈ ಫ್ಲ್ಯಾಗ್ 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಅನ್ನು ಸೇರಿಸುತ್ತದೆ, ಎರಡೂ ಟನೆಲ್ ಕಡೆಗೆ. 0.0.0.0/1 ಮೊದಲ ಆಕ್ಟೆಟ್ 0 ರಿಂದ 127 ರವರೆಗೆ ಇರುವ ಪ್ರತಿಯೊಂದು ವಿಳಾಸವನ್ನು ಆವರಿಸುತ್ತದೆ, ಮತ್ತು 128.0.0.0/1 128 ರಿಂದ 255 ರವರೆಗೆ ಆವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ IPv4 ಗಮ್ಯಸ್ಥಾನಕ್ಕೂ ಹಳೆಯ ಡೀಫಾಲ್ಟ್ಗಿಂತ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಹೊಂದಾಣಿಕೆ ಇರುತ್ತದೆ. ಯಾವ ಮಾರ್ಗ ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ಮೆಟ್ರಿಕ್ ಅಲ್ಲ, ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದವು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮೂಲ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅದರ ಜಾಗದಲ್ಲೇ ಬಿಡುವುದು ಉದ್ದೇಶಪೂರ್ವಕ. ಕ್ಲೈಂಟ್ ಏನನ್ನು ಬದಲಿಸಿತು ಎಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕಾಗಿಲ್ಲ, ಮತ್ತು VPN ಸರ್ವರ್ಗೆ ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ಸಾಗಿಸುವ ಮಾರ್ಗವನ್ನು ಮತ್ತೆ ಬರೆಯುವುದಿಲ್ಲ. ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವಾಗ ಅದು ಎರಡು ಅರ್ಧ ಮಾರ್ಗಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಕೋಷ್ಟಕವು ಹಿಂದಿದ್ದಂತೆ ಆಗುತ್ತದೆ.
ಏಕೆ /1, /0 ಅಲ್ಲ
ಮಾರ್ಗನಿರ್ದೇಶನವು ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಅಲ್ಲ, ಅತಿ ಉದ್ದದ ಹೊಂದಿಕೆಯ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಡೀಫಾಲ್ಟ್ನ ಮೆಟ್ರಿಕ್ ಏನೇ ಹೇಳಲಿ, /1 /0 ಅನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಎರಡೂ ಅರ್ಧಗಳು ಇರುವುದು ಏಕೆಂದರೆ ಒಂದು /1 ಸ್ಥಳದ ಅರ್ಧವನ್ನು ಮಾತ್ರ ಆವರಿಸುತ್ತದೆ; ಕೇವಲ 0.0.0.0/1 ಇದ್ದಾಗ 128.0.0.0 ಮೇಲಿನ ಎಲ್ಲವೂ ಇನ್ನೂ ಹಳೆಯ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಇದು ಕೆಲವು ಸೈಟ್ಗಳು ಕೆಲಸ ಮಾಡಿ ಇನ್ನು ಕೆಲವು ಮಾಡದಿರುವ ಗೊಂದಲಮಯ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಹಳೆಯ ಡೀಫಾಲ್ಟ್ನ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು ಅಥವಾ ಕಡಿಮೆ ಮಾಡುವುದು ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಬೇರೆ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿನ ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ನ ಡೀಫಾಲ್ಟ್ ಕೂಡ ಸಂಚಾರವನ್ನು ಕದಿಯುವುದಿಲ್ಲ. ಮೊದಲು ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದವು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಸಮಾನ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಮಾತ್ರ ಮೆಟ್ರಿಕ್ಗೆ ಮರಳುತ್ತವೆ.
ನಿಜವಾದ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕವನ್ನು ಓದಿ
ಸಂಪರ್ಕಿತ ಹೋಸ್ಟ್ ಮೂರೂ ನಮೂದುಗಳನ್ನು ಒಟ್ಟಿಗೆ ತೋರಿಸಬಹುದು, ಟನೆಲ್ ಅರ್ಧಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಮೂಲ ಗೇಟ್ವೇ ಇನ್ನೂ ಪಟ್ಟಿಯಲ್ಲಿರುತ್ತದೆ. ವಿಳಾಸಗಳು ನಕಲಿಸಲು ಸಂರಚನೆಯಲ್ಲ, ಉದಾಹರಣೆಗಳು, ಏಕೆಂದರೆ ಇಂಟರ್ಫೇಸ್ ಹೆಸರುಗಳು, ಟನೆಲ್ ಟೋಪಾಲಜಿ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಮಾರ್ಗಗಳು ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ ಅನುಗುಣವಾಗಿ ಬದಲಾಗುತ್ತವೆ.
default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0ಮುಖ್ಯವಾದುದು ಸಂಬಂಧ: ಒಂದು ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್ನ ಮೇಲೆ ಎರಡು ನಿರ್ದಿಷ್ಟ ಅರ್ಧಗಳು. ಹಳೆಯ ಗೇಟ್ವೇ ಸಾಲು ಉಳಿಯುತ್ತದೆ ಏಕೆಂದರೆ ಯಾವುದೂ ಅದನ್ನು ಬದಲಿಸಿಲ್ಲ.
ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಯಾವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ
ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗಗಳು ಇನ್ನೂ ಗೆಲ್ಲಬಹುದು: ಖಾಸಗಿ ಶ್ರೇಣಿ, ಸ್ಥಳೀಯ ಸಬ್ನೆಟ್ ನಂತಹ ಮಾರ್ಗ ಅಥವಾ VPN ಸರ್ವರ್ನ ಸ್ವಂತ ವಿಳಾಸವು /1 ಗಿಂತ ಉದ್ದವಾಗಿದೆ. ಟನೆಲ್ಗೆ ತನ್ನ ಸರ್ವರ್ಗೆ ಹೊರಗಿನ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಆ ಸಂಪರ್ಕವನ್ನು ಮತ್ತೆ ಟನೆಲ್ಗೆ ಕಳುಹಿಸಿದರೆ ಅದು ತಕ್ಷಣ ಒಡೆಯುತ್ತದೆ. Linux ನಲ್ಲಿ ಕೋಷ್ಟಕವನ್ನು ಕಣ್ಣಿನಿಂದ ಓದುವ ಬದಲು ಕರ್ನಲ್ ಅನ್ನು ಕೇಳಿ: ನಿಮಗೆ ಆಸಕ್ತಿಯ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ip route get ಆಯ್ಕೆಯಾದ ಮಾರ್ಗ, ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮೂಲವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ನೀತಿ ಆಧಾರಿತ ಮಾರ್ಗನಿರ್ದೇಶನ ಸಂರಚಿಸಲಾಗಿದ್ದರೆ ನಿಯಮಗಳನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮುಖ್ಯ ಕೋಷ್ಟಕವನ್ನು ನೋಡುವ ಮೊದಲು ನಿಯಮವು ಬೇರೆ ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
IPv4 ನ ಒಂದು ಭಾಗ ಮಾತ್ರ ತಪ್ಪಾಗಿ ವರ್ತಿಸಿದರೆ, ಎರಡೂ ಅರ್ಧಗಳು ಸ್ಥಾಪಿತವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ವಿಫಲವಾಗುವ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಹೊಂದುವ ಅಪವಾದವನ್ನು ಹುಡುಕಿ. ಹಳೆಯ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಅಳಿಸುವುದು ಪರಿಹಾರವಲ್ಲ, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್ಗೆ ಟನೆಲ್ ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿ ಬಿಚ್ಚಲು ಬೇಕಾದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
def1 ಏನನ್ನು ಆವರಿಸುವುದಿಲ್ಲ
ಎರಡು IPv4 ನಮೂದುಗಳು IPv6 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ: IPv6 ಸಂಪರ್ಕವಿರುವ ಹೋಸ್ಟ್ ಆ ಕುಟುಂಬವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬೇರೆಡೆಗೆ ತಿರುಗಿಸುವವರೆಗೆ ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ದ್ವಿ-ಸ್ಟಾಕ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಕೆಲವು ಸಂಚಾರವು ಟನೆಲ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳದಂತೆ ಕಾಣುತ್ತದೆ. ಇತರ ಕ್ಲೈಂಟ್ಗಳು ಮತ್ತು ನೆಟ್ವರ್ಕ್ ನಿರ್ವಾಹಕರು ಪೂರ್ಣ-ಟನೆಲ್ ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಜಾರಿಗೊಳಿಸುತ್ತಾರೆ, ಮತ್ತು ಅವರ ಕೋಷ್ಟಕಗಳು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಇಲ್ಲಿ ವಿವರಿಸಿದ def1 ವರ್ತನೆ OpenVPN ನ ದಾಖಲಿತ ಫ್ಲ್ಯಾಗ್ಗೆ ಸೇರಿದ್ದು, ಯಂತ್ರದ ಪ್ರತಿ VPN ಗೆ ಅಲ್ಲ.
ಕಿಲ್ ಸ್ವಿಚ್ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಟನೆಲ್ ಬಿದ್ದಾಗ ಯಂತ್ರ ಏನು ಮಾಡುತ್ತದೆ. ಮಾರ್ಗ ಆದ್ಯತೆಯು ಟನೆಲ್ ಇರುವಾಗ ಸಂಚಾರ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ನಂತರ ಫೈರ್ವಾಲ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಅದು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಕೆಲಸದ ಕ್ರಮ: ಕೋಷ್ಟಕವನ್ನು ಓದಿ, ಎರಡೂ ಅರ್ಧಗಳು ಇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ವಿಫಲವಾಗುವ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ip route get ಚಲಾಯಿಸಿ, ನೀತಿ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ IPv6 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಿ. ಹಳೆಯ ಡೀಫಾಲ್ಟ್ ಇರುವಲ್ಲೇ ಬಿಡಿ.