VPN ನ ಮೀಸಲು ವಿಳಾಸಕ್ಕೆ ನಿಜವಾಗಿ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ?

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

ವಿಳಾಸದ ಹಿಂದಿನ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗ

ಸಹಭಾಗಿ ತನಗೆ ನೀಡಿದ ವಿಳಾಸಕ್ಕೆ IKE ಕಳುಹಿಸುತ್ತದೆ, UDP 500 ನಲ್ಲಿ ಅಥವಾ NAT ಜಾರಿ ಇದ್ದಾಗ UDP 4500 ನಲ್ಲಿ. ಮಾರ್ಗದಲ್ಲಿ ಆ ವಿಳಾಸವನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ಸಾಧನವು ಡೇಟಾಗ್ರಾಮ್ ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಸ್ವೀಕರಿಸಿ ಉತ್ತರಿಸುತ್ತದೆ, ಅಥವಾ ಅದನ್ನು ಬೇರೆಡೆಗೆ ರವಾನಿಸುತ್ತದೆ. ಇವು ಕೇವಲ ಎರಡು ಸಾಧ್ಯತೆಗಳು, ಮತ್ತು ಈ ಲೇಖನದಲ್ಲಿನ ಉಳಿದೆಲ್ಲವೂ ಇವುಗಳಲ್ಲಿ ಯಾವುದು ನಿಜ ಎಂಬುದರಿಂದ ಹುಟ್ಟುತ್ತದೆ.

ಸ್ಥಳೀಯವಾಗಿ ಸ್ವೀಕರಿಸುವುದು ಎಂದರೆ ಆ ಸಾಧನದಲ್ಲಿ ಆ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಸಾಕೆಟ್ ಇದೆ ಎಂದು. ರವಾನಿಸುವುದು ಎಂದರೆ ಡೇಟಾಗ್ರಾಮ್ ಮರುಬರೆಯಲ್ಪಟ್ಟು ಇನ್ನೊಂದು ಅಂತ್ಯಬಿಂದುವಿಗೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ, ಆಗ ಆ ಸಾಕೆಟ್ ಅದರ ಬಳಿ ಇರುತ್ತದೆ. UDP 500 ಗೆ ಅನುಮತಿ ನೀಡುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮವು ಈ ಎರಡರಲ್ಲಿ ಯಾವುದು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಿಮಗೆ ಹೇಳುವುದಿಲ್ಲ.

ಏನನ್ನೂ ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ದಾಖಲೆಯನ್ನು ಬರೆಯಿರಿ: ಸಹಭಾಗಿಗಳು ಸಂಪರ್ಕಿಸುವ ವಿಳಾಸ, ಮೇಲ್ಮಟ್ಟದ ಜಾಲವು ಅದನ್ನು ಹೇಗೆ ತಲುಪಿಸುತ್ತದೆ, ಅದನ್ನು ಸ್ವೀಕರಿಸುವ ಸ್ಥಳೀಯ ಇಂಟರ್‌ಫೇಸ್ ಅಥವಾ ತಾರ್ಕಿಕ ಅಂತ್ಯಬಿಂದು, ಮತ್ತು IKE ಗೆ ಉತ್ತರಿಸುವ ಪ್ರಕ್ರಿಯೆ. ನಾಲ್ಕು ಸಾಲುಗಳು, ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನೂ ಪರಿಶೀಲಿಸಬಹುದು. ಅವುಗಳಲ್ಲಿ ಒಂದು ಅಜ್ಞಾತವಾಗಿದ್ದರೆ, ಆ ಅಜ್ಞಾತವೇ ವಿನ್ಯಾಸದ ಕೆಲಸ, ನಂತರ ಬಗೆಹರಿಸಬೇಕಾದ ಅನುಷ್ಠಾನ ವಿವರವಲ್ಲ. ಬದಲಾವಣೆ ವಿನಂತಿ ಅನುಮೋದನೆಯ ನಂತರ ಅವನ್ನು ತುಂಬುವುದೇ ತಪ್ಪು ಸಾಧನಕ್ಕೆ ಭಾಷಾಂತರ ನಿಯಮ ಸೇರುವ ದಾರಿ.

ಮಾದರಿ A: ಗೇಟ್‌ವೇ ವಿಳಾಸವನ್ನು ಹೊಂದಿದೆ

