ಅಪ್ಸ್ಟ್ರೀಮ್ VPN ಹಿಂದಿನ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಕ್ಲೈಂಟ್ಗಳು: ರೂಟ್ ಅಥವಾ NAT?
ಅಪ್ಸ್ಟ್ರೀಮ್ VPN ಕ್ಲೈಂಟ್ನ ವಿಳಾಸವನ್ನು ಮಾತ್ರ ತಿಳಿದಿದೆ, ಆದ್ದರಿಂದ ಇನ್ನೊಂದು ಸಬ್ನೆಟ್ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಒಪ್ಪಿದ ರೂಟ್ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕ ಮೂಲ ಅನುವಾದ ಬೇಕು.
ಒಂದು ಗೇಟ್ವೇ ನಿಮ್ಮ ಸ್ವಂತ ಸಾಧನಗಳಿಗೆ WireGuard ಮತ್ತು ಬೇರೊಬ್ಬರ ನೆಟ್ವರ್ಕ್ಗೆ OpenVPN ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸುತ್ತದೆ. ಎರಡು ಒಳಗಿನ ಇಂಟರ್ಫೇಸ್ಗಳ ನಡುವಿನ ಫಾರ್ವರ್ಡಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಬ್ನೆಟ್ ಈಗ ಅಪ್ಸ್ಟ್ರೀಮ್ ಸೇವೆಯ ಭಾಗವಾಗಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವುದು ಸುಲಭ. ಹಾಗಲ್ಲ. ಕ್ಲೈಂಟ್ ಎಳೆದ ರೂಟ್ ನಿಮ್ಮ ಗೇಟ್ವೇಗೆ ವಿನಂತಿಗಳನ್ನು ಎಲ್ಲಿಗೆ ಕಳುಹಿಸಬೇಕೆಂದು ಹೇಳುತ್ತದೆ; ದೂರದ ನೆಟ್ವರ್ಕ್ ತಾನು ಎಂದೂ ಕೇಳದ ಸಾಧನಗಳಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಒಂದೇ ನಿಯಮ ಸೇರಿಸುವ ಮೊದಲು ಅಪ್ಸ್ಟ್ರೀಮ್ ನಿಜವಾಗಿ ಬೆಂಬಲಿಸುವ ರಿಟರ್ನ್ ಮಾದರಿಯನ್ನು ಆರಿಸಿ.
ರೂಟಿಂಗ್ ಮುಟ್ಟುವ ಮೊದಲು ರಿಟರ್ನ್ ಮಾದರಿಯನ್ನು ನಿರ್ಧರಿಸಿ
ಈ ವಾಕ್ಥ್ರೂನಲ್ಲಿ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಕ್ಲೈಂಟ್ಗಳು 10.90.0.0/24 ಬಳಸುತ್ತವೆ, ಗೇಟ್ವೇಗೆ ನೀಡಿದ ಅಪ್ಸ್ಟ್ರೀಮ್ ಟನೆಲ್ ವಿಳಾಸ 10.80.0.6, ಮತ್ತು ಅನುಮೋದಿತ ದೂರದ ಸಂಪನ್ಮೂಲ 172.20.0.30. ಈ ಆಕಾರಕ್ಕೆ ಎರಡು ಮಾದರಿಗಳು ಹೊಂದುತ್ತವೆ: ಡೌನ್ಸ್ಟ್ರೀಮ್ ಮೂಲವನ್ನು ಉಳಿಸಿ ದೂರದ ಬದಿಯಿಂದ ಅದನ್ನು ರೂಟ್ ಮಾಡಿಸುವುದು, ಅಥವಾ ಮೂಲವನ್ನು ಗೇಟ್ವೇಯ ಸ್ವಂತ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸುವುದು. ಈ ನಿರ್ಧಾರದ ನಂತರದ್ದೆಲ್ಲ ಯಾಂತ್ರಿಕ, ಮತ್ತು ನಿರ್ಧಾರಕ್ಕೆ ಸೇವೆಯ ಮಾಲೀಕರು ಬೇಕು. ಮೇಲಿನ ಒಂದು ಸಾಲು ದೂರದ ಬದಿಯೊಂದಿಗಿನ ರೂಟಿಂಗ್ ಒಪ್ಪಂದ; ಇನ್ನೊಂದು ನೀವು ಒಬ್ಬರೇ ಮಾಡಬಹುದಾದ ಸ್ಥಳೀಯ ನೀತಿ ಬದಲಾವಣೆ. ಈ ಎರಡನ್ನು ಗೊಂದಲಿಸುವುದೇ ಹತ್ತು ನಿಮಿಷದ ಬದಲಾವಣೆಯನ್ನು ಮಾತುಕತೆಯಾಗಿ ಮಾರ್ಪಡಿಸುತ್ತದೆ.
preserved: 10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6 -> 172.20.0.30ಒಂದು ಸಾಲನ್ನು ಆರಿಸಿ ಅದಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳಿ. ಸಾಲುಗಳು ಹಂತಗಳಲ್ಲ, ಪರ್ಯಾಯಗಳು, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸಿದರೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಯಾರೂ ವಿವರಿಸಲಾಗದ ವಿನ್ಯಾಸ ಬರುತ್ತದೆ.
ರೂಟ್ ಮೂಲಕ ಮೂಲ ಸಂರಕ್ಷಣೆ
ದೂರದ ಬದಿ ಡೌನ್ಸ್ಟ್ರೀಮ್ ವಿಳಾಸದಿಂದ ವಿನಂತಿ ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ಆ ಸಬ್ನೆಟ್ನ ಬೆಂಬಲಿತ ರೂಟ್ ಮತ್ತು ಪೀರ್ ಮಾಲೀಕತ್ವ ಬೇಕು, ಜೊತೆಗೆ ಅದನ್ನು ಸ್ವೀಕರಿಸುವ ಅಧಿಕಾರ. ಇವು ದೂರದ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಮತ್ತು ಯಾವ ಸ್ಥಳೀಯ Linux ರೂಟ್ ಅವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಅವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮತ್ತು ಲಿಖಿತವಾಗಿ ಕೇಳಿ, ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಅದನ್ನು ಸಾಗಿಸುವ ಟನೆಲ್ ಪೀರ್ನೊಂದಿಗೆ, ಮತ್ತು ಸೇವೆ ಸೈಟ್-ಟು-ಸೈಟ್ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆಯೇ ಎಂಬುದರ ಮೇಲೆ ಉತ್ತರ ಅವಲಂಬಿಸಿರುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಿ.
ಉತ್ತರ ಹೌದು ಆದರೆ, ಸ್ಥಳೀಯ ಸಂರಚನೆ ಚಿಕ್ಕದು: ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯ, ಡೌನ್ಸ್ಟ್ರೀಮ್ ಶ್ರೇಣಿಯನ್ನು ಆವರಿಸುವ WireGuard ಪೀರ್ನ allowed-ips, ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ದಾಟುವಿಕೆಯನ್ನು ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ನೀತಿ.
ಉದ್ದೇಶಪೂರ್ವಕ ಮೂಲ ಅನುವಾದ
ಸೇವೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಿದರೆ, ಹೊರಹೋಗುವಾಗ ಮೂಲವನ್ನು ಆ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸಿ ಮತ್ತು ಉತ್ತರಗಳಿಗಾಗಿ ಅದನ್ನು ತಿರುಗಿಸುವ conntrack ಸ್ಥಿತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ನಿಯಮವನ್ನು ಉದ್ದೇಶಿತ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಮೂಲಗಳು, ಉದ್ದೇಶಿತ ದೂರದ ಗಮ್ಯಸ್ಥಾನಗಳು ಮತ್ತು ಅಪ್ಸ್ಟ್ರೀಮ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಹೋಗುವ ಎಲ್ಲವನ್ನೂ ಅನುವಾದಿಸುವ ನಿಯಮ ಈ ಅಗತ್ಯಕ್ಕಿಂತ ಬಹಳ ದೊಡ್ಡ ನೀತಿ, ಮತ್ತು ಅದು ನಂತರ ನಿಮ್ಮನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುತ್ತದೆ.
IPv6 ಗೆ ತನ್ನದೇ ವಿನ್ಯಾಸ ಬೇಕು; IPv4 masquerade ಸಾಲನ್ನು ನಕಲಿಸುವುದು ವಾಸ್ತುಶಿಲ್ಪವಲ್ಲ. ಅನುವಾದಿತ ಮಾರ್ಗವನ್ನು ಕ್ಯಾಶ್ನಲ್ಲಿರುವ ಸಂಪರ್ಕದ ಬದಲು ಹೊಸ ಸಂಪರ್ಕದಿಂದ ಪರೀಕ್ಷಿಸಿ.
ಸ್ಥಳೀಯ ಡೇಟಾ ಮಾರ್ಗವು ಇನ್ನೂ ಕೆಲಸ ಮಾಡಬೇಕು
ಅನುವಾದವು ಸ್ಥಳೀಯ ಕೆಲಸವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ: ಗೇಟ್ವೇಗೆ ಇನ್ನೂ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ರೂಟ್, ಸರಿಯಾದ WireGuard ಪೀರ್ ಮೂಲ ಮಾಲೀಕತ್ವ, ಸಕ್ರಿಯ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗಳ ನಡುವೆ ಕಿರಿದಾದ ಫೈರ್ವಾಲ್ ನೀತಿ ಬೇಕು. ಗೇಟ್ವೇಯ ಮೇಲೆಯೇ ಸೃಷ್ಟಿಯಾದ ವಿನಂತಿ ಈ ಅನುಮತಿಗಳಲ್ಲಿ ಒಂದನ್ನೂ ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಗೇಟ್ವೇಯಲ್ಲಿನ ಸ್ಥಳೀಯ ಪರೀಕ್ಷೆಗಳು ಉತ್ತೀರ್ಣವಾಗುತ್ತವೆ ಆದರೆ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಾಧನಗಳು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತವೆ.
ಗೇಟ್ವೇಯಿಂದ ಅಲ್ಲ, ನಿಜವಾದ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಾಧನದಿಂದ ಪರೀಕ್ಷಿಸಿ. ಮೂಲ ವಿಳಾಸವೇ ಈ ಅಭ್ಯಾಸದ ಸಂಪೂರ್ಣ ಉದ್ದೇಶ.
ಒಂದು ಮೂಲ ಎಂದರೆ ಒಂದು ಸೆಷನ್ ಗುರುತು
ದೂರದ ಸೇವೆ ಪ್ರತಿ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಾಧನಕ್ಕೂ ಪ್ರತ್ಯೇಕ ದೃಢೀಕರಣವಲ್ಲ, ಗೇಟ್ವೇಯ ದೃಢೀಕೃತ ಸೆಷನ್ ಮತ್ತು ಅದರ ಅನುವಾದಿತ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಪ್ರತಿ-ಸಾಧನ ಅನುಮತಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಗುರುತುಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ, ಮತ್ತು ಹಲವು ಸಾಧನಗಳ ಪರವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಗೇಟ್ವೇಗೆ ಅನುಮತಿ ಇದೆಯೇ ಎಂದು ಸೇವೆಯ ಮಾಲೀಕರೊಂದಿಗೆ ದೃಢೀಕರಿಸಿ. ಅನುವಾದವು ಪ್ರತಿ-ಸಾಧನ ನೋಂದಣಿ ಅಗತ್ಯವನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ದಾರಿಯಲ್ಲ; ಸೇವೆ ಪ್ರತಿ ಸಾಧನದ ನೋಂದಣಿ ಕೇಳಿದರೆ, ಆ ಮಾದರಿಯನ್ನೇ ಬಳಸಿ ಅಥವಾ ಸೈಟ್-ಟು-ಸೈಟ್ ವ್ಯವಸ್ಥೆಗೆ ಮಾತುಕತೆ ನಡೆಸಿ.
ಆ ದೃಢೀಕರಣವನ್ನು ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ runbook ನಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಪರಿಶೀಲಕರು ವಿನ್ಯಾಸ ಅನುಮೋದನೆಯಾಗಿತ್ತೇ ಅಥವಾ ಕೇವಲ ಅನುಕೂಲವೇ ಎಂದು ಕೇಳುತ್ತಾರೆ.
ಸಂಪರ್ಕ ಕಡಿತದ ಸ್ಥಿತಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ, ನಂತರ ಮೂರು ವಿನಂತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ಅಪ್ಸ್ಟ್ರೀಮ್ ಟನೆಲ್ ಬಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಅನುಮತಿಸಿದ ದೂರದ ಟ್ರಾಫಿಕ್ ನಿಷೇಧಿಸಿದ ಸ್ಥಳದಲ್ಲಿ ಸಾಮಾನ್ಯ WAN ಫಾಲ್ಬ್ಯಾಕ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಅನುಸರಿಸಬಾರದು, ಆದ್ದರಿಂದ ದಾಟುವಿಕೆಯನ್ನು ಅನುಮತಿಸುವ ಫೈರ್ವಾಲ್ ನೀತಿಯೂ ಮುಚ್ಚಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ವಿಫಲವಾಗಬೇಕು. ನಂತರ ನಿಜವಾದ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸಾಧನದಿಂದ ಮೂರು ಸಂದರ್ಭಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ: ಕೆಲಸ ಮಾಡುವ ಅನುಮತಿಸಿದ ವಿನಂತಿ, ವಿಫಲವಾಗುವ ನಿಷೇಧಿತ ವಿನಂತಿ, ಮತ್ತು ಅನುಮತಿಸಿದ ವಿನಂತಿಯನ್ನು ನಿಲ್ಲಿಸುವ ಅಪ್ಸ್ಟ್ರೀಮ್ ವೈಫಲ್ಯ.
ಪ್ರತಿ ನಿಯಮಕ್ಕೆ ಒಂದು ಸಾಲಿನಲ್ಲಿ ರೋಲ್ಬ್ಯಾಕ್ ದಾಖಲಿಸಿ, ಇದರಿಂದ ಉದ್ದೇಶವನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸದೆ ಬದಲಾವಣೆಯನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು.