ಒಂದು OpenVPN ಪೋರ್ಟ್, ಮೂರು ಸೇವೆಗಳು: ಒಳ ಪೋರ್ಟ್ಗಳು ಏಕೆ ಮುಖ್ಯ

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

ಹೊರಗಿನ ಹರಿವು ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಮರೆಮಾಡುತ್ತದೆ

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

ಆದ್ದರಿಂದ WAN ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಒಂದು ಸಂಭಾಷಣೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಮೂರನ್ನು ಅಲ್ಲ. ಒಳ ಪೋರ್ಟ್ಗಳು ಡಿಕ್ಯಾಪ್ಸುಲೇಷನ್ ನಂತರವೇ ಕಾಣಿಸುತ್ತವೆ. ಅದಕ್ಕೇ ಒಂದೇ ಫೈರ್ವಾಲ್ ಕಿಂಡಿಯು SSH, HTTPS ಮತ್ತು DNS ಅನ್ನು ಒಟ್ಟಿಗೆ ಸಾಗಿಸಬಲ್ಲದು.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP ದಾಖಲೆ ಮಾರ್ಗನಿರ್ದೇಶಿತ TUN ಸಾಧನವು ಕರ್ನಲ್ ಮತ್ತು ಬಳಕೆದಾರ-ಸ್ಥಳ ಪ್ರಕ್ರಿಯೆಯ ನಡುವೆ IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಹಾಯಿಸುವ ಹಸ್ತಾಂತರವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈ ಹಸ್ತಾಂತರವೇ ಒಳ ಶೀರ್ಷಿಕೆಯನ್ನು ಗೇಟ್ವೇಯ ಮಾರ್ಗನಿರ್ದೇಶನ ಮತ್ತು ಫೈರ್ವಾಲ್ ಸಂಕೇತಕ್ಕೆ ಗೋಚರವಾಗಿಸುತ್ತದೆ. ಯಾವ ಸೇವೆಗಳಿಗೆ ಅನುಮತಿ ಇದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಹೊರ ಪೋರ್ಟ್ ಏಕೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ ಎಂಬುದನ್ನೂ ಅದು ವಿವರಿಸುತ್ತದೆ.

NAT ಫಾರ್ವರ್ಡ್ ಶ್ರೋತೃವಿನದು, ಅಪ್ಲಿಕೇಶನ್ಗಳದ್ದಲ್ಲ

IPv4 NAT ಹಿಂದಿನ ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿದ ಗೇಟ್ವೇಗೆ ಒಂದು ಒಳಬರುವ ಅನುವಾದ ಬೇಕು: ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ VPN ಶ್ರೋತೃಕ್ಕೆ ಮ್ಯಾಪ್ ಆಗುತ್ತವೆ. ಸುರಂಗ ಬಳಕೆದಾರರು ಅವುಗಳನ್ನು ತಲುಪುತ್ತಾರೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಮಾತ್ರ SSH, HTTPS ಅಥವಾ DNS ಗೆ ಯಾವುದೇ ನಿಯಮ ಬೇಕಿಲ್ಲ. ಆ ಪೋರ್ಟ್ಗಳನ್ನು ಪ್ರಕಟಿಸಿದರೆ ಸುರಂಗ ಈಗಾಗಲೇ ರಕ್ಷಿಸುವ ಸೇವೆಗಳು ಬಹಿರಂಗವಾಗುತ್ತವೆ. ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವು ಶ್ರೋತೃವಿನ ತಲುಪುವಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಒಳಗಿನ ಯಾವುದಕ್ಕೂ ಅನುಮತಿಯನ್ನಲ್ಲ.

ವಿರುದ್ಧವೂ ನಿಜ. ಸುರಂಗದ ಪೋರ್ಟ್ ತೆರೆದರೆ ಬೇರೆ ಏನೂ ಬಹಿರಂಗವಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸುರಂಗದ ಮೂಲಕ ಮಾತ್ರ ತಲುಪಬಹುದಾದ ಸೇವೆ ತನ್ನ ಸಾರ್ವಜನಿಕ ಮೇಲ್ಮೈಯನ್ನು ಮುಚ್ಚಿದ್ದೇ ಇರುತ್ತದೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯೇ ಸಾಮಾನ್ಯವಾಗಿ ಸೇವೆಯನ್ನು ಆರಂಭದಿಂದಲೂ ಖಾಸಗಿಯಾಗಿ ಇಡುವ ಕಾರಣ.

