ಒಂದೇ OpenVPN ಕ್ಲೈಂಟಿನಲ್ಲಿ ಎರಡು ಸೇವಾ ವಿಳಾಸಗಳು: iroute ಮತ್ತು lo

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

ಉಪನಾಮ ಸ್ಥಳೀಯ, ಮಾಲೀಕತ್ವ ದೂರದ್ದು

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

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

ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲೂ ಎರಡು ಶ್ರೇಣಿಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಉದಾಹರಣೆಯಲ್ಲಿನ ವಿಳಾಸಗಳು ದಾಖಲೀಕರಣ ಮೌಲ್ಯಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ನಿಜವಾದ LAN ಜೊತೆ ಅತಿವ್ಯಾಪಿಸುವುದು ಕೆಲಸ ಮಾಡುವ ಸೆಟಪ್ ಮುರಿದಂತೆ ಕಾಣಿಸುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ.

ಕ್ಲೈಂಟಿನಲ್ಲಿ ವಿಳಾಸವನ್ನು ಶಾಶ್ವತವಾಗಿ ಸೇರಿಸಿ

ಸೇವಾ ವಿಳಾಸವನ್ನು ಹೋಸ್ಟ್ ಪ್ರಿಫಿಕ್ಸ್ನೊಂದಿಗೆ ಲೂಪ್ಬ್ಯಾಕ್ನಲ್ಲಿ ಇರಿಸಿ, ಇದರಿಂದ ಹೋಸ್ಟ್ ಅದನ್ನು ತಲುಪಬೇಕಾದ ಸಬ್ನೆಟ್ ಎಂದಲ್ಲ, ಸ್ಥಳೀಯ ಇನ್ಪುಟ್ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ip address add 10.66.0.10/32 dev lo ಒಂದು ವಿಳಾಸಕ್ಕೆ ಅದನ್ನು ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ವಿಳಾಸಕ್ಕೆ ಆಜ್ಞೆಯನ್ನು ಪುನರಾವರ್ತಿಸುವುದು ಎರಡು ಸೇವೆಗಳನ್ನು ಮಾದರೀಕರಿಸುತ್ತದೆ.

ಅದನ್ನು ಒಂದು ಬಾರಿಯ ಪರೀಕ್ಷೆಯಾಗಿ ಓಡಿಸಿ, ನಂತರ ಹೋಸ್ಟಿನ ನೆಟ್ವರ್ಕ್ ಸಂರಚನೆಯನ್ನು ಹೊಂದಿರುವುದಕ್ಕೆ ಸರಿಸಿ, ಏಕೆಂದರೆ ರನ್ಟೈಮ್ ಸೇರ್ಪಡೆ ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ ಮತ್ತು ಮರುಸಂಪರ್ಕಗಳ ನಡುವೆ ನಕಲುಗಳು ಸಂಗ್ರಹವಾಗುತ್ತವೆ. ನೆಟ್ವರ್ಕ್ನ ನಂತರ ಕ್ರಮಗೊಳಿಸಿದ systemd ಘಟಕವು ಒಂದು ಆಯ್ಕೆ, ಮತ್ತು ವಿತರಣೆಯ ನೆಟ್ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ ಇನ್ನೊಂದು. ನೀವು ಯಾವುದನ್ನು ಆರಿಸಿದರೂ, ಅಪ್ಲಿಕೇಶನ್ ಬೈಂಡ್ ಆಗುವ ಮೊದಲು ವಿಳಾಸವು ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸೇವೆ ತಪ್ಪು ಸಾಕೆಟ್ನಲ್ಲಿ ಏಳುತ್ತದೆ. ಕೈಯಿಂದ ಆಜ್ಞೆಯ ನಂತರವಲ್ಲ, ಮರುಬೂಟ್ನ ನಂತರ ip address show dev lo ನಿಂದ ಪರಿಶೀಲಿಸಿ.

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

ಹಬ್ ನಿಜವಾಗಿ ಓದುವ CCD ಫೈಲ್ನಲ್ಲಿ ಅದನ್ನು ಕೇಳಿ

ಸರ್ವರ್ನಲ್ಲಿ ಮಾಲೀಕತ್ವದ ಘೋಷಣೆ ದೃಢೀಕೃತ ಸಾಮಾನ್ಯ ಹೆಸರಿನಿಂದ ಆಯ್ಕೆಯಾದ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಫೈಲ್ಗೆ ಹೋಗುತ್ತದೆ, client-config-dir ಹೆಸರಿಸಿದ ಡೈರೆಕ್ಟರಿಯೊಳಗೆ. ಸಾಲು iroute 10.66.0.10 255.255.255.255, ಪ್ರತಿ ವಿಳಾಸಕ್ಕೆ ಒಂದು, ಮತ್ತು ಆ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಯಾವ ಪೀರ್ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು ಎಂದು ಸರ್ವರ್ಗೆ ಹೇಳುತ್ತದೆ.

