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

ವಿರುದ್ಧ ತುದಿಗಳನ್ನು ವಿವರಿಸುವ ಎರಡು ಸಂಖ್ಯೆಗಳು

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

ನಡುವಿನ ರೌಟರ್ ಆ ಮೂಲವನ್ನು ತನ್ನದೇ 'NAT' ಮ್ಯಾಪಿಂಗ್‌ಗೆ ಮತ್ತೆ ಬರೆಯಬಹುದು. ಆದ್ದರಿಂದ ಸರ್ವರ್‌ನಲ್ಲಿ ಕಾಣುವ ಸಂಖ್ಯೆಗೆ ಲ್ಯಾಪ್‌ಟಾಪ್ ಆಯ್ಕೆ ಮಾಡಿದ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಹೆಚ್ಚಾಗಿ ಯಾವುದೇ ಸಂಬಂಧವಿರುವುದಿಲ್ಲ.

ಹೊರಹೋಗುವಾಗ ಮೂಲ ಸಂಖ್ಯೆ ಎಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ

ಒಂದು ಕಲ್ಪಿತ IPv4 ಉದಾಹರಣೆ ತೆಗೆದುಕೊಳ್ಳಿ: ಅನುವಾದ ಮಾಡುವ ರೌಟರ್‌ನ ಹಿಂದೆ ಒಬ್ಬ ಕ್ಲೈಂಟ್, ಒಂದು 'UDP' ಕೇಳುಗವಿರುವ ಸರ್ವರ್, ಮತ್ತು ಎರಡನ್ನೂ ದಾಟುವ ಒಂದೇ ಡೇಟಾಗ್ರಾಮ್. ಕೋಷ್ಟಕವು ಮೂರು ವೀಕ್ಷಣಾ ಬಿಂದುಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಮರುಪ್ರಸಾರ ಮಾಡುವ ಬದಲು ಪ್ರತಿ ತುದಿಯನ್ನು ಮತ್ತು ಅದಕ್ಕೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

EndpointWhat stays fixedWhat changes on reconnectWho owns it
Server listenerThe service port and the address the profile namesNothing; the listener does not follow the clientThe server operator
Client socketThe destination it dialsThe local source port, chosen per socketThe client, or its operating system
Translated sourceUsually the public address of the routerThe port, and sometimes the address after a network switchThe NAT device or the upstream carrier

ಗಮ್ಯಸ್ಥಾನ ಪ್ರತಿ ಸಾಲಿನಲ್ಲೂ ಸ್ಥಿರವಾಗಿದೆ, ಮತ್ತು ಬದಲಾಗುವುದು ಮೂಲದ ಗುರುತು ಮಾತ್ರ. UDP NAT ಅಗತ್ಯಗಳು ಒಳಗಿನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಹೊರಗಿನ ಮ್ಯಾಪಿಂಗ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ, ಮತ್ತು ಅದೇ ಎರಡನೇ ಮತ್ತು ಮೂರನೇ ಸಾಲಿನ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ರೌಟರ್ ಕ್ಲೈಂಟ್‌ನ ಮೂಲ ಪೋರ್ಟ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು ಅಥವಾ ಇನ್ನೊಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು; ಉಳಿಸಿಕೊಳ್ಳುವುದು ಅನ್ವಯವು ಊಹಿಸಬೇಕಾದ ವಿಷಯವಲ್ಲ.

ಮೂರು ತುದಿಗಳನ್ನು ಹೋಸ್ಟ್‌ಗಳಿಂದಲೇ ಓದಿ

ಕೆಳಗಿನ ಪಟ್ಟಿಗಳು ಮೂರು ವಿಭಿನ್ನ ಯಂತ್ರಗಳಿಂದ ಬಂದಿವೆ ಮತ್ತು ಒಟ್ಟಾಗಿ ಇಡೀ ಸಂಭಾಷಣೆಯನ್ನು ತೋರಿಸುತ್ತವೆ. ಮೊದಲನೆಯದನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ, ಎರಡನೆಯದನ್ನು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ, ಮೂರನೆಯದನ್ನು ಮ್ಯಾಪಿಂಗ್ ಇರುವಲ್ಲಿ ಚಲಾಯಿಸಿ. ಒಂದು ಲಾಗ್ ಸಾಲು ಎಂದಿಗೂ ಮೂರನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ.

ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194

ಮೊದಲ ಪಟ್ಟಿ ಸರ್ವರ್ ಸೇವಾ ಪೋರ್ಟ್‌ಗೆ ಬದ್ಧವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಹೊಂದಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಕ್ಲೈಂಟ್‌ನ ಸ್ಥಳೀಯ ಸಾಕೆಟ್ ಮತ್ತು ಅದು ಡಯಲ್ ಮಾಡಿದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತೋರಿಸುತ್ತದೆ. ಮೂರನೆಯದು ರೌಟರ್ ರಚಿಸಿದ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅನುವಾದಿತ ಮೂಲ ಕಾಣಿಸುವ ಏಕೈಕ ಸ್ಥಳ ಅದೇ. ಅವನ್ನು ಆ ಕ್ರಮದಲ್ಲಿ ಓದಿ, ಎರಡು ಸಂಖ್ಯೆಗಳು ವಿರೋಧಾಭಾಸವಾಗಿ ಕಾಣುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತವೆ.

