ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಇಲ್ಲದೆ NAT ಹಿಂದಿನ ಕೆಲಸದ ನಿಲ್ದಾಣವನ್ನು ತಲುಪುವುದು
ಒಳಬರುವ ಪೋರ್ಟ್ ಇಲ್ಲದ ಕೆಲಸದ ನಿಲ್ದಾಣವೂ ಹಬ್, ರಿಲೇ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಬ್ರೋಕರ್ ಮೂಲಕ ತಲುಪಬಹುದು. ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಪ್ರತಿ ವಿನ್ಯಾಸ ಏನನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಹೋಲಿಸಿ.
ವಾಹಕ NAT ಮತ್ತು ಲಾಕ್ ಆದ ಕಚೇರಿ ರೌಟರ್ ಹಿಂದಿನ ಎರಡು ತುದಿ ಬಿಂದುಗಳು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಯಾವುದೇ ಒಳಬರುವ ಪೋರ್ಟ್ ಬಿಡುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಹೇಗಿದ್ದರೂ ಒಂದನ್ನು ಕೇಳುವುದೇ. ಉತ್ತಮ ಪ್ರಶ್ನೆ ಎಂದರೆ ಯಾವ ಬದಿ ಹೊರಗೆ ಡಯಲ್ ಮಾಡಬಹುದು ಮತ್ತು ಯಾವ ತಲುಪಬಹುದಾದ ಸೇವೆಗೆ ಸಂಚಾರ ಸಾಗಿಸಲು ಅನುಮತಿ ಇದೆ. ನಾಲ್ಕು ವಿನ್ಯಾಸಗಳು ಈ ಪ್ರಶ್ನೆಗೆ ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಮಾರ್ಗ ತಡೆಯಾದಾಗ ಅವು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ಅವುಗಳ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವುದು ಪ್ರೋಟೋಕಾಲ್ ಹೆಸರುಗಳ ಹೋಲಿಕೆಯಲ್ಲ, ಖಾತರಿಗಳ ಹೋಲಿಕೆ.
ನಾಲ್ಕು ವಿನ್ಯಾಸಗಳು, ನಾಲ್ಕು ಬೇರೆ ಭರವಸೆಗಳು
ಕೆಳಗಿನ ಕೋಷ್ಟಕ ಸಂಕ್ಷಿಪ್ತ ಆವೃತ್ತಿ. ಮಧ್ಯದ ಕಾಲಂ ಅನ್ನು ನೀವು ಪರೀಕ್ಷಿಸಬಹುದಾದ ಭರವಸೆ ಎಂದು, ಮತ್ತು ಬಲ ಕಾಲಂ ಅನ್ನು ಯಾರೂ ನೀಡದ ಭರವಸೆ ಎಂದು ಓದಿ.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
ಯಾವ ಸಾಲು ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದು ಆದ್ಯತೆಯ ಮೇಲಲ್ಲ, ಕೆಲಸದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಒಂದು ದೂರದ ಡೆಸ್ಕ್ಟಾಪ್ ಅಧಿವೇಶನ, ಒಂದು ಆಡಳಿತಾತ್ಮಕ ಶೆಲ್ ಮತ್ತು ಇಡೀ ಖಾಸಗಿ ಉಪಜಾಲಕ್ಕೆ ಪ್ರವೇಶ — ಇವು ಒಂದೇ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಅಗತ್ಯವಿಲ್ಲದ ಮೂರು ಅಗತ್ಯಗಳು, ಅವು ಆಕಸ್ಮಿಕವಾಗಿ ಒಂದೇ ಯಂತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸಿದರೂ ಸಹ.
ಹಬ್ ಯಾರು ಹೊರಗೆ ಡಯಲ್ ಮಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಏನು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನಲ್ಲ
ಮಾರ್ಗೀಕೃತ ಹಬ್ ವಿನ್ಯಾಸದಲ್ಲಿ ದೂರದ ಲ್ಯಾಪ್ಟಾಪ್ ಮತ್ತು ಕೆಲಸದ ನಿಲ್ದಾಣ, ಅಥವಾ ಅದರ ಮುಂದಿನ ಸೈಟ್ ಗೇಟ್ವೇ, ಪ್ರತಿಯೊಂದೂ ಎರಡೂ ತಲುಪಬಹುದಾದ ಸೇವೆಗೆ ಹೊರಹೋಗುವ ಸುರಂಗ ತೆರೆಯುತ್ತವೆ. ಕೆಲಸದ ನಿಲ್ದಾಣದ ರೌಟರ್ನಲ್ಲಿ ಯಾವುದೂ ಕೇಳದ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಇದೇ ಕಾರಣಕ್ಕೆ ಈ ವಿನ್ಯಾಸ NAT ಮೀರಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಸೈಟ್ಗೆ ಸ್ಥಿರ ವಿಳಾಸ ಇಲ್ಲದಿದ್ದರೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಂತರ ಹಬ್ ತನ್ನ ಸ್ವಂತ ನೀತಿಯ ಪ್ರಕಾರ ಎರಡು ಒಳಗಿನ ವಿಳಾಸಗಳ ನಡುವೆ ಸಂಚಾರವನ್ನು ಮಾರ್ಗೀಕರಿಸುತ್ತದೆ.
ಬೆಲೆ ಎಂದರೆ ಹಬ್ ಇರಬೇಕು, ಎರಡೂ ಕಡೆಯಿಂದ ತಲುಪಬಹುದಾಗಿರಬೇಕು ಮತ್ತು ಯಾರಾದರೂ ಅದನ್ನು ನಿರ್ವಹಿಸಬೇಕು. ಹೊರಹೋಗುವ ಫಿಲ್ಟರಿಂಗ್ ಸಾಗಣೆಯನ್ನು ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ಅದನ್ನು ತಡೆಯುವ ಜಾಲ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ ವಿನ್ಯಾಸವನ್ನು ಸೋಲಿಸುತ್ತದೆ.
ಸೂಕ್ಷ್ಮ ಭಾಗ ಎಂದರೆ ತಲುಪುವಿಕೆ ಮತ್ತು ಅಧಿಕಾರ ನೀಡುವಿಕೆ ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು. ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೆ ಹೋಗುವ ಮಾರ್ಗವು ಕೆಲಸದ ನಿಲ್ದಾಣದ ಯಾವ ಸೇವೆಯನ್ನು ಗುರುತು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಸುರಂಗಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಫೈರ್ವಾಲ್ ನಿಯಮವು ಖಾತೆ ಒಳಗೆ ಹೋಗಬಹುದೇ ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ಸಂರಚಿಸಿ, ಎರಡನ್ನೂ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಅಧಿಕಾರದ ನಿರ್ಧಾರವನ್ನು ಮಾರ್ಗೀಕರಣ ಕೋಷ್ಟಕದ ಬಳಿಯಲ್ಲ, ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿರುವ ವ್ಯವಸ್ಥೆಯ ಬಳಿ ಇರಿಸಿ.
ಎರಡೂ ಸ್ಟಾಕ್ಗಳು ಅದನ್ನು ಜಾರಿಗೊಳಿಸಿದಾಗ ಮಾತ್ರ ಟ್ರಾವರ್ಸಲ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ
ಸಮಾನ ತುದಿಗಳ ನಡುವಿನ ಟ್ರಾವರ್ಸಲ್ ನಿರ್ದಿಷ್ಟ ವ್ಯವಸ್ಥೆಯ ಸಾಮರ್ಥ್ಯ, VPN ಸುಧಾರಿಸುವ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. Interactive Connectivity Establishment ಹಲವು ಅಭ್ಯರ್ಥಿ ವಿಳಾಸಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಒಂದು ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಜೋಡಿಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ: ಸ್ಥಳೀಯ ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಹೋಸ್ಟ್ ಅಭ್ಯರ್ಥಿಗಳು, NAT ಬಹಿರಂಗಪಡಿಸುವುದರಿಂದ ನಿರ್ಮಿಸಿದ ಸರ್ವರ್-ಪ್ರತಿಬಿಂಬಿತ ಅಭ್ಯರ್ಥಿಗಳು, ಮತ್ತು ರಿಲೇಯಲ್ಲಿ ಹಂಚಿದ ರಿಲೇ ಅಭ್ಯರ್ಥಿಗಳು. ಖಾಸಗಿ ವಿಳಾಸ ಒಂದೇ ಮಾರ್ಗವಲ್ಲ, ಏಕೆಂದರೆ ಇನ್ನೊಂದು ಬದಿ ಅಲ್ಲಿಗೆ ಮಾರ್ಗೀಕರಿಸಲಾರದು.
ರಿಲೇ ಪ್ರಕರಣವನ್ನು ತಳ್ಳಿಹಾಕುವ ಮೊದಲು ಅರ್ಥ ಮಾಡಿಕೊಳ್ಳುವುದು ಯೋಗ್ಯ. RFC 8656 TURN ಅನ್ನು ಕ್ಲೈಂಟ್ ಸರ್ವರ್ನಿಂದ ರಿಲೇ ಮಾಡಿದ ಸಾಗಣೆ ವಿಳಾಸವನ್ನು ಕೇಳುವ ಮತ್ತು ಸರ್ವರ್ ಆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಅದರ ಸಮಾನ ತುದಿಗಳ ನಡುವೆ ಸಂಚಾರ ರವಾನಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ರಿಲೇ ಡೇಟಾವನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಇದು ಕೇವಲ ತುದಿಗಳು ಭೇಟಿಯಾಗಲು ಸಹಾಯ ಮಾಡುವ ಡೈರೆಕ್ಟರಿಯಿಂದ ಮೂಲಭೂತವಾಗಿ ಭಿನ್ನ. ರಿಲೇ ವಿಳಾಸವನ್ನು ಇನ್ನೊಂದು ಬದಿಯೊಂದಿಗೆ ವಿನಿಮಯ ಮಾಡುವುದು ಅಪ್ಲಿಕೇಶನ್ ಮಾಡಬೇಕಾದ ಸಮನ್ವಯ ಹಂತ.
ನೀವು ಭರವಸೆ ನೀಡಲಾಗದ್ದು ನೇರ ಮಾರ್ಗ. ಸಮ್ಮಿತೀಯ NAT ಮತ್ತು ಕೆಲವು ಎಂಟರ್ಪ್ರೈಸ್ ಫೈರ್ವಾಲ್ಗಳು ರಂಧ್ರ ಕೊರೆಯುವಿಕೆಯನ್ನು ಸೋಲಿಸುತ್ತವೆ, ಮತ್ತು ಹಾಗಾದಾಗ ವ್ಯವಸ್ಥೆ ರಿಲೇಗೆ ಹಿಂತಿರುಗುತ್ತದೆ ಅಥವಾ ವಿಫಲವಾಗುತ್ತದೆ. ಎರಡು ಅನುವಾದಿತ ತುದಿಗಳು ಎಂದಿಗೂ ಮಾತನಾಡಲಾರವು ಎಂದೂ ನೀವು ತೀರ್ಮಾನಿಸಲಾಗದು; ರಿಲೇ ಬ್ಯಾಕಪ್ ಇರುವ ಬೆಂಬಲಿತ ಸ್ಟಾಕ್ ಇರುವುದೇ ಅವು ಹೆಚ್ಚಾಗಿ ಮಾತನಾಡಬಲ್ಲವು ಎಂಬ ಕಾರಣಕ್ಕೆ. ಲಭ್ಯತೆ ಹೆಚ್ಚು ಮುಖ್ಯವೋ ನೇರತೆ ಹೆಚ್ಚು ಮುಖ್ಯವೋ ಎಂದು ನಿರ್ಧರಿಸಿ, ನಂತರ ಅನುಕೂಲಕರ ಸಂದರ್ಭವನ್ನು ಊಹಿಸುವ ಬದಲು ನಿಯೋಜನೆ ನಿಜವಾಗಿ ಯಾವ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
ಬ್ರೋಕರ್ ಜಾಲಕ್ಕಿಂತ ಸಂಕುಚಿತ
ಅಗತ್ಯ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಆದಾಗ, ಅಪ್ಲಿಕೇಶನ್ ಬ್ರೋಕರ್ ಅಥವಾ ಕೆಲಸದ ನಿಲ್ದಾಣ ಆರಂಭಿಸಿದ ಹಿಮ್ಮುಖ ಸಂಪರ್ಕವು ಚಿಕ್ಕ ಉತ್ತರವಾಗಬಹುದು. ಕೆಲಸದ ನಿಲ್ದಾಣ ಬ್ರೋಕರ್ಗೆ ಹೊರಗೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ, ಬ್ರೋಕರ್ ದೂರದ ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಅಪ್ಲಿಕೇಶನ್ ಅಧಿವೇಶನ ಮಾತ್ರ ಸಾಗಿಸಲ್ಪಡುತ್ತದೆ. ಕೆಲಸದ ನಿಲ್ದಾಣದ ಉಪಜಾಲಕ್ಕೆ ಯಾವುದೇ ಮಾರ್ಗ ಸೃಷ್ಟಿಯಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ದೂರದ ಅಧಿವೇಶನದ ಒಳನುಗ್ಗುವಿಕೆ ಪಕ್ಕದ ಪ್ರತಿ ಸಾಧನಕ್ಕೂ ಮಾರ್ಗವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ.
ಈ ಸಂಕುಚಿತತೆಗೆ ಬೆಲೆ ಇದೆ: ಪ್ರತಿ ಹೆಚ್ಚುವರಿ ಅಪ್ಲಿಕೇಶನ್ಗೆ ತನ್ನದೇ ಸಂಯೋಜನೆ ಬೇಕು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಳೀಯ ಜಾಲದ ಬಗ್ಗೆ ಊಹಿಸುವ ಯಾವುದೇ ವಿಷಯ, ಉದಾಹರಣೆಗೆ ಹತ್ತಿರದ ಸರ್ವರ್ನಲ್ಲಿ ತೆರೆಯುವ ಫೈಲ್ ಹಂಚಿಕೆ, ತಲುಪಲಾಗದಿರಬಹುದು. ಬ್ರೋಕರ್ಗಳು ನೀತಿ ಮತ್ತು ದಾಖಲೆಯನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ, ಅದು ಆ ಸ್ಥಳವೇ ಅಡಚಣೆಯಾಗುವವರೆಗೆ ಉಪಯುಕ್ತ.
ನಂಬಿಕೆಯ ಗಡಿಗಳನ್ನು ಹೋಲಿಸಿ, ನಂತರ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ
ಸುರಂಗಗಳನ್ನು ಮುಗಿಸುವ ಹಬ್ ತಾನು ಮಾರ್ಗೀಕರಿಸುವ ಸಂಚಾರವನ್ನು ಓದಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ತುದಿಯಿಂದ ತುದಿಗೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದಾಗ ರಿಲೇ ಸ್ವತಂತ್ರವಾಗಿ ಸಂರಕ್ಷಿತ ವಿನಿಮಯವನ್ನು ಸಾಗಿಸಬಹುದು, ಮತ್ತು ಬ್ರೋಕರ್ ಸಾಮಾನ್ಯವಾಗಿ ತಾನು ಪ್ರಸ್ತುತಪಡಿಸುವ ಅಧಿವೇಶನವನ್ನು ಮುಗಿಸುತ್ತದೆ. ಎರಡೂ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿರುವುದರಿಂದ ಎರಡು ವಿನ್ಯಾಸ ಸಮಾನ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ರಕ್ಷಣೆ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ.
ನಂತರ ಕೆಲಸದ ನಿಲ್ದಾಣ ಹೊರಕ್ಕೆ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ತಲುಪುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮೇಲಿನ ಪ್ರತಿ ವಿನ್ಯಾಸ ಅದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಇದನ್ನು ಕೆಲಸದ ನಿಲ್ದಾಣದಲ್ಲಿ ಚಲಾಯಿಸಿ, ನೀವು ಬಳಸಲು ಉದ್ದೇಶಿಸಿರುವ ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಬದಲಿಸಿ.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comಅನುಮತಿಸಿದ ಗುರುತಿನ ಅಡಿಯಲ್ಲಿ ಉದ್ದೇಶಿತ ದೂರದ ಕಾರ್ಯಾಚರಣೆ ಯಶಸ್ವಿಯಾದ ನಂತರ, ಅನುಮತಿಸದ ಗುರುತು ನಿರಾಕರಿಸಲ್ಪಟ್ಟ ನಂತರ, ಮತ್ತು ನೇರ ಅಥವಾ ರಿಲೇ ಮಾರ್ಗ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗಿನ ವರ್ತನೆ ತಿಳಿದು ದಾಖಲಾಗಿದ್ದ ನಂತರವೇ ವಿನ್ಯಾಸವನ್ನು ಸ್ವೀಕರಿಸಿ. ಮರುಸಂಪರ್ಕ ಮತ್ತು ಕೆಲಸದ ನಿಲ್ದಾಣದ ಸಾಮಾನ್ಯ ಆರಂಭಿಕ ಸಂದರ್ಭವನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಕಚೇರಿಯಲ್ಲಿ LAN ಮೂಲಕ ಆರಂಭವಾದ ಅಧಿವೇಶನ ದೂರದ ಪ್ರವೇಶ ಅವಲಂಬಿಸಿರುವ ಯಾವುದನ್ನೂ ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ.