VPN ರೌಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಾಗುವಾಗ STUN ಪ್ರತಿಕ್ರಿಯೆ ಏನನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ
ರೌಟರ್‌ನ ಟನೆಲ್ ವಿಳಾಸ ಬ್ರೌಸರ್‌ನ ಸ್ಥಳೀಯ ವಿಳಾಸವಲ್ಲ. ಪ್ರತಿಫಲಕ ಏನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಓದುವ ಮೊದಲು ಪ್ರತಿ ವಿನಂತಿ ಹೇಗೆ ಮಾರ್ಗ ಮತ್ತು ಅನುವಾದಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಅನುಸರಿಸಿ.
ಟನೆಲ್ ರೌಟರ್‌ನಲ್ಲಿ ಇರುವಾಗ, ಬ್ರೌಸರ್ ಚಲಾಯಿಸುವ ಯಂತ್ರಕ್ಕೆ ಯಾವುದೇ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಇರುವುದಿಲ್ಲ. ಆ ಯಂತ್ರದ ಸ್ಥಳೀಯ ವಿಳಾಸಗಳನ್ನು ಕೇಳಿದರೆ ಖಾಸಗಿ LAN ವಿಳಾಸ ಮತ್ತು ಲೂಪ್‌ಬ್ಯಾಕ್ ಸಿಗುತ್ತದೆ, VPN ವಿಳಾಸವನ್ನು ಹೋಲುವ ಯಾವುದೂ ಇಲ್ಲ. ಆದರೂ ಆಚೆ ಬದಿಯ STUN ಸರ್ವರ್ ಮಾರ್ಗದ ಬಗ್ಗೆ ಇನ್ನೂ ಅರ್ಥಪೂರ್ಣವಾದದ್ದನ್ನು ವರದಿ ಮಾಡಬಹುದು, ಮತ್ತು ಅದು ಏನನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂಬುದು ಆ ನಿರ್ದಿಷ್ಟ ವಿನಂತಿ ಹೇಗೆ ಮಾರ್ಗಗೊಂಡಿತು ಮತ್ತು ಅನುವಾದಗೊಂಡಿತು ಎಂಬುದರ ಮೇಲೆ ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿತವಾಗಿದೆ.
ಇದು ನಿಧಾನವಾಗುವುದಕ್ಕೆ ಅರ್ಹವಾದ ಭಾಗ. “ಬ್ರೌಸರ್ VPN ವಿಳಾಸದ ಮಾಲೀಕರಲ್ಲ” ಎಂಬುದು ಇಂಟರ್ಫೇಸ್‌ಗಳ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಫಲಿತ ವಿಳಾಸವು ಅನುವಾದದ ಮೂಲಕ ಹಾದುಹೋಗುವ ಮಾರ್ಗದ ಬಗ್ಗೆ ಉತ್ತರವಾಗಿದೆ. ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಸಾಕ್ಷ್ಯವು ಬೆಂಬಲಿಸದ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ಬಗ್ಗೆ ಆತ್ಮವಿಶ್ವಾಸದ ತೀರ್ಮಾನಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಎರಡು ಸಾಧನಗಳು, ಇಂಟರ್ಫೇಸ್‌ಗಳ ಎರಡು ಗುಂಪುಗಳು
ರೌಟರ್ ಆಧಾರಿತ ಸಂರಚನೆಯಲ್ಲಿ ಟನೆಲ್ ರೌಟರ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು LAN ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯ ಸಂಚಾರವನ್ನು ತನ್ನ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನ ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿ ಚಿಕ್ಕದಾಗಿಯೇ ಇರುತ್ತದೆ: ಒಂದು ಖಾಸಗಿ ವಿಳಾಸ, ಬೇರೆ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಇನ್ನೊಂದು, ಮತ್ತು ಲೂಪ್‌ಬ್ಯಾಕ್. ಅಪಾಯವು ಅವುಗಳಲ್ಲಿ ಒಂದು ಆಕಸ್ಮಿಕವಾಗಿ ಟನೆಲ್ ವಿಳಾಸವಾಗಿರುವುದಲ್ಲ; ಅಪಾಯವು ನೀವು ಆಯ್ಕೆ ಮಾಡದ ಮಾರ್ಗದಿಂದ ವಿನಂತಿ ಹೊರಹೋಗುವುದು.
ಯಾವ ಇಂಟರ್ಫೇಸ್‌ಗಳಿವೆ ಎಂದು ಕೇಳುವ ಬದಲು, ಕ್ಲೈಂಟ್‌ಗೆ ನಿರ್ದಿಷ್ಟ ಗಮ್ಯಸ್ಥಾನ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಕೇಳಿ. ಉತ್ತರವು ಗೇಟ್‌ವೇ ಮತ್ತು ಕರ್ನಲ್ ಬಳಸುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಇದು ಯಾವುದೇ ವಿಳಾಸ ಪಟ್ಟಿಗಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಪೂರ್ಣವಾಗಿದೆ.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsದಾಖಲೆ ಶ್ರೇಣಿಗಳು ಪರೀಕ್ಷಾ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಒಳ್ಳೆಯವು ಏಕೆಂದರೆ ಅವು ಎಂದಿಗೂ ನಿಜವಾದ ಸೇವೆಗೆ ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಹೇಳುವುದನ್ನು ರೌಟರ್ ಹೇಳುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ನೀತಿ ಮಾರ್ಗದರ್ಶನ, ವಿಭಜಿತ ಟನೆಲ್ ನಿಯಮ ಅಥವಾ ಎರಡನೇ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವು ನೀವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದ ಏನನ್ನೋ ಮಾಡುತ್ತಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಿ.
Binding ಪ್ರತಿಕ್ರಿಯೆ ಏನು ಹೇಳಬಹುದು
RFC 8489 Binding ವಿನಂತಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಸರ್ವರ್ ಆ ವಿನಂತಿಗೆ ಗಮನಿಸಿದ ಮೂಲ ಸಾಗಣೆ ವಿಳಾಸವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಇದು ಒಂದು ಕ್ಷಣದಲ್ಲಿ ಒಂದು ಪಂಚಕದ ಬಗ್ಗೆ ಹೇಳಿಕೆ, ಕ್ಲೈಂಟ್‌ನ ಇಂಟರ್ಫೇಸ್‌ಗಳ ಜನಗಣತಿ ಅಲ್ಲ. ಆದ್ದರಿಂದ ಆಸಕ್ತಿದಾಯಕ ಎಲ್ಲವೂ ಕ್ಲೈಂಟ್ ಮತ್ತು ವೀಕ್ಷಣಾ ಬಿಂದುವಿನ ನಡುವೆ ನಡೆಯುತ್ತದೆ.
ಆ ಕೊರಕಲನ್ನು ಮಾರ್ಗದರ್ಶನ ಮತ್ತು ಅನುವಾದ ತುಂಬುತ್ತದೆ. ಹೊರಹೋಗುವ ಸಂಚಾರದ ಮೇಲೆ ಮೂಲ NAT ಮಾಡುವ ರೌಟರ್ ಕ್ಲೈಂಟ್‌ನ ಖಾಸಗಿ ಮೂಲವನ್ನು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿನ ತನ್ನ ಸ್ವಂತ ವಿಳಾಸದಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ. ಆ ಇಂಟರ್ಫೇಸ್ ಟನೆಲ್ ಆಗಿದ್ದರೆ, ಪ್ರತಿಫಲಕ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಟನೆಲ್‌ನಿಂದ ಹೊರಗಿಡಲ್ಪಟ್ಟಿದ್ದರೆ, ಪ್ರತಿಫಲಕ WAN ಅನುವಾದ ಉತ್ಪಾದಿಸಿದ್ದನ್ನು ನೋಡುತ್ತದೆ. ಅದೇ ಕ್ಲೈಂಟ್, ಅದೇ ಪ್ರತಿಫಲಕ, ಬೇರೆ ಉತ್ತರ.
ಒಂದೇ ರೀತಿ ಕಾಣುವ ಮತ್ತು ಇಲ್ಲದ ಮೂರು ಸಂದರ್ಭಗಳು
ಉಪಯುಕ್ತ ವ್ಯತ್ಯಾಸ ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ನಡುವೆ ಅಲ್ಲ, ಬದಲಿಗೆ ಯಾವ ಜಾರಿ ಬಿಂದು ಪ್ಯಾಕೆಟ್ ನಿರ್ವಹಿಸಿತು ಎಂಬುದು. ರೌಟರ್‌ನ ಸ್ವಂತ ಕೋಷ್ಟಕಗಳನ್ನು ತೆರೆದಿಟ್ಟು ಸಂದರ್ಭಗಳನ್ನು ನೋಡಿ, ಏಕೆಂದರೆ ಒಂದೇ ಬ್ರೌಸರ್ ನೀವು ಬರೆಯಲು ಮರೆತ ನಿಯಮದ ಪ್ರಕಾರ ಮೂರನ್ನೂ ಉತ್ಪಾದಿಸಬಹುದು.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
ಎರಡನೇ ಸಂದರ್ಭ ಮಾತ್ರ ಕೆಲವು ಸಂಚಾರ ಎಂದಿಗೂ ನೇರವಾಗಿ ಹೊರಹೋಗಬಾರದು ಎಂಬ ಷರತ್ತನ್ನು ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಹಾಗೂ ಮೂರನೆಯವು ಮಾತ್ರ ಟನೆಲ್ ಬದಿಯ ಗುರುತನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ. ಮೂರು ಸಾಲುಗಳಲ್ಲಿ ಯಾವುದೂ ನಿರ್ದಿಷ್ಟ ಪೂರೈಕೆದಾರರ ನಡವಳಿಕೆಯ ಬಗ್ಗೆ ಪ್ರತಿಪಾದನೆ ಅಲ್ಲ: ಖಾಸಗಿ ಪ್ರತಿಫಲಕವನ್ನು ತಲುಪಲು ಸಾಧ್ಯವೇ ಎಂಬುದು ಮಾರ್ಗದರ್ಶನ, ಇನ್ನೊಂದು ಬದಿಯ ಅನುಮತಿಸಿದ IP ವಿಳಾಸಗಳು ಮತ್ತು ಎರಡೂ ತುದಿಗಳ ಫೈರ್‌ವಾಲ್ ನೀತಿಯನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಅದೇ ಪೂರೈಕೆದಾರರಲ್ಲಿ ಖಾತೆ ಹೊಂದಿರುವುದು ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಮಾರ್ಗಗೊಂಡ ವಿನಂತಿ ಯಾವುದೂ ಅನುವಾದಿಸದಿದ್ದರೆ ಕ್ಲೈಂಟ್‌ನ LAN ಮೂಲವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು ಎಂಬುದನ್ನೂ ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಒಳ್ಳೆಯದು, ಆದ್ದರಿಂದ ಮೂಲ ಕ್ಷೇತ್ರವನ್ನು ಟೋಪಾಲಜಿ ರೇಖಾಚಿತ್ರದಿಂದ ಊಹಿಸದೆ ಪತ್ತೆ ಮಾಡಬೇಕು.
ಸಂಗ್ರಹಿಸುವುದು ಆಯ್ಕೆ ಮಾಡುವುದಲ್ಲ
WebRTC ಪ್ರಯತ್ನಿಸಲು ಅಭ್ಯರ್ಥಿ ವಿಳಾಸಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ, ಮತ್ತು ರೋಗನಿರ್ಣಯ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣುವ ಅಭ್ಯರ್ಥಿ ಎಂದಿಗೂ ಮಾಧ್ಯಮ ಸಾಗಿಸದಿರಬಹುದು. ಪಟ್ಟಿಯನ್ನು “ಇದನ್ನೇ ಇನ್ನೊಂದು ಬದಿ ಕಲಿತದ್ದು” ಎಂದು ಓದುವುದು ಸಾಕ್ಷ್ಯವನ್ನು ಅತಿಯಾಗಿ ಅಂದಾಜಿಸುತ್ತದೆ. ಆಯ್ಕೆಯಾದ ಜೋಡಿಯೇ ಸೆಷನ್ ಅನ್ನು ನಿಜವಾಗಿ ಸಾಗಿಸಿದ್ದು, ಮತ್ತು ಅದು ಬೇರೆ ಕ್ಷೇತ್ರದಲ್ಲಿದೆ.
HTTPS ನಿರ್ಗಮನ ಪರಿಶೀಲಕ ಇನ್ನೊಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಆ ವಿನಂತಿಗೆ ವೆಬ್ ಸರ್ವರ್ ನೋಡಿದ ಮೂಲ ವಿಳಾಸ. ಇದು ಉಪಯುಕ್ತ ಅಡ್ಡ-ಪರಿಶೀಲನೆ ಏಕೆಂದರೆ ಇದು UDP ಪ್ರತಿಫಲಕಕ್ಕಿಂತ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಗಮ್ಯಸ್ಥಾನ ಬಳಸುತ್ತದೆ, ಮತ್ತು ಎರಡರ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ದೋಷದ ಬದಲು ಮಾರ್ಗ ನಿಯಮದ ಕಡೆ ಸೂಚಿಸುತ್ತದೆ.
ನೀತಿ ನಿರ್ಧರಿಸಿ, ನಂತರ ಉತ್ತರ ಓದಿ
ಪರೀಕ್ಷೆಯ ಮೊದಲು ಉದ್ದೇಶ ಬರೆಯಿರಿ: ಯಾವ ಸಂಚಾರ ಟನೆಲ್ ಬಳಸಬೇಕು, ಯಾವುದು ನೇರವಾಗಿ ಹೊರಹೋಗಬಹುದು, ಯಾವ ವಿಳಾಸ ಕುಟುಂಬಗಳು ವ್ಯಾಪ್ತಿಯಲ್ಲಿವೆ, ಮತ್ತು ಟನೆಲ್ ಇಳಿದಾಗ ಏನಾಗಬೇಕು. ಆ ಆಧಾರ ರೇಖೆ ಇಲ್ಲದೆ ಪ್ರತಿ ವೀಕ್ಷಣೆಯೂ ಅಸ್ಪಷ್ಟ, ಏಕೆಂದರೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅನುಮತಿಸಿದ ಮಾರ್ಗದಿಂದ ಸೋರಿಕೆಯನ್ನು ಬೇರ್ಪಡಿಸಲಾಗುವುದಿಲ್ಲ.
ನಂತರ ಒಂದೊಂದೇ ಪ್ರಶ್ನೆ ಕೇಳಿ. ಈ ಗಮ್ಯಸ್ಥಾನ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಈ ಪ್ರತಿಫಲಕ ಯಾವ ವಿಳಾಸ ವರದಿ ಮಾಡುತ್ತದೆ. ಸೆಷನ್ ಯಾವ ಅಭ್ಯರ್ಥಿ ಜೋಡಿ ಆಯ್ಕೆ ಮಾಡಿತು. ಉತ್ತರಗಳನ್ನು ನೀತಿಯ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ದಿನಾಂಕ ಹಾಕಿ, ಏಕೆಂದರೆ ಫರ್ಮ್‌ವೇರ್ ನವೀಕರಣವು ಕಳೆದ ವರ್ಷದ ತೀರ್ಮಾನವನ್ನು ಮೌನವಾಗಿ ಅನೂರ್ಜಿತಗೊಳಿಸುವ ರೀತಿಯಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯನ್ನು ಬದಲಿಸಬಹುದು.
ರೌಟರ್ ಇನ್ನೂ ಬಲವಾದ ಜಾರಿ ಬಿಂದುವಾಗಿದೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ತನ್ನನ್ನೇ ಮರುಸಂರಚಿಸದೆ ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾಗದ ಸಂಚಾರವನ್ನು ಅದು ನೋಡುತ್ತದೆ. ಪ್ರತಿ ಅನ್ವಯಿಕ ಪ್ರೋಟೋಕಾಲ್‌ನ ಪ್ರತಿ ಕ್ಷೇತ್ರವೂ ಏನನ್ನೂ ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ ಎಂಬ ಭರವಸೆ ಇದಲ್ಲ, ಮತ್ತು ಅನುಮತಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದ ಮಾರ್ಗಗಳನ್ನು ಬರೆದಿಡುವುದಕ್ಕೆ ಇದು ಪರ್ಯಾಯವೂ ಅಲ್ಲ.