ಮರುಸಂಪರ್ಕ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ, ಏನನ್ನು ಇಲ್ಲ

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

ಸಮುದಾಯದ OpenVPN ಕ್ಲೈಂಟ್‌ಗಳು ಈ ನಡವಳಿಕೆಯನ್ನು nobind ಮೂಲಕ ಪಡೆಯುತ್ತವೆ, ಇದು ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸ್ಥಳೀಯ ಪೋರ್ಟ್ ಆಯ್ಕೆ ಮಾಡಲು ಬಿಡುತ್ತದೆ; ದೂರದ ಪೋರ್ಟ್ ಇನ್ನೂ ಪ್ರೊಫೈಲ್‌ನಿಂದ ಬರುತ್ತದೆ. ಸ್ಪಷ್ಟವಾಗಿ ಬಂಧಿಸುವುದು ಉದ್ದೇಶಪೂರ್ವಕ ಆಯ್ಕೆ, ಪ್ರೋಟೋಕಾಲ್ ಕಡ್ಡಾಯವಲ್ಲ. ಸರ್ವರ್ ಒಂದು ತುದಿಯನ್ನು ನೀಡುತ್ತಲೇ ಇರುತ್ತದೆ, ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮ ಸ್ಥಳೀಯ ಗುರುತುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ.

ದಾಖಲೆಯಲ್ಲಿ ಪದರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಲೇಬಲ್ ಮಾಡಿ

ಸುರಂಗದ ಒಳಗೆ ತನ್ನದೇ ಪೋರ್ಟ್‌ಗಳಿರುವ ಎರಡನೇ ಸಂಭಾಷಣೆ ಇದೆ. ಸುರಂಗ ಒಯ್ಯುವ HTTPS ವಿನಂತಿಯ ಗಮ್ಯಸ್ಥಾನ TCP 443, ಆದರೆ ಹೊರಗಿನ ಗೂಢಲಿಪೀಕೃತ ಸಂಪರ್ಕ UDP 1194 ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊರಗಿನ ಮೂಲ ಪೋರ್ಟ್ ಬದಲಿಸಿದರೂ ಒಳಗಿನ ಸೇವೆಯಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.

ಹೊರ ಪದರದಲ್ಲೂ ಪ್ರೋಟೋಕಾಲ್ ಮುಖ್ಯ. UDP 1194 ಮತ್ತು TCP 1194 ಬೇರೆ ಬೇರೆ ತುದಿಗಳು, ಮತ್ತು 'TCP' ಕೇಳುಗ ಸಂಖ್ಯೆ ಹೊಂದಿಕೆಯಾದ ಕಾರಣಕ್ಕೆ ಎಂದಿಗೂ UDP ಡೇಟಾಗ್ರಾಮ್ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ನಿಯೋಜನೆಯನ್ನು ದಾಖಲಿಸುವಾಗ ಸರ್ವರ್ ಕೇಳುಗ, ಕ್ಲೈಂಟ್ ಸಾಕೆಟ್ ಮತ್ತು ಅನುವಾದಿತ ಮೂಲವನ್ನು ಮೂರು ಬೇರೆ ವಿಷಯಗಳಾಗಿ ಲೇಬಲ್ ಮಾಡಿ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸಾರಿಗೆಯನ್ನು ಸೇರಿಸಿ.

ನಂತರ ನೀತಿ ಪಾತ್ರಗಳನ್ನು ಅನುಸರಿಸಲಿ. ಸರ್ವರ್ ಉದ್ದೇಶಿತ ಸಾರಿಗೆಯನ್ನು ತನ್ನ ಕೇಳುಗದಲ್ಲಿ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಇನ್ನೂ ಸಹಚರನನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ; ಕ್ಲೈಂಟ್‌ನ ಫೈರ್‌ವಾಲ್ ಒಳಬರುವ ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸದೆ ತನ್ನ ಹೊರಹೋಗುವ ವಿನಿಮಯಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಸ್ಥಿತಿರಹಿತ ಫಿಲ್ಟರ್‌ಗೆ ಮರಳು ದಿಕ್ಕನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಬೇಕು, ಮತ್ತು ಅಚ್ಚುಕಟ್ಟಾದ ರೇಖಾಚಿತ್ರಗಳಾಚೆಗೂ ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯವಾಗಲು ಇದೇ ಪ್ರಾಯೋಗಿಕ ಕಾರಣ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು