ಎರಡು OpenVPN ಸರ್ವರ್ಗಳಲ್ಲಿನ ಕ್ಲೈಂಟ್ಗಳು ಪರಸ್ಪರ ತಲುಪಬಹುದೇ?

ಎರಡನೇ OpenVPN ಸರ್ವರ್ ಅನ್ನು ನಿಲ್ಲಿಸುವುದರಿಂದ ಕ್ಲೈಂಟ್ಗಳು ಸಂಪರ್ಕಿಸಲು ಎರಡನೇ ಸ್ಥಳ ಸಿಗುತ್ತದೆ, ಅಷ್ಟೇ. ಅದು ಆ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಮೊದಲ ಸರ್ವರ್ನ ನೆಟ್ವರ್ಕ್ಗೆ ಸೇರಿಸುವುದಿಲ್ಲ, ಮತ್ತು client-to-client ಎಂಬ ಆಯ್ಕೆಯು ಒಂದೇ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆಯ ಒಳಗಿನ ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಮಾತ್ರ ಬದಲಿಸುತ್ತದೆ. ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅವುಗಳ ನಡುವೆ ರೂಟ್ ಮಾಡಿದಾಗ ಎರಡೂ ಪೂಲ್ಗಳು ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಆಗುತ್ತವೆ, ಪ್ರತಿ ದಿಕ್ಕಿಗೂ ಒಬ್ಬ ಮಾಲೀಕರೊಂದಿಗೆ. ಕೆಳಗಿನ ಎಲ್ಲವೂ ಬಳಕೆದಾರ ಜಾಗದ TUN ಮೋಡ್ ಮತ್ತು ಆ ಆಂತರಿಕ ಫಾರ್ವರ್ಡಿಂಗ್ ಆಫ್ ಆಗಿರುವುದನ್ನು ಊಹಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ನಿರ್ಣಯವನ್ನು ಕರ್ನಲ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಪುರಾಣ: ಒಂದು ಖಾತೆ ಪಟ್ಟಿ, ಒಂದು ನೆಟ್ವರ್ಕ್

ದೃಢೀಕರಣ ಮತ್ತು ತಲುಪುವಿಕೆ ಗೊಂದಲಕ್ಕೀಡಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಎರಡೂ ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ ಇರುತ್ತವೆ. ಎರಡೂ ಗೇಟ್ವೇಗಳಲ್ಲಿ ಯಾವುದಕ್ಕಾದರೂ ಲಾಗಿನ್ ಆಗಬಲ್ಲ ಬಳಕೆದಾರರು ಹೊರಗಿನಿಂದ ಎರಡು ಬಾಗಿಲುಗಳಿರುವ ಒಂದೇ ವ್ಯವಸ್ಥೆಯ ಬಳಕೆದಾರರಂತೆ ಕಾಣುತ್ತಾರೆ. ಒಳಗೆ, ಪ್ರತಿ ಸರ್ವರ್ ತನ್ನದೇ ಪೂಲ್ನಿಂದ ವಿಳಾಸಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ತಾನು ಮುಗಿಸುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮಾತ್ರ ರೂಟ್ಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಹಾಗಾಗಿ ಗೇಟ್ವೇ A ಯಲ್ಲಿನ ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇ B ಯಲ್ಲಿನ ಕ್ಲೈಂಟ್ಗೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುವಾಗ ತನ್ನ ಸರ್ವರ್ನೇ ಕೇಳರಿಯದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಕೇಳುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ A ಯ ಡೀಫಾಲ್ಟ್ ರೂಟ್ಗೆ ಹೋಗಿ, ಟನೆಲ್ ಬಿಟ್ಟು, ಅದನ್ನು ಅನುಮತಿಸಲು ಎಂದೂ ಕೇಳದ ಫೈರ್ವಾಲ್ ತಲುಪುತ್ತದೆ.

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

ಪ್ರತಿ ಗೇಟ್ವೇಗೆ ಅದರದೇ ಪೂಲ್ ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ವಿಳಾಸ ನೀಡಿ

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

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

ಎರಡೂ ಕಡೆ ರೂಟ್ ಸ್ಥಾಪಿಸಿ

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

