ಒಂದು IPv4 ಗಮ್ಯಸ್ಥಾನವನ್ನು OpenVPN ಸುರಂಗದ ಹೊರಗೆ ಕಳುಹಿಸುವುದು

ಹೆಚ್ಚಿನ ಪೂರ್ಣ ಸುರಂಗ ಸಂರಚನೆಗಳು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು VPN ಮೂಲಕ ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು redirect-gateway ಅದನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ನಿರ್ದೇಶನವಾಗಿದೆ. ಒಂದೇ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಇನ್ನೂ ಹೊರಗಿಡಬಹುದು. ಆ ವಿಳಾಸಕ್ಕೆ net_gateway ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ನೊಂದಿಗೆ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಸೇರಿಸುವುದು ಕ್ಲೈಂಟ್ಗೆ ಅದನ್ನು ಯಂತ್ರದ ಮೂಲ ಗೇಟ್ವೇ ಮೂಲಕ ತಲುಪಲು ಹೇಳುತ್ತದೆ, ಉಳಿದೆಲ್ಲವೂ ಸುರಂಗವನ್ನು ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ.

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

net_gateway ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಹೆಸರಿಸುತ್ತದೆ

ಆ ವಿನಾಯಿತಿಗೆ ಪ್ರೊಫೈಲ್ ನಮೂದು ಒಂದೇ ಸಾಲು: route 198.51.100.77 255.255.255.255 net_gateway. ಮೊದಲ ವಿಳಾಸ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ದಾಖಲೆ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್, ಮಾಸ್ಕ್ ಅದನ್ನು ಒಂದೇ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯ ಟೋಕನ್ ಗೇಟ್ವೇ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. OpenVPN ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಗೇಟ್ವೇ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ಗಳನ್ನು ಬಿಡಿಸುತ್ತದೆ. vpn_gateway ಎಂದರೆ ಸುರಂಗದ ಸ್ವಂತ ಗೇಟ್ವೇ, ಅಂದರೆ VPN ಕೊಂಡಿಯ ದೂರದ ಬದಿ. net_gateway ಎಂದರೆ VPN ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಹೋಸ್ಟ್ ಹೊಂದಿದ್ದ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಭೌತಿಕ ಜಾಲದಲ್ಲಿನ ಸ್ಥಳೀಯ ರೌಟರ್.

ಮೂರನೇ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್, remote_host, VPN ಸರ್ವರ್ನ ವಿಳಾಸವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗವು ಭೌತಿಕ ಮಾರ್ಗದಲ್ಲಿ ಸರ್ವರ್ ತಲುಪಲು ಅದು ಇದೆ. ಈ ಮೂರನ್ನು ಗೊಂದಲಿಸುವುದು ವಿನಾಯಿತಿ ತಪ್ಪು ಸ್ಥಳಕ್ಕೆ ಹೋಗುವ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಾಪನೆಯಾಗದಿರುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಕಾರಣ.

ಮೌಲ್ಯವನ್ನು ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಓದಲಾಗುತ್ತದೆ, ಫೈಲ್ಗೆ ಬರೆಯುವುದಿಲ್ಲ. ಯಂತ್ರವು ಬೇರೆ ಜಾಲಕ್ಕೆ ಹೋದರೆ, VPN ಮೊದಲಿನ ಗೇಟ್ವೇ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ಮಾರ್ಗ ಹೊಸದನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಅದು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ಬಯಸುವುದೇ, ಆದರೆ ವಿನಾಯಿತಿಯ ವರ್ತನೆ ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭವಾದ ಜಾಲವನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದೂ ಅರ್ಥ.

ಹೋಸ್ಟ್ ಮಾರ್ಗವು ಸುರಂಗದ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಏಕೆ ಸೋಲಿಸುತ್ತದೆ

ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಅತ್ಯಂತ ನಿರ್ದಿಷ್ಟ ಹೊಂದಿಕೆಯ ಪ್ರಿಫಿಕ್ಸ್ ನಿರ್ಧರಿಸುತ್ತದೆ. redirect-gateway def1 ಸಾಮಾನ್ಯವಾಗಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ; ಅದು ಎರಡು ಅರ್ಧಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ವಿಳಾಸ ಸ್ಥಳಾವಕಾಶದ ಕೆಳ ಅರ್ಧಕ್ಕೆ ಒಂದು ಮಾರ್ಗ ಮತ್ತು ಮೇಲಿನ ಅರ್ಧಕ್ಕೆ ಇನ್ನೊಂದು, ಹೀಗಾಗಿ ಮೂಲ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಬೇರೆ ಬಳಕೆಗಳಿಗೆ ಉಳಿಯುತ್ತದೆ. ಆ ಅರ್ಧಗಳು ಒಂದೇ ವಿಳಾಸಕ್ಕಿಂತ ಅಗಲವಾಗಿವೆ.

255.255.255.255 ಮಾಸ್ಕ್ನೊಂದಿಗೆ ಒಂದು ವಿಳಾಸದ ಮಾರ್ಗ /32 ಆಗಿದೆ, ಇದು IPv4 ತಲುಪಬಹುದಾದ ಗರಿಷ್ಠ ನಿರ್ದಿಷ್ಟತೆ. ಆ ವಿಳಾಸದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಾಗ /32 ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಯಾವ ಮಾರ್ಗ ಮೊದಲು ಸ್ಥಾಪನೆಯಾಯಿತು ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ಗೆಲ್ಲುತ್ತದೆ. ಇದು ವಿನಾಯಿತಿಯ ಹಿಂದಿನ ಕಾರ್ಯವಿಧಾನ, ಮತ್ತು ಮಾರ್ಗ ನಿಜವಾಗಿ ಇರುವವರೆಗೆ Linux, macOS ಮತ್ತು Windows ನಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

Windows ಎರಡನೇ ಆಯಾಮವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಎರಡು ಮಾರ್ಗಗಳು ಸಮಾನವಾಗಿ ನಿರ್ದಿಷ್ಟವಾದಾಗ, ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಇರುವುದು ಗೆಲ್ಲುತ್ತದೆ, ಮತ್ತು VPN ಅಡಾಪ್ಟರ್ ಫಲಿತಾಂಶವನ್ನು ಬದಲಿಸುವ ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ ಹೊಂದಿರಬಹುದು. /32 ಇನ್ನೂ ಅರ್ಧಗಳಿಗಿಂತ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ, ಆದ್ದರಿಂದ ವಿನಾಯಿತಿ ಸಾಮಾನ್ಯವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಆದರೆ ಹಿಂದಿನ ಅವಧಿಯ ಹಳೆಯ ಮಾರ್ಗ ಸಮಾನವಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿದ್ದರೆ ಗೊಂದಲದ ಫಲಿತಾಂಶ ನೀಡಬಹುದು.

ವಿನಾಯಿತಿ ಏನನ್ನು ಆವರಿಸುವುದಿಲ್ಲ

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

IPv6 ಎರಡನೆಯದು. ಮಾರ್ಗ ನಿರ್ದೇಶನವು IPv4 ಅನ್ನು ಮಾತ್ರ ನಿರ್ವಹಿಸುತ್ತದೆ. ದ್ವಿ ಸ್ಟ್ಯಾಕ್ ಗಮ್ಯಸ್ಥಾನವು IPv6 ಅನ್ನು ಆದ್ಯತೆ ನೀಡಬಹುದು, ಅದು ನೀತಿಯನ್ನು ಅವಲಂಬಿಸಿ ಸುರಂಗವನ್ನು ಅಥವಾ ಹೋಸ್ಟ್ನ IPv6 ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ IPv4 ವಿನಾಯಿತಿ ಎಂದಿಗೂ ಜಾರಿಗೆ ಬರುವುದಿಲ್ಲ. ನಿಮಗೆ ಹೊಂದಿಕೆಯಾಗುವ IPv6 ಮಾರ್ಗ ಬೇಕು, ಅಥವಾ ಆ ಕ್ಲೈಂಟ್ಗೆ IPv6 ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಉದ್ದೇಶಪೂರ್ವಕ ನಿರ್ಧಾರ ಬೇಕು.

