VPN ಕ್ಲೈಂಟ್ಗಾಗಿ NGINX ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ?
ಒಂದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ OpenVPN ಜೊತೆಗೆ NGINX ಏನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ: ಒಳಗಿನ ಟನೆಲ್ ವಿಳಾಸ, ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನ ವಿಳಾಸ ಅಥವಾ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಪೀರ್, ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿ.
ಒಂದೇ ಹೋಸ್ಟ್ನಲ್ಲಿ NGINX ಮತ್ತು OpenVPN ಸಂರಚನೆಯಲ್ಲಿ ಮೂರು ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳು ಕಾಣಿಸುತ್ತವೆ, ವಿನಂತಿ ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಪ್ರತಿ ಮಾರ್ಗಕ್ಕೂ ಒಂದು. ಟನೆಲ್ ವಿಳಾಸವನ್ನು ತಲುಪುವ ಬ್ರೌಸರ್, ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ತಲುಪುವ ಬ್ರೌಸರ್ ಮತ್ತು ಗೇಟ್‌ವೇಯ ಇಂಟರ್ನೆಟ್ ಮಾರ್ಗದಿಂದ ಹೊರಹೋಗುವ ಪ್ರೋಗ್ರಾಂ, ಕೇಳುವ ಸಾಕೆಟ್‌ನಲ್ಲಿ ಎಲ್ಲವೂ ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತವೆ. ಲಾಗ್ ಸಾಲನ್ನು ಅರ್ಥೈಸುವ ಮೊದಲು ನೀವು ಯಾವ ಮಾರ್ಗವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. ನಿರ್ಧಾರವು ಕ್ಲೈಂಟ್ ಬಳಸಿದ ಗಮ್ಯಸ್ಥಾನ, ಹೊರಗಿನ VPN ಅಂತ್ಯಬಿಂದುವಿಗಾಗಿ ಅದು ಹೊಂದಿರುವ ವಿನಾಯಿತಿ, ಮತ್ತು ದಾರಿಯಲ್ಲಿ ಏನಾದರೂ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುವಾದಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಬಳಕೆದಾರರು ಯಾರು ಎಂಬುದರಿಂದ ಅಲ್ಲ, ಗಮ್ಯಸ್ಥಾನದಿಂದ ನಿರ್ಧರಿಸಿ
ವಿನಂತಿ ಕಳುಹಿಸಲಾದ ವಿಳಾಸದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಆ ವಿಳಾಸವೇ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಹೋಸ್ಟ್ನ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ವಿನಂತಿ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಕ್ಲೈಂಟ್ನ ಒಳಗಿನ ವಿಳಾಸವನ್ನು ಮೂಲವಾಗಿ ತೆಗೆದುಕೊಂಡು ಬರುತ್ತದೆ. ಹೋಸ್ಟ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ವಿನಂತಿ ಸಾಮಾನ್ಯವಾಗಿ ಇಂಟರ್ನೆಟ್ನತ್ತ ಮುಖಮಾಡಿದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಕ್ಲೈಂಟ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದೊಂದಿಗೆ ಬರುತ್ತದೆ, ಅದೇ ಲ್ಯಾಪ್‌ಟಾಪ್ನಲ್ಲಿ ಆ ಕ್ಷಣದಲ್ಲಿ ಟನೆಲ್ ಸ್ಥಾಪಿತವಾಗಿದ್ದರೂ ಸಹ. ಆದ್ದರಿಂದ VPN ಪೂಲ್ನಲ್ಲಿ ಸದಸ್ಯತ್ವವು ಪ್ಯಾಕೆಟ್ನ ಮಾರ್ಗದ ಗುಣಲಕ್ಷಣ, ಬಳಕೆದಾರನನ್ನು ಹಿಂಬಾಲಿಸುವ ಗುಣಲಕ್ಷಣವಲ್ಲ.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
ಟನೆಲ್‌ಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ವಿಳಾಸದೊಂದಿಗೆ VPN ಬಳಕೆದಾರ ಲಾಗ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಾಗ ಮೊದಲು ಪರಿಶೀಲಿಸಬೇಕಾದದ್ದು ಈ ಮೂರನೇ ಸಾಲು. ಒಂದೇ ಪ್ರೊಫೈಲ್ನ ಇಬ್ಬರು ಬಳಕೆದಾರರು ವಿಭಿನ್ನ ನಮೂದುಗಳನ್ನು ಏಕೆ ರಚಿಸಬಹುದು ಎಂಬುದನ್ನೂ ಇದು ವಿವರಿಸುತ್ತದೆ: ಅವರ ಸ್ವಂತ ಪ್ರವೇಶ ಜಾಲಗಳು ಬೇರೆ, ಮತ್ತು ಟನೆಲ್ನೊಳಗೆ ಯಾವುದೂ ಅದನ್ನು ಮೇಲೆ ಬರೆಯುವುದಿಲ್ಲ.
ಹೊರಗಿನ ಅಂತ್ಯಬಿಂದು ಎರಡನೇ ಸಾರ್ವಜನಿಕ ಮಾರ್ಗವನ್ನು ಏಕೆ ಸೃಷ್ಟಿಸುತ್ತದೆ
ಕ್ಲೈಂಟ್ ಟನೆಲ್ ಸ್ಥಾಪಿಸಲು ಗೇಟ್‌ವೇಯ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ತಲುಪಬೇಕು, ಆದ್ದರಿಂದ ಆ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವು ಟನೆಲ್ನ ಹೊರಗೆ ಇರಬೇಕು. ಕ್ಲೈಂಟ್ ಎಲ್ಲಾ ಸಂಚಾರವನ್ನು ಒಳಕ್ಕೆ ತಿರುಗಿಸಿದಾಗ, ವಿವೇಕಯುತ ಅನುಷ್ಠಾನವು ಸ್ವತಃ ಅವಲಂಬಿತವಾದ ಟನೆಲ್ ತಪ್ಪಿಸಲು ಸರ್ವರ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಸ್ಪಷ್ಟ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಆ ವಿನಾಯಿತಿ ಸೇವೆಗಳ ವಿಷಯದಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಯಾವುದೇ ವಿನಂತಿ ಅದನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಗೇಟ್‌ವೇಯಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಿದ ಸೈಟ್‌ಗೆ ಬ್ರೌಸರ್ ವಿನಂತಿಯೂ ಸೇರಿದಂತೆ.
ಈ ಕ್ಷೇತ್ರದ ಹೆಚ್ಚಿನ ಗೊಂದಲದ ವರದಿಗಳ ಹಿಂದಿನ ಕಾರ್ಯವಿಧಾನ ಇದು, ಮತ್ತು ಇದು ಸರ್ವರ್‌ಗಿಂತ ಕ್ಲೈಂಟ್ ಅನುಷ್ಠಾನವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಆದ್ದರಿಂದ ಒಂದೇ ರೀತಿಯ ಪ್ರೊಫೈಲ್ ಇರುವ ಇಬ್ಬರು ಕ್ಲೈಂಟ್‌ಗಳು ಬೇರೆಯಾಗಿ ವರ್ತಿಸಬಹುದು. ಲಾಗ್ »ಸರಿಪಡಿಸಲು« ವಿನಾಯಿತಿಯನ್ನು ತೆಗೆದರೆ ಟನೆಲ್ ಕೂಡ ಜೊತೆಗೆ ಬೀಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಇಟ್ಟುಕೊಂಡು ಅದರ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡಿ.
ಸಾಕೆಟ್, ಕೋಷ್ಟಕ ಮತ್ತು ಲಾಗ್ ಸ್ವರೂಪವನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ
ಮೂರು ಅವಲೋಕನಗಳು ನೀವು ಯಾವ ಮಾರ್ಗವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಸಾಕೆಟ್ ಎಲ್ಲಿ ಕೇಳುತ್ತದೆ, ಯಾವ ಇಂಟರ್ಫೇಸ್ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಲಾಗ್ ಸ್ವರೂಪವು ನಿಜವಾಗಿ ಏನನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಶ್ರೋತೃವು ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಮಾತ್ರ ಬದ್ಧವಾಗಿದ್ದರೆ, ಸಾರ್ವಜನಿಕ ವಿನಂತಿ ಅಲ್ಲಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಲುಪಲಾರದು, ಇದು ತಕ್ಷಣ ಎರಡು ಸಾಲುಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಕ್ಲೈಂಟ್ಗಾಗಿ ಹುಡುಕಾಟವು ಟನೆಲ್ ಸಾಧನವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, ವಿನಂತಿ ಒಳಗಿನ ಮೂಲದೊಂದಿಗೆ ಬಂದಿದೆ ಮತ್ತು ಲಾಗ್ ಅದನ್ನು ತೋರಿಸಬೇಕು.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44ನಂತರ ಸಾಲನ್ನು ಅಲ್ಲ, ಸ್ವರೂಪವನ್ನು ಓದಿ. ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಹೆಡರ್ನಿಂದ ತುಂಬುವ ಕ್ಷೇತ್ರವು ಸಾಕೆಟ್ ಪೀರ್ ಅಲ್ಲ, ಹಕ್ಕನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಹಕ್ಕು ತಕ್ಷಣದ ಪೀರ್ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಕ್ಸಿ ಆಗಿರುವಾಗ ಮಾತ್ರ ಮುಖ್ಯ. ಎರಡೂ ಮೌಲ್ಯಗಳನ್ನು ಲಾಗ್‌ಗೆ ಬರೆಯುವುದು ನಂತರದ ವಾದಗಳನ್ನು ತೀರ್ಮಾನಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ತಕ್ಷಣದ ಪೀರ್ ಮತ್ತು ಬದಲಾಯಿಸಲಾದ ವಿಳಾಸ ಬೇರೆ ಬೇರೆ ಸತ್ಯಗಳು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಜಾಲದಿಂದ ಬಂದಿದೆ.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confನಿಮಗೆ ಬೇಕಾದ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು DNS ಒಪ್ಪುವಂತೆ ಮಾಡಿ
ಸೈಟ್ ಕೇವಲ ಟನೆಲ್ ಮೂಲಕ ಇರಬೇಕಾದರೆ, VPN ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರನ್ನು ಕೊಡಿ ಮತ್ತು ಕೇಳುವ ಸಾಕೆಟ್‌ನಲ್ಲಿ ನೀತಿಯನ್ನು ಜಾರಿಗೊಳಿಸಿ. ಒಳಗಿನ ಹೆಸರಿಗೆ 10.24.0.1 ಹಿಂತಿರುಗಿಸುವ ವಿಭಜಿತ DNS ಉತ್ತರವು ಹೆಸರು ಪರಿಹಾರದ ವಿವರದ ವೇಷದಲ್ಲಿ ಮಾರ್ಗದರ್ಶನ ನಿರ್ಧಾರ. ಸೈಟ್ ಸಾರ್ವಜನಿಕವೂ ಆಗಬೇಕಾದರೆ, ಎರಡು ಹೆಸರುಗಳು ಅಥವಾ ಎರಡು ಪೋರ್ಟ್‌ಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಯಾವುದು ವಿನಂತಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಿತು ಎಂದು ಲಾಗ್ ಹೇಳಲಿ.
ಅನುಮತಿ ನಿಯಮಗಳು ಅದೇ ತರ್ಕವನ್ನು ಅನುಸರಿಸುತ್ತವೆ. ಟನೆಲ್ ಪೂಲ್‌ಗೆ ಅನುಮತಿ ನೀಡುವುದು ಸಾರ್ವಜನಿಕ ವಿನಂತಿಗೆ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಇಂಟರ್ನೆಟ್ ಮೂಲಕ ಬಂದ ಸಂಪರ್ಕದಲ್ಲಿ ಒಳಗಿನ ವಿಳಾಸವನ್ನು ತುಂಬುವುದಿಲ್ಲ. ಎರಡೂ ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಒಂದೇ ಹೆಸರಿನ ಅಡಿಯಲ್ಲಿ ಮಿಶ್ರಣ ಮಾಡುವುದು ದಾಖಲಾದ ಮೂಲವನ್ನು ವಿನ್ಯಾಸ ಆಯ್ಕೆಯ ಬದಲು ಕ್ಲೈಂಟ್ ಮಾರ್ಗದ ಅಡ್ಡಪರಿಣಾಮವಾಗಿಸುತ್ತದೆ.
ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ನೀತಿ
ಗೇಟ್‌ವೇಯಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಮತ್ತು ನೀವು ನಿಯಂತ್ರಿಸುವ ವಿನಂತಿಯಿಂದ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ. ಟನೆಲ್ ಸಾಧನದಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಮತ್ತು ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಒಂದು, ಯಾವುದು ಬೈಟ್‌ಗಳನ್ನು ಸಾಗಿಸಿತು ಎಂದು ತೋರಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗಳ ಕ್ರಮ ಅವುಗಳ ನಡುವೆ ಅನುವಾದ ಸಂಭವಿಸಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5ನಂತರ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪ್ರವೇಶವನ್ನು ಪರಿಶೀಲಿಸಿ: ಉದ್ದೇಶಿತ ಹೆಸರಿನ ಪ್ರವೇಶ ಬಿಂದು ಉದ್ದೇಶಿತ ಕ್ಲೈಂಟ್‌ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅನುಮೋದಿಸದ ಸಾರ್ವಜನಿಕ ಮಾರ್ಗವು ಕೇವಲ ನಿಧಾನವಾಗುವ ಬದಲು ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯ IP-ಪ್ರತಿಧ್ವನಿ ಸೈಟ್ ಗೇಟ್‌ವೇಯ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನದ ಬಗ್ಗೆ ಏನನ್ನೋ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ಹೋಸ್ಟ್ನಲ್ಲಿನ ಈ ಸೈಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಪುಟ ಮತ್ತು WebSocket ಒಪ್ಪದಿದ್ದಾಗ, ಸರ್ವರ್ ಸಂರಚನೆಯನ್ನು ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ಅವುಗಳ URL, ವಿಳಾಸ ಕುಟುಂಬಗಳು ಮತ್ತು DNS ಉತ್ತರಗಳನ್ನು ಹೋಲಿಸಿ.