ಮೊದಲ ಮಾದರಿಯಲ್ಲಿ ಗೇಟ್‌ವೇ ಸ್ವತಃ ವಿಳಾಸವನ್ನು ಹೊಂದಿದೆ, ಅಂದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ದ್ವಿತೀಯ ವಿಳಾಸವಾಗಿ, ಮೀಸಲು ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ವಿಳಾಸವಾಗಿ, ಅಥವಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸುರಂಗದ ಅಂತ್ಯಬಿಂದುವಾಗಿ ಬೆಂಬಲಿಸುವ loopback ಆಗಿ. ಇವು ಮೂರು ವಿಭಿನ್ನ ವೈಶಿಷ್ಟ್ಯಗಳು ಮೂರು ವಿಭಿನ್ನ ಸಂರಚನಾ ಮಾರ್ಗಗಳೊಂದಿಗೆ, ಮತ್ತು ಒಂದನ್ನು ಬೆಂಬಲಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಉಳಿದವನ್ನು ಬೆಂಬಲಿಸದೇ ಇರಬಹುದು.

ಅದರ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಮತ್ತು ಆವೃತ್ತಿ ನಿಖರವಾಗಿ ಈ ಜೋಡಣೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ರೂಟ್ ಮಾಡಿದ ಬ್ಲಾಕ್, ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿನ ಹೆಚ್ಚುವರಿ ವಿಳಾಸ ಮತ್ತು loopback ಅಂತ್ಯಬಿಂದು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದವಲ್ಲ, ಮತ್ತು ಒಂದು ಆವೃತ್ತಿಯ ದಾಖಲೆ ಮುಂದಿನದೂ ಹಾಗೆಯೇ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಭರವಸೆ ನೀಡುವುದಿಲ್ಲ.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

ಸ್ಥಳವಿಜ್ಞಾನದ ಬೇರೆಡೆ ಈಗಾಗಲೇ ಇರುವ ಉಪಜಾಲಕ್ಕೆ ಎರಡನೇ ಇಂಟರ್‌ಫೇಸ್ ಇಡಬೇಡಿ ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ. ಅತಿಕ್ರಮಿಸುವ ಇಂಟರ್‌ಫೇಸ್ ಉಪಜಾಲಗಳು ಅಸ್ಪಷ್ಟ ಮೂಲ ಆಯ್ಕೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ ಮತ್ತು ಅನೇಕ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಸಂರಚನೆಗೆ ಸಂಪೂರ್ಣ ನಿರಾಕರಣೆ ಉಂಟುಮಾಡುತ್ತವೆ.

ಮಾದರಿ B: ಮೇಲ್ಮಟ್ಟದ ಸಾಧನವು ಅದನ್ನು ಭಾಷಾಂತರಿಸುತ್ತದೆ

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

ಅದು ಏನಲ್ಲವೋ, ಅಂದರೆ ಮೇಲ್ಮಟ್ಟದ ಸಾಧನವು ಸ್ಥಳೀಯ VPN ಸಾಕೆಟ್ ಪಡೆದಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಭಾಷಾಂತರವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರವಾನಿಸುತ್ತದೆ; ಅದು ಮೇಲಿನ ಪೆಟ್ಟಿಗೆಯನ್ನು IKE ಉತ್ತರದಾತನನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ. ಮೇಲ್ಮಟ್ಟದ ನಿಯಮ ತೆಗೆದುಹಾಕಲ್ಪಟ್ಟರೆ ಅಥವಾ ಅದರ ಹಿಂತಿರುಗು ಮಾರ್ಗ ಮುರಿದರೆ, ಗೇಟ್‌ವೇ ಆರೋಗ್ಯವಾಗಿದ್ದರೂ ಮತ್ತು ಅದರ ಸ್ವಂತ ಶ್ರೋತೃಗಳು ಅಕ್ಷತವಾಗಿದ್ದರೂ VPN ನಿಲ್ಲುತ್ತದೆ.