ಎರಡು ವಿವರಗಳು ಇದನ್ನು ಮೌನವಾಗಿ ಮುರಿಯುತ್ತವೆ. ಫೈಲ್ನ ಹೆಸರು ಸರ್ವರ್ ನಿಜವಾಗಿ ಬಳಸುವ ಹೆಸರಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಅದು username-as-common-name ಆಟದಲ್ಲಿದ್ದಾಗ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಮತ್ತು iroute ಕ್ಲೈಂಟ್ ಸಂರಚನಾ ಡೈರೆಕ್ಟರಿ ಸಂರಚಿಸಲಾದ TUN ಮೋಡ್ನಲ್ಲಿ ಮಾತ್ರ ಜಾರಿಗೆ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಬ್ರಿಡ್ಜ್ ನಿಯೋಜನೆಯಲ್ಲಿ ಅದೇ ಸಾಲು ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ಇರುವ ಫೈಲ್ಗೆ ಸಾಲುಗಳನ್ನು ಸೇರಿಸಿ, ಅದನ್ನು ಬದಲಾಯಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಅದು ಈಗಾಗಲೇ ಸ್ಥಿರ ವಿಳಾಸ ಅಥವಾ push ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿರಬಹುದು. OpenVPN 2.6 ಉಲ್ಲೇಖ ಡೈರೆಕ್ಟರಿ ಮತ್ತು ಮಾಲೀಕತ್ವದ ನಿರ್ದೇಶನ ಎರಡನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ.

ಹಬ್ನ ಸ್ವಂತ ಕರ್ನೆಲ್ಗೂ ಆ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಮಾರ್ಗ ಬೇಕು ಇದರಿಂದ ಸ್ಥಳೀಯವಾಗಿ ಉತ್ಪತ್ತಿಯಾದ ಸಂಚಾರವು ಟನೆಲ್ ಪ್ರಕ್ರಿಯೆಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ. ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ route 10.66.0.10 255.255.255.255 ಸರ್ವರ್ ಸ್ವತಃ ಉತ್ಪಾದಿಸುವ ಸಂಚಾರವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಇತರ ಕ್ಲೈಂಟ್ಗಳು ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಾವೇ ಕಲಿಯಲು push "route 10.66.0.10 255.255.255.255" ಬೇಕು.

ರೂಟಿಂಗ್ ಮತ್ತು ಅಧಿಕಾರ ಪ್ರತ್ಯೇಕವಾಗಿ ಉಳಿಯುತ್ತವೆ. ತಳ್ಳಲಾದ ಮಾರ್ಗವು ಕ್ಲೈಂಟಿಗೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ; ಸೇವೆಯು ಇನ್ನೂ ಕರೆದವರನ್ನು ತನ್ನದೇ ಷರತ್ತುಗಳಲ್ಲಿ ಸ್ವೀಕರಿಸಬೇಕು.

ಇನ್ಪುಟ್ ನೀತಿ ಮತ್ತು ಉತ್ತರ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಉತ್ತರಗಳಿಗೆ ಕರೆದವರಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು. ಸಾಮಾನ್ಯ ಟನೆಲ್ ಪೂಲ್ನೊಳಗಿನ ಕರೆದವರಿಗೆ ಆ ಮಾರ್ಗ ಈಗಾಗಲೇ ಇದೆ, ಏಕೆಂದರೆ ಟನೆಲ್ ಸಾಧನವು ಅದನ್ನು ಒಯ್ಯುತ್ತದೆ. ಇನ್ನೊಂದು ರೂಟ್ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್ನ ಹಿಂದಿನ ಕರೆದವರಿಗೆ ಆ ನೆಟ್ವರ್ಕ್ನ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವೂ ಬೇಕು, ಮತ್ತು ಇಲ್ಲಿಯೇ ಅಸಮಮಿತ ಸೆಟಪ್ಗಳು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ.

ಅದೇ ಪೋರ್ಟ್ನಲ್ಲಿ ಬೇರೆ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಎರಡನೇ ಆಲಿಸುವವರ ಬಗ್ಗೆ ಗಮನವಿರಲಿ, ಏಕೆಂದರೆ ಕರ್ನೆಲ್ ಹೊಂದಿಕೆಯಾಗುವ ಸಾಕೆಟ್ಗೆ ತಲುಪಿಸುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಕಾಣುತ್ತವೆ. ss -lntp ನಿಂದ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಬದ್ಧವಾದ ವಿಳಾಸವು ಸೇವಾ ಉಪನಾಮವೇ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಇಲ್ಲಿ ಮೂಲ NAT ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸೇರಿಸುವುದು ನಿಮ್ಮ ಲಾಗ್ಗಳು ಅವಲಂಬಿಸಿರುವ ಕರೆದವರ ಗುರುತನ್ನು ಮರೆಮಾಡುತ್ತದೆ.

ವಿಳಾಸಗಳು ಮತ್ತು ಮಾಲೀಕತ್ವವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

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

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