ಅಪ್ಲಿಕೇಶನ್ ವ್ಯಾಪ್ತಿ ಮೂರನೆಯದು. ನಿಯಮ ಗಮ್ಯಸ್ಥಾನ ಆಧಾರಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಆ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುವ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆ ನೇರ ಮಾರ್ಗವನ್ನು ಬಳಸುತ್ತದೆ, ಅದು ನಿಮ್ಮ ಮನಸ್ಸಿನಲ್ಲಿದ್ದ ಪ್ರಕ್ರಿಯೆಯೇ ಆಗಿರಲಿ ಇಲ್ಲದಿರಲಿ. ವಿರುದ್ಧವಾಗಿ, ವೆಬ್ಸೈಟ್ ಹಲವು ವಿಳಾಸಗಳಿಂದ ಉತ್ತರಿಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು /32 ಅನ್ನು ಹೊರಗಿಡುವುದು ಸೈಟ್ ಅನ್ನು ಹೊರಗಿಡುವುದಿಲ್ಲ. ನಿಜವಾದ ಅಗತ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಕ ಮಾರ್ಗನಿರ್ದೇಶನ ಆಗಿದ್ದರೆ, Community ಕ್ಲೈಂಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕ ತಪ್ಪು ಸಾಧನ.

ನಿಮ್ಮನ್ನು ಮೋಸಗೊಳಿಸದೆ ವಿನಾಯಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದು

ಬ್ರೌಸರ್ನಿಂದ ಅಲ್ಲ, ಸ್ಥಾಪಿತ ಮಾರ್ಗದಿಂದ ಪ್ರಾರಂಭಿಸಿ. Linux ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ವಿಳಾಸಕ್ಕೆ ಯಾವ ಮಾರ್ಗ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಬಳಸುತ್ತದೆ ಎಂದು ಕರ್ನಲ್ಗೆ ಕೇಳಿ; Windows ನಲ್ಲಿ ಆ /32 ಗಾಗಿ ಮಾರ್ಗ ಕೋಷ್ಟಕ ಓದಿ. ಗೇಟ್ವೇ ಭೌತಿಕವಾದುದು, ಸುರಂಗವಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಮೂದು ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರೊಫೈಲ್ ಅನ್ವಯವಾಗಿಲ್ಲ ಅಥವಾ ಕ್ಲೈಂಟ್ಗೆ ಮಾರ್ಗಗಳನ್ನು ಬದಲಿಸುವ ಅಧಿಕಾರ ಇರಲಿಲ್ಲ.

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

ಕೊನೆಯದಾಗಿ, ಮಾರ್ಗವನ್ನು ಮೀರಿಸಬಹುದಾದ ನಿಯಂತ್ರಣಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಕ್ಲೈಂಟ್ ಬದಿಯ kill switch ಅಥವಾ Windows ನ block-outside-dns ಸೆಟ್ಟಿಂಗ್ ನೇರ ಸಂಚಾರವನ್ನು ನಿಷೇಧಿಸಬಹುದು, ಅದು ಮಾರ್ಗ ಸರಿಯಾಗಿದ್ದರೂ ವಿಫಲವಾಗುವ ಸಂಪರ್ಕವಾಗಿ ಕಾಣುತ್ತದೆ. ವಿನಾಯಿತಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ತೋರಿಸಲು ಆ ನಿಯಂತ್ರಣಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ; ನೀತಿ ನೇರ ಮಾರ್ಗವನ್ನು ನಿಷೇಧಿಸಿದರೆ, ವಿನಾಯಿತಿ VPN ಸೇವೆಯ ಮಾಲೀಕರಿಗೆ ವಿನ್ಯಾಸ ಸಮಸ್ಯೆ.

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