ಎರಡೂ ವಿಳಾಸಗಳನ್ನು ದಾಖಲಿಸಿ: ಸಹಭಾಗಿಗಳು ಸಂಪರ್ಕಿಸುವುದು ಮತ್ತು ಗೇಟ್‌ವೇ ನಿಜವಾಗಿ ನೋಡುವುದು. ನಂತರ ಸಾಗಣೆ ಮತ್ತು ಹಿಂತಿರುಗು ಮಾರ್ಗವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ UDP 500 ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಹೊರತು ಸುತ್ತಿಕೊಂಡ ESP ಗೆ ಇಲ್ಲದ ಭಾಷಾಂತರವು ಸಂಪರ್ಕಗೊಂಡು ನಂತರ ಸಂಚಾರವನ್ನು ಸಾಗಿಸಲು ವಿಫಲವಾಗುತ್ತದೆ, ಇದು ನಂತರ ದೋಷನಿವಾರಣೆ ಮಾಡಲು ಗೊಂದಲದ ವೈಫಲ್ಯ.

ಗುರುತು ಹೊರಗಿನ ವಿಳಾಸವಲ್ಲ

IPsec ಸುರಂಗದ ಅಂತ್ಯಬಿಂದುವನ್ನು ಅದು ರಕ್ಷಿಸುವ ಸಂಚಾರದಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪ ಆ ನಿರ್ಧಾರಗಳನ್ನು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಇಡುತ್ತದೆ. ಸಹಭಾಗಿಗಳು ಸಂಪರ್ಕಿಸುವ ವಿಳಾಸವನ್ನು ಬದಲಾಯಿಸುವುದರಿಂದ ಯಾವ ಆಂತರಿಕ ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಗೆ ಅನುಮತಿ ಇದೆ, ಯಾವ ಮಾರ್ಗಗಳು ಸ್ಥಾಪಿತವಾಗುತ್ತವೆ ಅಥವಾ ಅಧಿವೇಶನವು ಯಾವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಲುಪಬಹುದು ಎಂಬುದು ತಾನಾಗಿಯೇ ಬದಲಾಗುವುದಿಲ್ಲ.

ದೃಢೀಕೃತ ಗುರುತು ಮತ್ತೆ ಪ್ರತ್ಯೇಕ. IKEv2 ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುವ ಅಗತ್ಯವಿಲ್ಲದ ಗುರುತಿನ ಪೇಲೋಡ್ ಮತ್ತು ದೃಢೀಕರಣ ವಿನಿಮಯವನ್ನು ಒಯ್ಯುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಭಾಷಾಂತರಿತ ವಿನ್ಯಾಸವೂ ಸರಿಯಾಗಿ ದೃಢೀಕರಿಸಬಲ್ಲದು.

ಆ ಸ್ವಾತಂತ್ರ್ಯ ಉಪಯುಕ್ತ ಹಾಗೂ ಬೋನು ಕೂಡ. ಒಂದು ಸಾಮಾನ್ಯ ಶ್ರೋತೃವಿಗೆ ಪರಿಹರಿಸುವ ಎರಡು DNS ಹೆಸರುಗಳು ಬೇರೆ ಬೇರೆ VPN ಬ್ಯಾಕೆಂಡ್‌ಗಳನ್ನು ಆಯ್ಕೆಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಒಂದು ಗುರುತನ್ನು ಹೆಸರಿಸುವ ಪ್ರಮಾಣಪತ್ರವು ಇನ್ನೊಂದನ್ನು ನಿರೀಕ್ಷಿಸುವ ಸಹಭಾಗಿಯನ್ನು ಸಂತೃಪ್ತಿಪಡಿಸುವುದಿಲ್ಲ. ಕೇವಲ ವಿಳಾಸವೇ ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಸಹಭಾಗಿ ಏನನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಒಂದು ಸಂಪರ್ಕವನ್ನು ಗಮನಿಸಿ ವಿನ್ಯಾಸವನ್ನು ಸ್ವೀಕರಿಸಿ

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

ಋಣಾತ್ಮಕ ಸಂದರ್ಭವನ್ನೂ ಇಟ್ಟುಕೊಳ್ಳಿ: ಸ್ವೀಕರಿಸಬಾರದ ಸಹಭಾಗಿ, ಅಥವಾ ತಲುಪಬಾರದ ಆಂತರಿಕ ಪೂರ್ವಪ್ರತ್ಯಯ, ಬದಲಾವಣೆಯ ನಂತರ ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟದ್ದು. ಆರಂಭದಲ್ಲಿ ಬರೆದ ದಾಖಲೆಯೇ ವಿನ್ಯಾಸವನ್ನು ನೆನಪಿನಿಂದ ಮತ್ತೆ ಕಟ್ಟದೆ ಆ ಪರೀಕ್ಷೆಯನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

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