OpenVPN ಮೂಲಕ ಸಾರ್ವಜನಿಕ ಪ್ರಿಫಿಕ್ಸ್: ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ
ರೂಟ್ ಮಾಡಿದ ಸಾರ್ವಜನಿಕ ಪ್ರಿಫಿಕ್ಸ್ OpenVPN TUN ಲಿಂಕ್ ಅನ್ನು ದಾಟಬಹುದು, ಆದರೆ ಪ್ರತ್ಯುತ್ತರಗಳು ಅದೇ ಮಾರ್ಗದಲ್ಲಿ ಹಿಂತಿರುಗಬೇಕು. ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಮೂಲ ವಿಳಾಸವನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿ.
ಟನಲ್ ಮೇಲೆ ಬರುವುದನ್ನು ಮತ್ತು ಕ್ಲೈಂಟ್ ಆಚೆ ಬದಿಗೆ ಪಿಂಗ್ ಮಾಡುವುದನ್ನು ನೋಡಿ, ನಂತರ VPN ಹಿಂದೆ ಇರುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಬೇರೆ ಎಲ್ಲಿಂದಲೋ ಪ್ರತ್ಯುತ್ತರ ನೀಡುತ್ತದೆ, ಅಥವಾ ಯಾವುದೇ ಉತ್ತರ ನೀಡುವುದಿಲ್ಲ. ಈ ಲಕ್ಷಣಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಸೈಫರ್ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರಗಳೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಪೂರೈಕೆದಾರರು ರೂಟ್ ಮಾಡಿದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು IP ಮಾರ್ಗವಾಗಿ ತಲುಪಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು OpenVPN ಮೂಲಕ ಸಾಗಿಸುವುದು ಎಂದರೆ ಆ ಮಾರ್ಗವನ್ನು ಎರಡು ಹಂತಗಳಲ್ಲಿ ಮರುಸೃಷ್ಟಿಸುವುದು ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ ಮೂಲ ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು. WAN ಅನ್ನು ಸೇತುವೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗೆ ವಿಳಾಸ ಸೇರಿಸುವುದು ಮೇಲಿನ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.
ಪ್ರಿಫಿಕ್ಸ್ ಮೊದಲು ನಿಮ್ಮ ಕಡೆಗೆ ರೂಟ್ ಆಗಬೇಕು
ಬ್ಲಾಕ್ ಹೇಗೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ ಎಂದು ಪೂರೈಕೆದಾರರನ್ನು ಕೇಳಿ. ನಿಮ್ಮ ಸರ್ವರ್ನ ಮುಖ್ಯ ವಿಳಾಸಕ್ಕೆ ರೂಟ್ ಮಾಡಿದ ಪ್ರಿಫಿಕ್ಸ್, ಪೂರೈಕೆದಾರರು WAN ವಿಭಾಗದಲ್ಲಿ ನೇರವಾಗಿ ತಲುಪಲು ನಿರೀಕ್ಷಿಸುವ ವಿಳಾಸಗಳಿಗಿಂತ ಬೇರೆಯದೇ ಆಗಿದೆ. ಇಲ್ಲಿ ವಿವರಿಸಿದ ವಿನ್ಯಾಸದೊಂದಿಗೆ ಮೊದಲ ಮಾದರಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಪೂರೈಕೆದಾರರು 198.51.100.64/28 ಅನ್ನು ನಿಮ್ಮ ಪ್ರವೇಶ ಸರ್ವರ್ಗೆ ರೂಟ್ ಮಾಡಿದರೆ, ಆ ಶ್ರೇಣಿಯ ಪ್ಯಾಕೆಟ್ಗಳು ಸರ್ವರ್ಗೆ ಬಂದು ನೀವು ಅವನ್ನು ಮುಂದಕ್ಕೆ ರವಾನಿಸದಿದ್ದರೆ ಅಲ್ಲೇ ನಿಲ್ಲುತ್ತವೆ. ಪೂರೈಕೆದಾರರು ಬದಲಿಗೆ ಶ್ರೇಣಿಯನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಂಕ್ಗೆ ಸೇತುವೆ ಮಾಡಿದರೆ, ಸರ್ವರ್ ಅದಕ್ಕೆ ARP ಉತ್ತರ ನೀಡಬೇಕು, ಅದು ಬೇರೆ ಸಮಸ್ಯೆ.
OpenVPN ಅನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ವಿತರಣಾ ಮಾದರಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ: ಹೊರಗಿನಿಂದ ಬ್ಲಾಕ್ನಲ್ಲಿನ ವಿಳಾಸಕ್ಕೆ ಪಿಂಗ್ ಮಾಡಿ ಮತ್ತು ಯಾವ ಇಂಟರ್ಫೇಸ್ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ. ಏನೂ ಬಂದಿಲ್ಲದಿದ್ದರೆ, ಯಾವುದೇ ಟನಲ್ ಸಂರಚನೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ವಿಳಾಸವು WAN ನಲ್ಲಿ ನೇರವಾಗಿ ಉತ್ತರಿಸಿದರೆ, ಪೂರೈಕೆದಾರರು ರೂಟ್ ಮಾಡುವ ಬದಲು ಸೇತುವೆ ಮಾಡುತ್ತಿದ್ದಾರೆ, ಮತ್ತು ಕೆಳಗಿನ ವಿನ್ಯಾಸ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.
ಎರಡು ರೂಟಿಂಗ್ ಹಂತಗಳು: ಕರ್ನಲ್ ಮಾರ್ಗ ಮತ್ತು iroute
OpenVPN ಗೆ ಪ್ರಿಫಿಕ್ಸ್ ಎರಡು ಸ್ಥಳಗಳಲ್ಲಿ ಬೇಕು. ಪ್ರಿಫಿಕ್ಸ್ ಟನಲ್ ಸಾಧನಕ್ಕೆ ಸೇರಿದ್ದು ಎಂದು ಕರ್ನಲ್ಗೆ ತಿಳಿದಿರಬೇಕು, ಇದರಿಂದ ರವಾನೆಯಾದ ಪ್ಯಾಕೆಟ್ಗಳು ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗದ ಬದಲು OpenVPN ಗೆ ಪ್ರವೇಶಿಸುತ್ತವೆ. ಯಾವ ದೃಢೀಕೃತ ಕ್ಲೈಂಟ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂದು OpenVPN ಕೂಡ ತಿಳಿದಿರಬೇಕು, ಮತ್ತು ಅದು ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿನ iroute ನಮೂದು.
ಸರ್ವರ್-ಬದಿಯ ಮಾರ್ಗವು ಹೀಗೆ ಕಾಣುತ್ತದೆ, ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಮಾಸ್ಕ್ ಹಂಚಿಕೆಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು:
ip route add 198.51.100.64/28 dev tun0
ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಸಂರಚನೆ ಮಾಲೀಕತ್ವವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ. ಅದನ್ನು ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರದ ಸಾಮಾನ್ಯ ಹೆಸರಿನಿಂದ ಹೆಸರಿಸಿದ CCD ಫೈಲ್ನಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ಸರ್ವರ್ ನಿಜವಾಗಿ ಓದುವ ಡೈರೆಕ್ಟರಿ ಅದೇ ಎಂದು ಖಚಿತಪಡಿಸಿ:
iroute 198.51.100.64 255.255.255.240
OpenVPN ನ ರೂಟ್ ಮಾಡಿದ ನೆಟ್ವರ್ಕ್ಗಳ ದಸ್ತಾವೇಜು ಎರಡೂ ಹಂತಗಳನ್ನು ಮತ್ತು ಅವು ಏಕೆ ಪ್ರತ್ಯೇಕವಾಗಿವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. iroute ಇಲ್ಲದ ಕರ್ನಲ್ ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮಾಲೀಕರಿಲ್ಲದೆ ಟನಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು OpenVPN ಅವನ್ನು ಬಿಸಾಡುತ್ತದೆ. ಕರ್ನಲ್ ಮಾರ್ಗ ಇಲ್ಲದ iroute ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸರ್ವರ್ನ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗದಲ್ಲಿ ಬಿಡುತ್ತದೆ. ಎರಡೂ ತಪ್ಪುಗಳು ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ಮುರಿದ ಟನಲ್ನಂತೆ ಕಾಣುತ್ತವೆ.
ಸೇವಾ ವಿಳಾಸ ಎಲ್ಲಿ ಇರುತ್ತದೆ
ನಿಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ ಟನಲ್ನ ಸ್ವಂತ ವಿಳಾಸಗಳಿಗಿಂತ ಬೇರೆ. ಬಯಸಿದರೆ ಲಿಂಕ್ ಅನ್ನು ಖಾಸಗಿ ಜಾಗದಿಂದ ಸಂಖ್ಯೆ ಮಾಡಿ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಸೇವಾ ವಿಳಾಸವನ್ನು ಸೇವೆ ನಿಜವಾಗಿ ನಡೆಯುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ.
ಸೇವೆಯನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕೊನೆಗೊಳಿಸುವ Linux ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಒಂದು ಹೋಸ್ಟ್ ವಿಳಾಸ ಸಾಕು:
ip address add 198.51.100.70/32 dev lo
ಪ್ರಿಫಿಕ್ಸ್ ಮುಂದೆ VM ಹೋಸ್ಟ್ ಅಥವಾ ಇನ್ನೊಂದು LAN ಗೆ ರೂಟ್ ಆದರೆ, ಬದಲಿಗೆ ಆ ಕೆಳಮುಖ ಮಾರ್ಗ ಮತ್ತು ಅದರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸಂರಚಿಸಿ. ಬ್ಲಾಕ್ನ ಪ್ರತಿ ವಿಳಾಸವನ್ನು VPN ಕ್ಲೈಂಟ್ಗೆ ನಿಗದಿಪಡಿಸುವುದು ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ನಂತರ ಘರ್ಷಣೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಮೂಲವನ್ನು ಇರಿಸಿ
ನಿಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ನಿಂದ ಪ್ರತ್ಯುತ್ತರ ಟನಲ್ ಮೂಲಕ ಹೊರಬಂದು ಪೂರೈಕೆದಾರರ ಮಾರ್ಗವನ್ನು ತಲುಪಬೇಕು. ದೂರದ ಹೋಸ್ಟ್ ಅದನ್ನು ತನ್ನದೇ ISP ಮೂಲಕ ಕಳುಹಿಸಿದರೆ, ಮೂಲ ವಿಳಾಸ ನಕಲಿ ಎಂಬಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರು ಅಥವಾ ಗಮ್ಯಸ್ಥಾನ ಅದನ್ನು ಬಿಸಾಡುತ್ತದೆ. ಪರಿಹಾರ ಮೂಲ-ಆಧಾರಿತ ನಿಯಮ ಅಥವಾ ಮೀಸಲಾದ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ, ಇನ್ನಷ್ಟು ಅಗಲವಾದ NAT ಅಲ್ಲ. ಅದಿಲ್ಲದೆ ಸೇವೆ ಟನಲ್ ಸಂಗಾತಿಯಿಂದ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಉಳಿದ ಎಲ್ಲಾ ಕಡೆಯಿಂದ ವಿಫಲವಾಗುತ್ತದೆ.
ಪ್ರವೇಶ ಸರ್ವರ್ನಲ್ಲಿ ಅಗಲವಾದ masquerade ನಿಯಮ ಸಾಮಾನ್ಯ ಅಪರಾಧಿ. ಅದು ಸಾರ್ವಜನಿಕ ಮೂಲವನ್ನು ಸರ್ವರ್ನ ಮುಖ್ಯ ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ನಿಜವಾದದ್ದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ:
iptables -t nat -S POSTROUTING
NAT ಅನ್ನು ಅದು ಬೇಕಾದ ಖಾಸಗಿ VPN ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು ನಿಯೋಜಿತ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಅನುವಾದಿಸದೆ ಬಿಡಿ. ನಂತರ ಸರ್ವರ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ರವಾನಿಸುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಡಿಫಾಲ್ಟ್-ನಿರಾಕರಣೆ ರವಾನೆ ಸರಪಳಿ ಅದನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಸಾಡುತ್ತದೆ.
ನಂಬುವ ಮೊದಲು ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ
ಪರಿಶೀಲನೆ ಒಂದಲ್ಲ, ನಾಲ್ಕು ಅವಲೋಕನಗಳು. ಪೂರೈಕೆದಾರರ ಮಾರ್ಗ ಬರುತ್ತದೆ, ಕರ್ನಲ್ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಟನಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, OpenVPN ಅದನ್ನು ಸರಿಯಾದ ಕ್ಲೈಂಟ್ಗೆ ಆರೋಪಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತ್ಯುತ್ತರ ಸಾರ್ವಜನಿಕ ಮೂಲದೊಂದಿಗೆ ಸುರಕ್ಷಿತವಾಗಿ ಹಿಂತಿರುಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪ್ರತಿ ಅವಲೋಕನಕ್ಕೂ ತನ್ನದೇ ಆದ ಆಜ್ಞೆ ಇದೆ, ಆದ್ದರಿಂದ ವೈಫಲ್ಯವು ಇಡೀ ವಿನ್ಯಾಸದ ಬದಲು ಒಂದು ಪದರವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರತಿ ಸಂರಚನಾ ಬದಲಾವಣೆಯ ನಂತರ ಅವನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಚಲಾಯಿಸಿ.
ನಿಯೋಜಿತ ವಿಳಾಸ ಯಾವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಕರ್ನಲ್ಗೆ ಕೇಳಿ, ಮತ್ತು ವಿನಂತಿ ನಡೆಯುತ್ತಿರುವಾಗ ಟನಲ್ ಅನ್ನು ಗಮನಿಸಿ:
ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70
ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಫಿಲ್ಟರಿಂಗ್ ಸರಿಯಾದ ಮಾರ್ಗವನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು. ಟನಲ್ನಲ್ಲಿ ಮತ್ತು ಅಪ್ಲಿಂಕ್ನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್ ತಾನು ಬಂದ ಇಂಟರ್ಫೇಸ್ಗೆ ಮೂಲ ಹೊಂದಿಕೆಯಾಗದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ ಎಂದು ನೆನಪಿಡಿ:
sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter
ಕೊನೆಯದಾಗಿ, ವೈಫಲ್ಯದ ಪ್ರಕರಣವನ್ನು ಪರೀಕ್ಷಿಸಿ. ಟನಲ್ ಅನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಪ್ರಿಫಿಕ್ಸ್ ಸಾಮಾನ್ಯ ಅಪ್ಲಿಂಕ್ನಿಂದ ಸೋರಿಕೆಯಾಗದಂತೆ ಖಚಿತಪಡಿಸಿ. VPN ಮರುಸ್ಥಾಪಿಸಿದಾಗ ಹೋಸ್ಟ್ ತೆರೆಯುವ ಪೋರ್ಟ್ಗಳನ್ನು ವಿಸ್ತರಿಸದೆ ಸೇವೆ ಮರಳಬೇಕು.