VPN ಹಿಂದೆ IoT ಸಂವೇದಕಗಳನ್ನು ಇಡುವ ಮೊದಲು ಮೂರು ವಿಳಾಸ ನಿರ್ಣಯಗಳು
ಮೂರು ವಿಳಾಸಗಳು ಮೂರು ಕೆಲಸ ಮಾಡುತ್ತವೆ: ಸಾರ್ವಜನಿಕ ಹಬ್, ದೃಢೀಕೃತ ಸೈಟ್ ಪೀರ್ ಮತ್ತು ಸಂವೇದಕದ ಖಾಸಗಿ ವಿಳಾಸ. ಯಾವುದನ್ನೂ ಸಾರ್ವಜನಿಕವಾಗಿ ಹಂಚುವ ಮೊದಲು ಪ್ರತಿಯೊಂದನ್ನು ಯೋಜಿಸಿ.
ಪ್ರತಿ IoT ಮೂಲಕ VPN ಯೋಜನೆಯಲ್ಲಿ ಮೂರು ವಿಳಾಸಗಳು ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅವು ಒಂದೇ ರೀತಿಯ ನಿರ್ಣಯವಲ್ಲ. ಒಂದು ದೂರದ ಆಪರೇಟರ್ ಟನೆಲ್ನ ಅಂತ್ಯ ಬಿಂದುವನ್ನು ಹೇಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತಾನೆ ಎಂಬುದು, ಇನ್ನೊಂದು ಸೈಟ್ ತಾನೇ ಸೈಟ್ ಎಂದು ಹೇಗೆ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಎಂಬುದು, ಮತ್ತು ಮೂರನೆಯದು ಸಂವೇದಕದ ಸೇವೆ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಕೇಳುತ್ತದೆ ಎಂಬುದು. ಅದೇ ಕ್ರಮದಲ್ಲಿ ಉತ್ತರಿಸಿ, ವಿನ್ಯಾಸ ಬಹುತೇಕ ತಾನಾಗಿಯೇ ಹೊರಬರುತ್ತದೆ. ಒಂದೇ ಪ್ರಶ್ನೆಯಾಗಿ ಉತ್ತರಿಸಿದರೆ, ಎಂದೂ ಅಗತ್ಯವಿಲ್ಲದ ಸಾಧನಗಳಿಗೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಗಳನ್ನು ಹಂಚುವ ಸ್ಥಿತಿಗೆ ಬರುತ್ತೀರಿ. ಹೊರಹೋಗುವ ಸೈಟ್ ಟನೆಲ್ನ ಹಿಂದೆ ಇರುವ ಸಂವೇದಕ ಸಂವೇದಕದ ಕಡೆ ತೋರಿಸುವ ಯಾವುದೇ ಒಳಬರುವ ನಿಯಮವಿಲ್ಲದೆ ಅಧಿಕೃತ ಆಪರೇಟರ್ಗೆ ತಲುಪಬಹುದು.
ಯಾರು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಎಂಬುದರಿಂದ ಆರಂಭಿಸಿ
ಯಾರು ಡಯಲ್ ಮಾಡುತ್ತಾರೆ ಎಂಬುದು ಮುಂದಿನ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ನಿರ್ಧರಿಸುತ್ತದೆ. ಸೈಟ್ ಹಬ್ಗೆ ಡಯಲ್ ಮಾಡಿದಾಗ, ಸೈಟ್ಗೆ ಒಳಬರುವ ತಲುಪುವಿಕೆ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಹಬ್ಗೆ ಸೈಟ್ ಪರಿಹರಿಸಬಹುದಾದ ಹೆಸರು ಅಥವಾ ವಿಳಾಸ ಬೇಕು. ಆ ಒಂದೇ ಆಯ್ಕೆ ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ನೀಡುವಿಕೆಯ ಚರ್ಚೆಯ ಬಹುಪಾಲನ್ನು ಅದು ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ತೆಗೆದುಹಾಕುತ್ತದೆ.
ನಂತರ ಮೂರು ಪಾತ್ರಗಳು ಸ್ವಚ್ಛವಾಗಿ ಬೇರ್ಪಡುತ್ತವೆ, ಮತ್ತು ಕೆಳಗಿನ ಕೋಷ್ಟಕ ನಿರ್ಣಯದ ಚಿಕ್ಕ ರೂಪ.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
ಪ್ರತಿ ಸಾಲಿಗೂ ಬೇರೆ ಮಾಲೀಕರಿದ್ದಾರೆ, ಮತ್ತು ಅದೇ ನಿಜವಾದ ಅಂಶ. ಹಬ್ VPN ಸೇವೆ ನಡೆಸುವವರದು, ಸೈಟ್ ಪೀರ್ ಜಾಲ ತಂಡದದು, ಮತ್ತು ಸಂವೇದಕದ ವಿಳಾಸ ಸಾಧನವನ್ನು ಹೊಂದಿರುವವರದು.
ಹಬ್ನ ವಿಳಾಸ ಬೂಟ್ಸ್ಟ್ರಾಪ್, ಗಮ್ಯಸ್ಥಾನವಲ್ಲ
ನಿರ್ವಹಿತ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರು ಹಬ್ಗೆ ಸಾಕು. DNS ದಾಖಲೆ ಅಂತ್ಯ ಬಿಂದು ಸ್ಥಳಾಂತರಗೊಂಡಾಗ ಅದನ್ನು ಅನುಸರಿಸಬಹುದು, ಪ್ರತಿ ಸೈಟ್ ಸಂರಚನೆಯನ್ನು ಕೈಯಿಂದ ಸಂಪಾದಿಸದೆ. DNS ಮಾಡದಿರುವುದು ತಲುಪುವಿಕೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದು ಅಥವಾ ಹಳೆಯ ಉತ್ತರವನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ನವೀಕರಿಸುವುದು, ಮತ್ತು ಇವು ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು ಬೇರೆ ಬೇರೆ ಪರಿಹಾರಗಳೊಂದಿಗೆ.
ಹಬ್ ಇಲ್ಲದೆ ಸೈಟ್ನಿಂದ ಸೈಟ್ಗೆ ಟನೆಲ್ಗಳನ್ನು ನಡೆಸಿದರೆ, ಅದೇ ತರ್ಕ ಬೇರೆ ರೂಪದಲ್ಲಿ ಅನ್ವಯಿಸುತ್ತದೆ: ಒಂದು ಬದಿಗೆ ತಲುಪಬಹುದಾದ ಅಂತ್ಯ ಬಿಂದು ಬೇಕು, ಅಥವಾ ಎರಡೂ ಬದಿಗಳು ಮೂರನೇ ಪಕ್ಷಕ್ಕೆ ಡಯಲ್ ಮಾಡುತ್ತವೆ. ಯಾರಾದರೂ ಆ ವಿಳಾಸ ಮತ್ತು ಅದರ ನವೀಕರಣಗಳನ್ನು ಇನ್ನೂ ಹೊಂದಿರಬೇಕು.
ಸೈಟ್ ಪೀರ್ ಎಂಬುದು ಪೂರ್ವಪ್ರತ್ಯಯ ಸೇರಿಸಿದ ಗುರುತು
ಪೀರ್ ಮೊದಲು ಗುರುತು, ನಂತರ ಪೂರ್ವಪ್ರತ್ಯಯ. WireGuard ಪರಿಭಾಷೆಯಲ್ಲಿ ಪೀರ್ ಕೀ ಜೋಡಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ಹಬ್ನ AllowedIPs ನಮೂದು ಆ ಕೀಯನ್ನು ಸೈಟ್ನ ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೆ ಬಂಧಿಸುತ್ತದೆ. IKEv2 ಪರಿಭಾಷೆಯಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಮೊದಲೇ ಹಂಚಿದ ಕೀ ಸೈಟ್ ಅನ್ನು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಸಂಚಾರ ಆಯ್ಕೆಗಾರರು ಏನನ್ನು ಸಾಗಿಸಬಹುದು ಎಂದು ಹೇಳುತ್ತವೆ. ಒಂದು ಅರ್ಧವನ್ನು ಮಾತ್ರ ಬದಲಿಸಿದರೆ ಏರ್ಪಾಡು ಮುರಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಳಾಸ ಬದಲಾವಣೆಯನ್ನು ಎಂದಿಗೂ ಗುರುತಿನ ಬದಲಾವಣೆ ಎಂದು ಪರಿಗಣಿಸಬಾರದು.
ಕೀ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರದ ಮಾಲೀಕತ್ವವನ್ನು ಹಬ್ ಆಪರೇಟರ್ ಬಳಿ ಅಲ್ಲ, ಸೈಟ್ ಬಳಿ ಇಡಿ, ಪೂರೈಕೆದಾರ ಬದಲಾವಣೆ ಗುರುತಿನ ಬದಲಾವಣೆಯಾಗದಂತೆ.
ಪೂರ್ವಪ್ರತ್ಯಯವು ಜನರು ಯೋಜಿಸಲು ಮರೆಯುವ ಭಾಗ. ಹಬ್ ಸಂವೇದಕದ ಉಪಜಾಲವನ್ನು ಸರಿಯಾದ ಪೀರ್ಗೆ ಜೋಡಿಸಬೇಕು, ಮತ್ತು ಆಪರೇಟರ್ನ ಕ್ಲೈಂಟ್ಗೆ ಅದಕ್ಕೆ ಮಾರ್ಗ ಬೇಕು; ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಮಾತ್ರ ಇರುವ ಮಾರ್ಗ ಸಂಚಾರವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಡುವ ಟನೆಲ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಕೀ ಬೆರಳಚ್ಚಿನ ಪಕ್ಕದಲ್ಲಿ ಸೈಟ್ ದಾಖಲೆಯಲ್ಲಿ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಬರೆಯಿರಿ, ಬದಲಿಸಿದ ಗೇಟ್ವೇ ಗಮನಿಸದೆ ಬೇರೆ ವ್ಯಾಪ್ತಿಯೊಂದಿಗೆ ಮೇಲೇಳದಂತೆ.
ಸಂವೇದಕದ ವಿಳಾಸ ಅನ್ವಯದ್ದು
ಸೈಟ್ ಯೋಜನೆಯಿಂದ ಖಾಸಗಿ ವಿಳಾಸ ಸಾಕು, ಮತ್ತು ಅದಕ್ಕೆ ಬೇಕಾಗಿರುವುದು ಸಾರ್ವಜನಿಕ ತಲುಪುವಿಕೆ ಅಲ್ಲ, ಸ್ಥಿರತೆ: DHCP ಕಾಯ್ದಿರಿಸುವಿಕೆ, ಸ್ಥಿರ ನಿಯೋಜನೆ, ಅಥವಾ ಸೈಟ್ನ ಸ್ವಂತ ವಲಯದಲ್ಲಿ ಹೆಸರು. ಸಾಧನವನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸೈಟ್ ಗೇಟ್ವೇಯಲ್ಲಿ ಅನುವಾದ ಸಕ್ರಮ ಉತ್ತರ, ಅನುವಾದ ದಾಖಲಾಗಿದ್ದು ಹಿಂತಿರುಗುವ ಸಂಚಾರ ಅದನ್ನು ಅನುಸರಿಸುವವರೆಗೆ.
ಇನ್ನೊಂದು ಅಭ್ಯಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯ: ಸಂವೇದಕದ ಹೋಸ್ಟ್ನ ಮುಂದಿನ ಹಾಪ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಹಬ್ ವಿಳಾಸವನ್ನು ಎಂದಿಗೂ ಅಂಟಿಸಬೇಡಿ. VPN ತನ್ನದೇ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಅಂತ್ಯ ಬಿಂದುವಿಗೆ ಸಾಮಾನ್ಯ ಎಥರ್ನೆಟ್ ನೆರೆಹೊರೆ ಎಂಬುದು ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುವ ಸಂರಚನೆಯನ್ನು ಉಂಟುಮಾಡುವ ಕಲ್ಪನೆ.
ಉತ್ತರಗಳೇ ಕೈಬಿಡುವ ಅರ್ಧ. ಸಾಧನವು ತನ್ನ ಉತ್ತರವನ್ನು ಟನೆಲ್ನ ಕಡೆಗೆ ಹಿಂತಿರುಗಿಸಬೇಕು, ಒಂದೋ ಆಪರೇಟರ್ನ ಕ್ಲೈಂಟ್ಗೆ ಮಾರ್ಗದ ಮೂಲಕ ಅಥವಾ ವಿನಂತಿಯನ್ನು ಅನುವಾದಿಸಿದ ಅದೇ ಗೇಟ್ವೇ ಮೂಲಕ. ತಪ್ಪಾದ ಡೀಫಾಲ್ಟ್ ಗೇಟ್ವೇ ಇರುವ ಸಂವೇದಕ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ ಶೂನ್ಯಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಟಿಪ್ಪಣಿಗಳು ಆಗಮನ ಮತ್ತು ಉತ್ತರದ ಮಾರ್ಗನಿರ್ದೇಶನ ಒಂದಲ್ಲ ಎರಡು ಅಗತ್ಯಗಳು ಏಕೆ ಎಂದು ವಿವರಿಸುತ್ತವೆ.
ನಿರ್ಣಯಿಸಿ, ನಂತರ ಮಿತಿ ಬರೆಯಿರಿ
ಯಾರಾದರೂ ಸಂಪರ್ಕಿಸುವ ಮೊದಲು ಪ್ರವೇಶ ಮಿತಿಯನ್ನು ಬರೆಯಿರಿ. ಗೇಟ್ವೇಯನ್ನು IoT ವಿಭಾಗಕ್ಕೆ ಮತ್ತು ಆಪರೇಟರ್ಗೆ ಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ಸೇವೆಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಏಕೆಂದರೆ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಆಕಸ್ಮಿಕವಾಗಿ ಸಾಮಾನ್ಯ ಪ್ರವೇಶವಾಗುತ್ತದೆ. ಓದಲು ಮಾತ್ರ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಸಂರಚನಾ ಅಧಿಕಾರವನ್ನು ಬೇರೆ ಬೇರೆ ಗುರುತುಗಳಿರುವ ಬೇರೆ ಬೇರೆ ಪಾತ್ರಗಳಾಗಿ ಇಡಿ, ಮತ್ತು ಒಪ್ಪಂದ ಮುಗಿದಾಗ ಪ್ರವೇಶ ತೆಗೆಯುವ ವ್ಯಕ್ತಿಯ ಹೆಸರು ಹೇಳಿ.
ಅನುಮೋದನೆ ಜಾಲದ ಮಾಲೀಕರದು, ಮತ್ತು DMZ ನಲ್ಲಿ ಇರುವುದು ಪ್ರವೇಶ ನೀತಿ ಅಲ್ಲ.
ನಿಯೋಜನೆಯ ನಂತರದ ಪರೀಕ್ಷೆ ನೀರಸ ಮತ್ತು ನಿರ್ಣಾಯಕ: ಅನುಮತಿಸಿದ ಪೂರ್ವಪ್ರತ್ಯಯದ ಒಳಗೆ ಒಂದು ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಗೇಟ್ವೇಯಲ್ಲಿ ಕೌಂಟರ್ ಹೆಚ್ಚುತ್ತದೆ, ಮತ್ತು ಪೂರ್ವಪ್ರತ್ಯಯದ ಹೊರಗೆ ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕ ಪ್ರಯತ್ನ ವಿಫಲವಾಗುತ್ತದೆ.