ಸೈಟ್-ಟು-ಸೈಟ್ ವಿರುದ್ಧ ರಿಮೋಟ್ ಆಕ್ಸೆಸ್ VPN: ಎರಡೂ ಏನನ್ನು ಸಂಪರ್ಕಿಸುತ್ತವೆ
ಒಂದು ಗೇಟ್‌ವೇಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಸಾಧನಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ರೂಟ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ, ವಿಳಾಸಗಳನ್ನು ಯೋಜಿಸಿ, ನಂತರ ನಿಜವಾದ ಹೋಸ್ಟ್‌ನಿಂದ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ನೀತಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಎರಡೂ ವಿನ್ಯಾಸಗಳನ್ನು VPN ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಸೈಟ್-ಟು-ಸೈಟ್ ಸುರಂಗವು ಎರಡು ಗೇಟ್‌ವೇಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳ ಹಿಂದಿನ ಪ್ರತಿಯೊಂದು ಹೋಸ್ಟ್ ಏನನ್ನೂ ಸ್ಥಾಪಿಸದೆ ಇನ್ನೊಂದು ಬದಿಯ ಅನುಮತಿಸಿದ ವಿಳಾಸಗಳನ್ನು ತಲುಪಬಹುದು. ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ ಸುರಂಗವು ಪ್ರತ್ಯೇಕ ಸಾಧನಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಕ್ಲೈಂಟ್. ಈ ಹೋಲಿಕೆ ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ನಿಯೋಜನೆ ದೋಷಗಳು ಒಂದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ ಇನ್ನೊಂದರ ನಡವಳಿಕೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವುದರಿಂದ ಉಂಟಾಗುತ್ತವೆ, ಮತ್ತು ಲಕ್ಷಣ ಸಾಮಾನ್ಯವಾಗಿ ಸುರಂಗವು ನಿಜವಾಗಿಯೂ ತಲುಪಿದ ಸೇವೆಯಲ್ಲಿ ಸಮಯ ಮೀರಿಕೆ ಆಗಿರುತ್ತದೆ.
ಎರಡು ವಿನ್ಯಾಸಗಳು, ಎರಡು ಗಡಿಗಳು
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
ಯಾವುದೇ ವಿನ್ಯಾಸವು LAN ಪ್ರಸಾರ ಡೊಮೇನ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದಿಲ್ಲ. ದೂರದ ಬದಿಯ ಸಾಧನಗಳು ಸ್ಥಳೀಯ ಶೋಧ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹಾಗೆ ನಿರೀಕ್ಷಿಸುವುದು ಬಿಟ್ಟುಬಿಡಬೇಕಾದ ಮೊದಲ ಊಹೆ. ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರಕಟಿಸುವ ಖಾಸಗಿ DNS ಹೆಸರುಗಳು ಯಾವುದೇ ಶೋಧ ಪ್ರೋಟೋಕಾಲ್‌ಗಿಂತ ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದವು, ಮತ್ತು ಪೂರೈಕೆದಾರ ಬದಲಾದರೂ ಉಳಿಯುತ್ತವೆ.
ಒಂದು ಸೈಟ್‌ನಲ್ಲಿ 10.10.0.0/24 ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ 10.20.0.0/24 ತೆಗೆದುಕೊಳ್ಳಿ. ಗೇಟ್‌ವೇ A ಗೆ 10.20.0.0/24 ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಸುರಂಗಕ್ಕೆ ಕಳುಹಿಸುವ ರೂಟ್ ಅಥವಾ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್ ಬೇಕು, ಮತ್ತು ಗೇಟ್‌ವೇ B ಗೆ ಅದರ ಕನ್ನಡಿ ಪ್ರತಿಬಿಂಬ ಬೇಕು. ನಂತರ ಎರಡೂ ಬದಿಯ ಹೋಸ್ಟ್‌ಗಳು ಸಾಮಾನ್ಯ IP ಸಂಪರ್ಕವನ್ನು ಬಳಸುತ್ತವೆ ಮತ್ತು ಸುರಂಗ ಇದೆ ಎಂದು ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ. ಆ ಅಗೋಚರತೆಯೇ ವೈಶಿಷ್ಟ್ಯ, ಮತ್ತು ವೈಫಲ್ಯಗಳು ಸುರಂಗದ ದೋಷಗಳಂತೆ ಅಲ್ಲದೆ ಸಾಮಾನ್ಯ ನೆಟ್‌ವರ್ಕ್ ದೋಷಗಳಂತೆ ಕಾಣುವುದಕ್ಕೂ ಅದೇ ಕಾರಣ.
ನೀತಿ ಆಧಾರಿತ ಮತ್ತು ರೂಟ್ ಆಧಾರಿತ ಒಂದೇ ಸುರಂಗವಲ್ಲ
ನೀತಿ ಆಧಾರಿತ IPsec ನಿಯೋಜನೆಯಲ್ಲಿ, ಸಮಾಲೋಚಿಸಿದ ಟ್ರಾಫಿಕ್ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಯಾವ ಮೂಲ ಮತ್ತು ಗಮ್ಯ ಜೋಡಿಗಳು ಸಂರಕ್ಷಿತವೆಂದು ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ. ಒಂದು ಗೇಟ್‌ವೇಯ ಹಿಂದೆ ಹೊಸ ಉಪಜಾಲಬಂಧ ಕಾಣಿಸಿಕೊಂಡರೆ ಮತ್ತು ಯಾವುದೇ ಸೆಲೆಕ್ಟರ್ ಅದನ್ನು ಆವರಿಸದಿದ್ದರೆ, ಸುರಂಗ ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು ಹೊಸ ಉಪಜಾಲಬಂಧ ಸಾಗಿಸಲ್ಪಡುವುದಿಲ್ಲ. ರೂಟ್ ಆಧಾರಿತ ವಿನ್ಯಾಸದಲ್ಲಿ ಇಂಟರ್‌ಫೇಸ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ನಿರ್ಧರಿಸುತ್ತದೆ, ಇದು ಪೂರ್ವಪ್ರತ್ಯಯ ಸೇರಿಸುವುದನ್ನು ಸುರಂಗದ ಮರುಸಂಧಾನವಲ್ಲದೆ ರೂಟ್ ಬದಲಾವಣೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.
StrongSwan ಎರಡೂ ದೃಶ್ಯಗಳನ್ನು ನೇರವಾಗಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅವನ್ನು ಒಟ್ಟಿಗೆ ಓದುವುದೇ ನೀವು ನಿಜವಾಗಿ ಯಾವ ಮಾದರಿಯನ್ನು ನಿಯೋಜಿಸಿದ್ದೀರಿ ಎಂದು ತಿಳಿಯುವ ದಾರಿ.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'ನಿಮಗೆ ಬೇಕಾದ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟ ಸೆಲೆಕ್ಟರ್ ಪಟ್ಟಿ ಯಾವುದೇ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯದೆ ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ತಪ್ಪು ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ತೋರಿಸುವ ರೂಟ್ ಹಿಂತಿರುಗುವ ದಾರಿಯಲ್ಲಿ ಕನ್ನಡಿ ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಏನನ್ನಾದರೂ ಮರುಸಂಧಾನ ಮಾಡುವ ಮೊದಲು ಎರಡನ್ನೂ ಓದಿ, ಏಕೆಂದರೆ ಕೀ ನವೀಕರಣವು ನೀವು ಎಂದಿಗೂ ಕಾನ್ಫಿಗರ್ ಮಾಡದ ಸೆಲೆಕ್ಟರ್ ಅನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ.
ಸುರಂಗಕ್ಕೆ ಮೊದಲು ವಿಳಾಸಗಳನ್ನು ಯೋಜಿಸಿ
ಅತಿಪಾತಿತ ಶ್ರೇಣಿಗಳು ಕಾನ್ಫಿಗರೇಶನ್‌ನಿಂದ ಸರಿಪಡಿಸಲಾಗದ ವಿನ್ಯಾಸ ದೋಷ. ಎರಡೂ ಸೈಟ್‌ಗಳು 192.168.1.0/24 ಬಳಸಿದರೆ, 192.168.1.50 ಬೇಕಾದ ಹೋಸ್ಟ್‌ಗೆ ಎರಡು ಅಭ್ಯರ್ಥಿಗಳಿದ್ದು ಆಯ್ಕೆ ಮಾಡುವ ದಾರಿಯಿಲ್ಲ. ಸುರಂಗ ದೃಢೀಕರಣಗೊಳ್ಳುತ್ತದೆ, ಭದ್ರತಾ ಸಂಘಟನೆಗಳು ಸ್ಥಾಪಿತವಾಗುತ್ತವೆ, ಮತ್ತು ರೂಟಿಂಗ್ ನಿರ್ಧಾರ ಹೇಗಿದ್ದರೂ ತಪ್ಪಾಗಿರುತ್ತದೆ ಅಥವಾ ಅಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ.
ಮೂರು ಪ್ರಾಮಾಣಿಕ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಆರಿಸಿ: ಒಂದು ಸೈಟ್ ಅನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ, ಗೇಟ್‌ವೇಯಲ್ಲಿ ಅತಿಪಾತಿತ ಶ್ರೇಣಿಯನ್ನು ಅನುವಾದಿಸಿ ಇದರಿಂದ ಪ್ರತಿ ಬದಿಯೂ ವಿಭಿನ್ನ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ನೋಡುತ್ತದೆ, ಅಥವಾ ಆ ಹೋಸ್ಟ್‌ಗಳಿಗೆ ನೇರ ರೂಟಿಂಗ್ ಬಿಟ್ಟು ಸೇವೆಯನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪ್ರಕಟಿಸಿ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ವೆಚ್ಚವಿದೆ, ಮತ್ತು ಎರಡು ವರ್ಷಗಳ ಅವಧಿಯಲ್ಲಿ ಮೊದಲನೆಯದು ಸಾಮಾನ್ಯವಾಗಿ ಅಗ್ಗವಾದದ್ದು. ಸುರಂಗ ಇರುವ ಮೊದಲು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ನಂತರದ ಬದಲಾವಣೆ ಹಳೆಯ ವಿಳಾಸ ಹೊಂದಿರುವ ಪ್ರತಿಯೊಂದು ಸಾಧನವನ್ನೂ ಮುಟ್ಟುತ್ತದೆ.
MTU ಪ್ರಶ್ನೆಯನ್ನೂ ಬೇಗ ಪರಿಹರಿಸಿ. ಸುರಂಗವು ಉಪಯುಕ್ತ ಪೇಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ತುಣುಕುಗೊಳಿಸುವಿಕೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ವಿನ್ಯಾಸವು ಗೇಟ್‌ವೇಗಳಲ್ಲಿ MSS ಅನ್ನು ಸ್ಥಿರಗೊಳಿಸುವ ವಿನ್ಯಾಸಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತದೆ.
ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ನೀತಿ ಸುರಂಗದ ಹೊರಗೆ ಇರುತ್ತವೆ
ಗೇಟ್‌ವೇ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು LAN ಇಂಟರ್‌ಫೇಸ್ ನಡುವೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಸಿದ್ಧವಾಗಿರಬೇಕು, ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳಿಗೂ ಸೇವೆಯನ್ನು ಅನುಮತಿಸುವ ನೀತಿ ಬೇಕು. Linux ನಲ್ಲಿ ಇವು ಎರಡು ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಜೊತೆಗೆ ಫಾರ್ವರ್ಡ್ ಆದ ಹರಿವು ಸರ್ವಥಾ ಅನುಮತಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTಸ್ವೀಕರಿಸುವ ಹೋಸ್ಟ್ ಮೂರನೇ ಪದರವನ್ನು ಸೇರಿಸುತ್ತದೆ: ಅದರ ಸ್ವಂತ ಫೈರ್‌ವಾಲ್ ಇನ್ನೂ ದೂರದ ಉಪಜಾಲಬಂಧದಿಂದ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. ತನ್ನ ಸ್ಥಳೀಯ /24 ಅನ್ನು ಮಾತ್ರ ಅನುಮತಿಸುವ ಫೈಲ್ ಸರ್ವರ್ 10.20.0.7 ರಿಂದ ಫಾರ್ವರ್ಡ್ ಆದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ, ಸುರಂಗ ಎಷ್ಟೇ ಆರೋಗ್ಯಕರವಾಗಿ ಕಂಡರೂ, ಮತ್ತು ಆ ತಿರಸ್ಕಾರವನ್ನು ರೂಟಿಂಗ್ ವೈಫಲ್ಯ ಎಂದು ಓದುವುದು ಸುಲಭ.
ಗೇಟ್‌ವೇಯಿಂದ ಅಲ್ಲ, ಹೋಸ್ಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ
ಗೇಟ್‌ವೇ ಸ್ವತಃ ಕಳುಹಿಸುವ ping ಫಾರ್ವರ್ಡ್ ಆದ ಬಳಕೆದಾರ ಟ್ರಾಫಿಕ್‌ಗಿಂತ ಬೇರೆ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಬೇರೆ ನೀತಿಯನ್ನು ಅನುಸರಿಸಬಹುದು. ಇದು ಅದನ್ನು ದುರ್ಬಲ ಪರೀಕ್ಷೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ದಾರಿತಪ್ಪಿಸುವಂತೆಯೂ ಮಾಡುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾದಾಗ ಅದು ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡುವಾಗ ಅದು ವಿಫಲವಾಗುತ್ತದೆ.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullನಿಜವಾದ ಹೋಸ್ಟ್, ನಿಜವಾದ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ನಿಜವಾದ ಪ್ರೋಟೋಕಾಲ್ ಬಳಸಿ. ನಂತರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಿ, ಏಕೆಂದರೆ ಹಿಂತಿರುಗುವ ರೂಟ್ ಇಲ್ಲದೆ ಕೆಲಸ ಮಾಡುವ ಮುಂದಿನ ದಿಕ್ಕು ತಡೆಯಲಾದ ಸೇವೆಗೆ ಸಮಾನವಾಗಿ ಕಾಣುವ ಸಮಯ ಮೀರಿಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ನೀವು ಉತ್ತರಿಸುತ್ತಿರುವ ಪ್ರಶ್ನೆಯ ಪ್ರಕಾರ ವಿನ್ಯಾಸವನ್ನು ಆರಿಸಿ: ನೀವು ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದೀರಾ ಅಥವಾ ಸಾಧನಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿದ್ದೀರಾ? ಉಳಿದ ಎಲ್ಲವೂ, ಯಾವ ಪೂರೈಕೆದಾರರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೀರಿ ಎಂಬುದೂ ಸೇರಿದಂತೆ, ಆ ಉತ್ತರದಿಂದ ಬರುತ್ತದೆ.