ಪ್ರವೇಶವನ್ನು ನಿಜವಾಗಿ ನಿರ್ಧರಿಸುವುದು ಒಳ ನೀತಿಯಲ್ಲೇ

ಗೂಢಲಿಪೀಕರಣ ಮಾರ್ಗವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ; ಅದು ಗಮ್ಯಕ್ಕೆ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಮಾರ್ಗಗಳು ಯಾವ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ, ಗೇಟ್ವೇಯ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಪ್ಯಾಕೆಟ್ಗಳು ಅದನ್ನು ಬಿಡಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಗಮ್ಯದ ಫೈರ್ವಾಲ್ ಹಾಗೂ ಲಾಗಿನ್ ಸೇವೆ ಉತ್ತರಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. DNS ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಸಂದರ್ಭ: ಪ್ರಶ್ನೆಗಳನ್ನು ಸಾಗಿಸುವುದರಿಂದ ರಿಜಾಲ್ವರ್ ಅವುಗಳನ್ನು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಪೂಲ್ನಿಂದ ಸ್ವೀಕರಿಸುವಂತಾಗುವುದಿಲ್ಲ. ಪ್ರತಿ ಪದರವೂ ಸ್ವತಂತ್ರವಾಗಿ ಇಲ್ಲ ಎನ್ನಬಲ್ಲದು.

ಸುರಂಗದ ಮೂಲಕ ಪ್ರತಿ ಸೇವೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಯಶಸ್ವಿ ಹುಡುಕಾಟ ವೆಬ್ ಪೋರ್ಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಯಶಸ್ವಿ ವೆಬ್ ವಿನಂತಿ SSH ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

ಸುರಂಗ ಚಾಲನೆಯಲ್ಲಿದ್ದು ಎಲ್ಲವೂ ವಿಫಲವಾದಾಗ, ಮೊದಲು ಕ್ಲೈಂಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಓದಿ. ಒಂದು ಸೇವೆ ವಿಫಲವಾಗಿ ಉಳಿದವು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ದೋಷ ಆ ಗಮ್ಯದಲ್ಲೇ ಇರುತ್ತದೆ. ಆ ಎರಡು ಅವಲೋಕನಗಳು ಬೇರೆ ಬೇರೆ ಜವಾಬ್ದಾರರನ್ನು ಸೂಚಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

WireGuard ಅದೇ ರೇಖೆಯನ್ನು ಎಳೆಯುತ್ತದೆ

WireGuard ತನ್ನ ಹೊರ ಶ್ರೋತೃವನ್ನು ListenPort ಎಂದು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಒಳ ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ತನಗೆ ಬೇಕಾದ ಯಾವುದೇ ಸೇವಾ ಪೋರ್ಟ್ ಬಳಸುತ್ತದೆ. AllowedIPs ಮಾರ್ಗನಿರ್ದೇಶಿತ ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಗುಂಪು, ಅನುಮತಿಸಿದ ಸೇವಾ ಪೋರ್ಟ್ಗಳ ಪಟ್ಟಿಯಲ್ಲ. ಅದನ್ನು ಪೋರ್ಟ್ ಅನುಮತಿ ಪಟ್ಟಿ ಎಂದು ಓದಿದರೆ ಸುರಂಗ ಮಾಡುವುದಕ್ಕೆ ಹೊಂದದ ನಿಯಮಗಳು ಹುಟ್ಟುತ್ತವೆ. ಹೆಸರಿಸುವಿಕೆ ಬೇರೆ; ಪದರೀಕರಣವಲ್ಲ.

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

ಸಾಮಾನ್ಯ ರೂಪ ಒಂದು ಹೊರ ಸಾಗಣೆ, ಅನೇಕ ಒಳ ಸಂಭಾಷಣೆಗಳೊಂದಿಗೆ. ಹಲವು ಹೊರ ವಿನಿಮಯಗಳು ಅಥವಾ ಬೇರೆ IP ಪ್ರೋಟೋಕಾಲ್ ಬೇಕಾದ ಉತ್ಪನ್ನಗಳು, ಒಂದೇ-ಸಾರ್ವಜನಿಕ-ಪೋರ್ಟ್ ಮಾದರಿ ಈ ವಿನ್ಯಾಸವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಪ್ರತಿ VPN ಅನ್ನಲ್ಲ ಎಂದು ನೆನಪಿಸುತ್ತವೆ.