Port-Share ಏಕೆ ಎಲ್ಲಾ ವೆಬ್ಸೈಟ್ ಸಂದರ್ಶಕರನ್ನು localhost ನಂತೆ ತೋರಿಸುತ್ತದೆ

ಪ್ರವೇಶ ಲಾಗ್ನ ಪ್ರತಿ ಸಾಲು ಒಂದೇ loopback ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಪುಟ ಸ್ವತಃ ಲೋಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಸರಿಯಾಗಿ ಪರಿಶೀಲನೆಯಾಗುತ್ತದೆ. ತಲುಪಲಾಗದಿರುವ ಅರ್ಥದಲ್ಲಿ ಏನೂ ಮುರಿದಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕೇ ಈ ಸ್ಥಿತಿ ತಿಂಗಳುಗಳ ಕಾಲ ಉಳಿಯುತ್ತದೆ. ಮುರಿದದ್ದು ಆರೋಪಣೆ: ವೆಬ್ ಬ್ಯಾಕೆಂಡ್ ಸಂಪರ್ಕವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಹಾಪ್ನ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಲಾಗ್ ಅನ್ನು ನಂಬಿದ ಪ್ರತಿಯೊಂದು ನಂತರದ ನಿರ್ಧಾರವೂ ಅದೇ ತಪ್ಪು ಉತ್ತರವನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯಿತು.

ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳು ಕೇಬಲ್ನಿಂದ ಒಳಮುಖವಾಗಿ ಸಾಗುತ್ತವೆ. ನೀವು ನೋಡುವ ಮೌಲ್ಯವನ್ನು ವಿವರಿಸುವ ಮೊದಲನೆಯದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ನಂತರದ ಹಂತವೂ ಹಿಂದಿನವು ಈಗಾಗಲೇ ಸರಿ ಎಂದು ಊಹಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಫ್ರಂಟ್-ಎಂಡ್ ಸಂರಚನೆಯನ್ನು ಊಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಲಾಗ್ ಸಾಲನ್ನಲ್ಲ, ಎರಡು ಸಂಪರ್ಕಗಳನ್ನು ಅನುಸರಿಸಿ

Port-Share ಒಂದೇ TCP ಆಲಿಸುವಿಕೆಯಲ್ಲಿ ಎರಡು ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನು ಮಲ್ಟಿಪ್ಲೆಕ್ಸ್ ಮಾಡುತ್ತದೆ. OpenVPN ಒಳಬರುವ ಸಂಪರ್ಕದ ಮೊದಲ ಬೈಟ್ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಅದು ತನ್ನದೇ ಪ್ರೋಟೋಕಾಲ್ನಂತೆ ಕಂಡಾಗ ಅದನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಉಳಿದೆಲ್ಲವನ್ನೂ ಎರಡನೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಒಪ್ಪಿಸುತ್ತದೆ. ಆ ಗಮ್ಯಸ್ಥಾನ ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಹೋಸ್ಟ್ನಲ್ಲಿನ ವೆಬ್ ಸರ್ವರ್, ಆದ್ದರಿಂದ ವೆಬ್ ಸರ್ವರ್ನ ಸ್ವೀಕರಿಸಿದ ಸಾಕೆಟ್ಗೆ OpenVPN ಪ್ರಕ್ರಿಯೆಯೇ ಜೋಡಿ.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

ಮೊದಲ ಆಜ್ಞೆ ಸಾರ್ವಜನಿಕ ಆಲಿಸುವಿಕೆ ಯಾರದ್ದು ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಬ್ಯಾಕೆಂಡ್ ಪೋರ್ಟ್ಗೆ ಬರುವ ಸಂಪರ್ಕಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳ ಜೋಡಿ ವಿಳಾಸವೇ ಪ್ರವೇಶ ಲಾಗ್ ಮುದ್ರಿಸುವುದು. ಆ ಜೋಡಿ loopback ಆಗಿದ್ದರೆ, ಲಾಗ್ ನಿಖರವಾಗಿದೆ ಮತ್ತು ಮಾಹಿತಿ ಒಂದು ಪದರ ಮೊದಲೇ ಕಳೆದುಹೋಗಿದೆ. ಲಾಗ್ ಕ್ಷೇತ್ರದ ಹೆಸರು ಬದಲಿಸುವುದಾಗಲೀ ಕ್ಲೈಂಟ್-IP ಮಾಡ್ಯೂಲ್ ಸಕ್ರಿಯಗೊಳಿಸುವುದಾಗಲೀ ಸಂಪರ್ಕವೇ ಎಂದೂ ಒಯ್ಯದ ವಿಳಾಸವನ್ನು ಮರಳಿ ತರುವುದಿಲ್ಲ.

ಇದೇ ಉಳಿದೆಲ್ಲವನ್ನೂ ನಿರ್ಧರಿಸುವ ಪರಿಶೀಲನೆ. ಬ್ಯಾಕೆಂಡ್ನ ಜೋಡಿ ಬ್ರೌಸರ್ನ ವಿಳಾಸವಾಗಿದ್ದರೆ, ಪೋರ್ಟ್ ಹಂಚಿಕೆ ನಿಮ್ಮ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಲಾಗ್ ಸ್ವರೂಪವೇ ಸಮಸ್ಯೆ.

ಸಾರಿಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಹೆಡರ್ ಇಂಜೆಕ್ಷನ್ ಅಲ್ಲ

ಫಾರ್ವರ್ಡರ್ ಬೈಟ್ಗಳನ್ನು ಸರಿಸುತ್ತದೆ. ಅದು HTTP ಅನ್ನು ವಿಶ್ಲೇಷಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಎಂದೂ ವಿನಂತಿಯಾಗಿ ಓದದ ವಿನಂತಿಗೆ ಹೆಡರ್ ಸೇರಿಸಲಾಗದು, ಮತ್ತು ಸ್ಪರ್ಶಿಸದೆ ರವಾನಿಸುವ TLS ಸ್ಟ್ರೀಮ್ಗೆ ಏನನ್ನೂ ಸೇರಿಸಲಾಗದು. ಪ್ರಾಕ್ಸಿ ಹೆಡರ್ ನಿರೀಕ್ಷಿಸುವ ಮಾಡ್ಯೂಲ್ ಯಾವುದೇ ಘಟಕ ಉತ್ಪಾದಿಸದ ಒಂದಕ್ಕಾಗಿ ಕಾಯುತ್ತಲೇ ಇರುತ್ತದೆ.

ಮೂಲ ವಿಳಾಸವನ್ನು ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳು ಒಯ್ಯಬಹುದು, ಮತ್ತು ಎರಡೂ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಒಪ್ಪಿಗೆ ಬೇಕು. PROXY ಪ್ರೋಟೋಕಾಲ್ ಸಂಪರ್ಕದ ಆರಂಭಕ್ಕೆ ಸಣ್ಣ ಹೆಡರ್ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಅದನ್ನು ನಿರೀಕ್ಷಿಸಲು ಸಂರಚಿತವಾಗಿರಬೇಕು; ನಿರೀಕ್ಷಿಸದ ಬ್ಯಾಕೆಂಡ್ ಆ ಬೈಟ್ಗಳನ್ನು ವಿನಂತಿಯ ಆರಂಭವೆಂದು ಪರಿಗಣಿಸಿ ಗೊಂದಲದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. X-Forwarded-For ನಂತಹ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಾಕ್ಸಿ ಹೆಡರ್ಗಳು HTTP ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪ್ರಾಕ್ಸಿ ಅವನ್ನು ಹೊಂದಿಸಿದಾಗ ಮತ್ತು ಯಾವ ಜೋಡಿಗಳು ಅವನ್ನು ಪ್ರತಿಪಾದಿಸಬಹುದು ಎಂದು ಬ್ಯಾಕೆಂಡ್ಗೆ ತಿಳಿಸಿದಾಗ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

ಐಚ್ಛಿಕ ಮೂಲ-ಮ್ಯಾಪಿಂಗ್ ಡೈರೆಕ್ಟರಿ

ಪೋರ್ಟ್ ಹಂಚಿಕೆಗೆ ಐಚ್ಛಿಕ ಡೈರೆಕ್ಟರಿ ಆರ್ಗ್ಯುಮೆಂಟ್ ಇದೆ, ಅದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಜಾರಿಗೆ ತಂದಿರುವ ಪ್ಲಾಟ್ಫಾರ್ಮ್ಗಳಲ್ಲಿ ಮೂಲ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಸಂಪರ್ಕದ ನಡುವಿನ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ವೆಬ್ ಬದಿಯು ಆ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವ ನಿರೀಕ್ಷೆ ಇದೆ; ಅದು ಹೆಡರ್ ಅಲ್ಲ, ಮತ್ತು ಅದನ್ನು ವಿನಂತಿಗೆ ಚುಚ್ಚಲಾಗುವುದಿಲ್ಲ.

ಆ ವಿನ್ಯಾಸವನ್ನು ತಿಳಿಯುವುದು ಯೋಗ್ಯ, ಏಕೆಂದರೆ ತೋರಿಕೆಯಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಫ್ರಂಟ್-ಎಂಡ್ ಸಂರಚನೆಯೊಂದಿಗೆ ಕೆಲವು ನಿಯೋಜನೆಗಳು ನಿಜವಾದ ವಿಳಾಸಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತವೆ ಮತ್ತು ಇನ್ನು ಕೆಲವು ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಅದು ವಿವರಿಸುತ್ತದೆ. ವ್ಯತ್ಯಾಸ ಸ್ವೀಕರಿಸುವ ಬದಿಯಲ್ಲಿದೆ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ವೆಬ್ ಸರ್ವರ್ಗಳು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಸಕ್ರಿಯಗೊಳಿಸದ ಮಾಡ್ಯೂಲ್ ಅಥವಾ ಪ್ಯಾಚ್ನಲ್ಲಿ ಇರುತ್ತದೆ. ನಿಮ್ಮ ವೆಬ್ ಸರ್ವರ್ನ ದಾಖಲೆಗಳಲ್ಲಿ ಅದು ನೀಡುವ ನಿಖರವಾದ ಕೊಕ್ಕೆಯನ್ನು ಓದಿ, ಮತ್ತು ಊಹಿಸುವ ಬದಲು ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಆಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಈ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಅದನ್ನು ಎರಡು ಅರ್ಧಗಳ ಏಕೀಕರಣವೆಂದು ಪರಿಗಣಿಸಿ: ಫಾರ್ವರ್ಡರ್ ಬರೆಯುವ ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಮಾಡುವ ಹುಡುಕಾಟ. ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಡೈರೆಕ್ಟರಿ ಮರುಪ್ರಾರಂಭವನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯನಿರತ ಆಲಿಸುವಿಕೆಯಲ್ಲಿ ಮಿತಿಯಿಲ್ಲದೆ ಬೆಳೆಯುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ವಿಳಾಸಕ್ಕೆ ಯಾವ ಘಟಕ ಖಾತರಿ ನೀಡುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

ಸಂರಚನೆಯನ್ನು ಬದಲಿಸುವ ಮೊದಲು, ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಪ್ರತಿಪಾದಿಸಲು ಅನುಮತಿ ಇರುವ ಘಟಕವನ್ನು ಮತ್ತು ಅದನ್ನು ನಂಬಲು ಅನುಮತಿ ಇರುವ ಘಟಕಗಳನ್ನು ಹೆಸರಿಸಿ. ಒಂದೇ ಬರೆದ ಉತ್ತರವು ಸಾಮಾನ್ಯ ಒತ್ತರಿಕೆಯನ್ನು ತಡೆಯುತ್ತದೆ, ಅಲ್ಲಿ ಮೂರು ವಿಭಿನ್ನ ಪದರಗಳು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಮೂಲವನ್ನು ನಂಬುತ್ತವೆ.

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

ಕೆಲಸ ಮಾಡದಿರುವುದು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ loopback ವಿಳಾಸವನ್ನು ವಿನಂತಿ ಈ ಯಂತ್ರದಲ್ಲಿ ಹುಟ್ಟಿತು ಎಂಬ ಸಾಕ್ಷ್ಯವಾಗಿ ಪರಿಗಣಿಸುವುದು. ಆ ತೀರ್ಮಾನ ನಿಖರವಾಗಿ ವಿರುದ್ಧವಾಗಿದೆ: ವಿಳಾಸ ಇರುವುದೇ ಸ್ಥಳೀಯ ಘಟಕ ಸಂಪರ್ಕವನ್ನು ಮಾಡಿದ್ದರಿಂದ. ಹಾಗೆ ಬರೆದ ನಿಯಮ ಆಲಿಸುವಿಕೆಯನ್ನು ತಲುಪಬಲ್ಲ ಯಾರನ್ನೂ ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ.

ಪುಟವನ್ನಲ್ಲ, ನಿಯಮವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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