ಪೂಲ್ಗಳನ್ನು ಬದಲಿಸಿ ಇನ್ನೊಂದು ಹೋಸ್ಟ್ನಲ್ಲೂ ಅದನ್ನೇ ಮಾಡಿ. ಸಂಬಂಧವಿಲ್ಲದ ಸ್ಕ್ರಿಪ್ಟ್ನಿಂದ ಅದೇ ರೂಟ್ ಅನ್ನೇ ಪದೇ ಪದೇ ಸೇರಿಸುವುದು ಹೋಸ್ಟ್ಗೆ ಹಲವು ಪ್ರತಿಗಳು ಮತ್ತು ಮುಂದಿನ ಬಾರಿ ಯಾರಾದರೂ ಕೋಷ್ಟಕ ಓದಿದಾಗ ನಿಗೂಢ ಬದಲಾವಣೆ ಉಳಿಯುವ ದಾರಿ. ಟ್ರಾನ್ಸಿಟ್ ಕೊಂಡಿಯೇ ಟನೆಲ್ ಆಗಿದ್ದರೆ, ರೂಟ್ ಆ ಟನೆಲ್ನ ಟೋಪಾಲಜಿಗೆ ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಹಾಪ್ ಅದರ ಮರುಸಂಪರ್ಕವನ್ನು ದಾಟಬೇಕು. ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಮಾಯವಾಗುವ ಟ್ರಾನ್ಸಿಟ್ ವಿಳಾಸವು ಪೂಲ್ಗಳ ನಡುವಿನ ದಾರಿಯನ್ನೂ ತನ್ನೊಂದಿಗೆ ಕೊಂಡೊಯ್ಯುತ್ತದೆ, ಇದು ಕಂಡುಹಿಡಿಯುವ ಬದಲು ಘೋಷಿಸಲು ಯೋಗ್ಯವಾದ ವಿನ್ಯಾಸ ಗುಣ.

ಮಾಲೀಕತ್ವವನ್ನು ನಕಲಿ ಮಾಡದೆ ಕ್ಲೈಂಟ್ ರೂಟ್ ಪುಶ್ ಮಾಡಿ

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

push "route 10.64.20.0 255.255.255.0"

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

ಒಂದು ವಿನಂತಿಯನ್ನು ಸಾಬೀತು ಮಾಡಿ, ಇನ್ನೊಂದನ್ನು ನಿರಾಕರಿಸಿ

ನೈಜ ಕಾರ್ಯಾಚರಣೆ ಆರಿಸಿ, ಉದಾಹರಣೆಗೆ 10.64.10.21 ನಲ್ಲಿನ ಕ್ಲೈಂಟ್ನಿಂದ 10.64.20.37 ನಲ್ಲಿನ ಸೇವೆಗೆ HTTPS, ಮತ್ತು ಎರಡೂ ಹೋಸ್ಟ್ಗಳಲ್ಲಿ ನಿಖರವಾಗಿ ಅದನ್ನೇ ಅನುಮತಿಸಿ. ಪ್ರತಿ ಫೈರ್ವಾಲ್ ತನ್ನ ಒಳಬರುವ ಬದಿಯಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಮತ್ತು ಹಿಂತಿರುಗುವ ಬದಿಯಲ್ಲಿ ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ ಉತ್ತರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ; ಗಮ್ಯಸ್ಥಾನದ ಸ್ವಂತ ಸೇವಾ ನೀತಿ ಅದನ್ನು ಇನ್ನೂ ಒಪ್ಪಬೇಕು.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

ಪರಸ್ಪರ ರೂಟ್ಗಳಿದ್ದಾಗ ಮೂಲ NAT ಅನಗತ್ಯ ಮತ್ತು ಇಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಹಾನಿಕಾರಕ: ಮೂಲವನ್ನು ಅನುವಾದಿಸುವುದು ಯಾವ ಕ್ಲೈಂಟ್ ವಿನಂತಿ ಮಾಡಿತು ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಬದಿಯಲ್ಲಿ ಮೂಲ ಆಧಾರಿತ ನೀತಿಯನ್ನು ಸೋಲಿಸುತ್ತದೆ. ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನಕ್ಕಾಗಿ ಇರುವ masquerade ನಿಯಮ ಈ ದಾರಿಯನ್ನೂ ಹಿಡಿಯುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ನಂತರ ನಿರಾಕರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ಪೂಲ್ B ಗೆ ಸ್ಥಳೀಯವಾಗಿ ಉಳಿಯಬೇಕಾದ ಸೇವೆ ಪೂಲ್ A ಯಿಂದ ತಲುಪಲಾಗದೇ ಇರಬೇಕು, ಮತ್ತು ಒಂದೇ ಗೇಟ್ವೇಯ ಕ್ಲೈಂಟ್ ಜೋಡಿಗಳನ್ನೂ ಪರೀಕ್ಷಿಸಬೇಕು, ಏಕೆಂದರೆ ನೀವು ಈಗ ತಾನೇ ಬದಲಿಸಿದ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಅವರಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ.

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