OpenVPN ಮಾರ್ಗ ಯೋಜನೆಗೆ bypass-dhcp ನಿಜವಾಗಿ ಏನನ್ನು ಸೇರಿಸುತ್ತದೆ

redirect-gateway def1 bypass-dhcp ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್ IPv4 ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಬದಲಾವಣೆಯನ್ನು ಒಂದು ಸಣ್ಣ ವಿನಾಯಿತಿಯೊಂದಿಗೆ ಸೇರಿಸುತ್ತದೆ. ಜನರು ಕೊನೆಯ ಪದವನ್ನು ಓದಿ ಮೊಬೈಲ್ ಸಂಪರ್ಕಗಳಿಗೆ ಸಾಮಾನ್ಯ ಪರಿಹಾರವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ, ನಂತರ ಈ ಫ್ಲಾಗ್ ಎಂದೂ ಬೆಂಬಲಿಸದ DHCP ಸಿದ್ಧಾಂತದಲ್ಲಿ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುತ್ತಾರೆ. ಪ್ರತಿ ಭಾಗ ಒಂದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ವಿನಾಯಿತಿಯು ಅದರ ಖ್ಯಾತಿಗಿಂತ ಬಹಳ ಚಿಕ್ಕದಾಗಿದೆ.

ಮೊಬೈಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಮಾತ್ರ ಸಂಭವಿಸುವ ವೈಫಲ್ಯವನ್ನು ವಿಳಾಸ ಹಂಚಿಕೆಗೆ ಆರೋಪಿಸುವ ಮೊದಲು ಫ್ಲಾಗ್‌ಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ. ಆ ಸ್ಟ್ರಿಂಗ್‌ನ ಎರಡು ಅರ್ಧಗಳಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧವಿಲ್ಲ.

ಎರಡು ಫ್ಲಾಗ್‌ಗಳು, ಎರಡು ಸಂಬಂಧವಿಲ್ಲದ ಕೆಲಸಗಳು

def1 ಜೊತೆಗೆ, ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಇರುವ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುವ ಬದಲು ಎರಡು IPv4 ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. 0.0.0.0/1 ವಿಳಾಸ ಸ್ಥಳದ ಕೆಳಗಿನ ಅರ್ಧವನ್ನು ಆವರಿಸುತ್ತದೆ ಮತ್ತು 128.0.0.0/1 ಮೇಲಿನ ಅರ್ಧವನ್ನು, ಆದ್ದರಿಂದ ಒಟ್ಟಿಗೆ ಅವು ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪುತ್ತವೆ, ಪ್ರತಿಯೊಂದೂ 0.0.0.0/0 ಗಿಂತ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಆದ್ದರಿಂದ ಮೂಲ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ಆ ಹುಡುಕಾಟಗಳನ್ನು ಗೆಲ್ಲದೆ ಕೋಷ್ಟಕದಲ್ಲಿ ಉಳಿಯುತ್ತದೆ, ಇದು ಹಳೆಯ ಗೇಟ್‌ವೇಯನ್ನು ಕ್ಲೈಂಟ್ ಸ್ಪಷ್ಟವಾಗಿ ಮಾರ್ಗೀಕರಿಸುವ ಎಲ್ಲದಕ್ಕೂ ತಲುಪಬಹುದಾಗಿ ಇರಿಸುತ್ತದೆ. ಇದು ಕೋಷ್ಟಕದಲ್ಲಿ ಎರಡು ಅತಿವ್ಯಾಪಿಸುವ ಡೀಫಾಲ್ಟ್‌ಗಳನ್ನು ಸಹ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮಾರ್ಗ ಡಂಪ್ ಪ್ರೊಫೈಲ್ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ವಿಚಿತ್ರವಾಗಿ ಕಾಣಬಹುದು.

bypass-dhcp ಪ್ರತ್ಯೇಕವಾಗಿದೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸ್ವಲ್ಪವೂ ಮುಟ್ಟುವುದಿಲ್ಲ. OpenVPN 2.6 ಕೈಪಿಡಿ ಇದನ್ನು ಸ್ಥಳೀಯ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಇಲ್ಲದ DHCP ಸರ್ವರ್‌ಗೆ ನೇರ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದು ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಲೀಸ್ ಸಂಚಾರವು ಸುರಂಗದ ಹೊರಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಈ ವರ್ತನೆಯು Windows ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ಜಾರಿಯಾಗಿದೆ ಹಾಗೂ ಬೇರೆಡೆ ಲಭ್ಯವಿಲ್ಲದಿರಬಹುದು ಎಂದು ಗಮನಿಸುತ್ತದೆ.

ಅದರ ಅಸ್ತಿತ್ವದ ಕಾರಣ ಯಾಂತ್ರಿಕ. ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳು ಹೊರಹೋಗುವ ಸಂಚಾರವನ್ನು ಹಿಡಿದ ನಂತರ, ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್‌ನ ಸರ್ವರ್‌ಗೆ ಉದ್ದೇಶಿಸಿದ DHCP ನವೀಕರಣವು ಸುರಂಗದೊಳಗೆ ಮಾರ್ಗೀಕರಣಗೊಳ್ಳುತ್ತಿತ್ತು, ಒಂದು ವೇಳೆ ಯಾವುದೋ ಆ ವಿಳಾಸವನ್ನು ನಿಜವಾದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಪಿನ್ ಮಾಡದಿದ್ದರೆ. ಫ್ಲಾಗ್ ಅದನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ.

ವಿನಾಯಿತಿ ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಸೀಮಿತವಾಗಿದೆ

ಯಶಸ್ವಿ ಸಂಪರ್ಕದ ನಂತರದ ಉದಾಹರಣೆ ಕೋಷ್ಟಕವು ಆಕಾರವನ್ನು ತೋರಿಸುತ್ತದೆ: ಸುರಂಗದ ಮೂಲಕ ಎರಡು ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳು, ಮತ್ತು ಭೌತಿಕ ಗೇಟ್‌ವೇ ಮೂಲಕ DHCP ಸರ್ವರ್‌ಗೆ ಒಂದು ಹೋಸ್ಟ್ ಮಾರ್ಗ. ಅದನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ವಿಳಾಸಗಳಾಗಿ ಅಲ್ಲ, ಆಕಾರವಾಗಿ ಓದಿ.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

ಆ ಮೂರನೇ ಸಾಲು ಒಂದು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಇದು ರಿಸಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ, ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಾಮಾನ್ಯ ಅನುಮತಿ ಅಲ್ಲ ಮತ್ತು ಸರ್ವರ್‌ನಲ್ಲಿ ಹೊರಹೋಗುವ ನಿಯಮವಲ್ಲ. ಸೆಲ್ಯುಲಾರ್ ವಾಹಕದಲ್ಲಿರುವ ಫೋನ್‌ಗೆ ಕ್ಲೈಂಟ್ ಈ ರೀತಿ ಗುರುತಿಸಬಹುದಾದ DHCP ಸರ್ವರ್ ಇಲ್ಲದಿರಬಹುದು, ಆದ್ದರಿಂದ ಫ್ಲಾಗ್ ಅಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.

ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸ್ಥಾಪಿಸಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

VPN ಅಂತ್ಯಬಿಂದುವಿಗೆ ಮಾರ್ಗವನ್ನು ಅದೇ ಸಮಯದಲ್ಲಿ ಬಳಸಬಹುದಾಗಿ ಇರಿಸಿ. ಆ ಅಂತ್ಯಬಿಂದು ವಿನಾಯಿತಿ DHCP ವಿನಾಯಿತಿಗಿಂತ ಬೇರೆ ಅಗತ್ಯವಾಗಿದೆ, ಮತ್ತು ಅದು ಇಲ್ಲದೆ ಸುರಂಗವು ತನ್ನನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಸಾಗಣೆಯನ್ನೇ ಹಿಡಿಯಬಹುದು.

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

ಉಳಿದ ಮಾರ್ಗ ಈ ಫ್ಲಾಗ್‌ನಲ್ಲಿಲ್ಲ

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

ಹೆಸರು ಪರಿಹರಣ ಮತ್ತು IPv6 ಎರಡಕ್ಕೂ ತಮ್ಮದೇ ನೀತಿ ಬೇಕು. IPv4 ಬದಲಾವಣೆ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಸುರಂಗ ಬದಿಯ ಸರ್ವರ್‌ಗೆ ತಿರುಗಿಸುವುದಿಲ್ಲ ಮತ್ತು IPv6 ಕವರೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕೇವಲ v4 ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವ ಕ್ಲೈಂಟ್ v6 ಮಾರ್ಗವನ್ನು ಸ್ಪರ್ಶಿಸದೆ ಬಿಡುತ್ತದೆ.

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