ಸಾಕೆಟ್ ಪೀರ್ vs ಫಾರ್ವರ್ಡೆಡ್ ಹೆಡರ್: ಯಾವ ವಿಳಾಸವನ್ನು ನಂಬಬೇಕು?

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

ಏನನ್ನಾದರೂ ಹೋಲಿಸುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ವಿವರಿಸಿ:

Client -> approved reverse proxy -> application origin

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

ವಿಳಾಸದ ಎರಡು ರೀತಿಯ ಸಾಕ್ಷ್ಯ

ಸಾಕೆಟ್ ಪೀರ್ ಒಂದು TCP ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಇರುವ ಸತ್ಯ: ಏನೋ ಆ ವಿಳಾಸದಿಂದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸಿತು. ಅದು ನಿಮಗೆ ಮುಖ್ಯವಾದ ವ್ಯಕ್ತಿ, ಸಾಧನ ಅಥವಾ ಖಾತೆ ಇರಬೇಕೆಂದಿಲ್ಲ, ಏಕೆಂದರೆ VPN ಅಥವಾ Tor ನಿರ್ಗಮನವು ಸೇವೆ ಗಮನಿಸುವ ಮೂಲವಾಗಿರಲು ಕಾನೂನುಬದ್ಧವಾಗಿ ಸಾಧ್ಯ. ಆದರೂ ಅದು ಹೋಸ್ಟ್ ಸ್ವತಃ ಪರಿಶೀಲಿಸಿದ ಏಕೈಕ ವಿಳಾಸ, ಮತ್ತು ಅದರ ಸಂಪೂರ್ಣ ಮೌಲ್ಯ ಅಷ್ಟೇ.

ಫಾರ್ವರ್ಡಿಂಗ್ ಕ್ಷೇತ್ರವು ಸರಪಳಿಯ ಬಗ್ಗೆ ಇರುವ ಮೆಟಾಡೇಟಾ. X-Forwarded-For, X-Real-IP ಮತ್ತು ಪ್ರಮಾಣೀಕೃತ ಕ್ಷೇತ್ರ Forwarded ಅನ್ನು ಅವನ್ನು ಪ್ರತಿಧ್ವನಿಸುವ ಅಂತ್ಯಬಿಂದುವನ್ನು ತಲುಪುವ ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಬರೆಯಬಹುದು, ಆದ್ದರಿಂದ ಅವುಗಳ ವಿಶ್ವಾಸಾರ್ಹತೆ ಅವನ್ನು ಹೊಂದಿಸಲು ಯಾರಿಗೆ ಅನುಮತಿ ಇತ್ತು ಎಂಬುದರ ಮೇಲೆ ಸಂಪೂರ್ಣವಾಗಿ ಅವಲಂಬಿತವಾಗಿದೆ.

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

ಹೆಡರ್ ಎಂದಿಗೂ ಸಂಪರ್ಕವನ್ನು ಮರುಮಾರ್ಗ ಮಾಡುವುದಿಲ್ಲ

ಫಾರ್ವರ್ಡಿಂಗ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ವಿಳಾಸ ಬರೆಯುವುದು ಸರ್ವರ್‌ಗೆ ಬರುವ TCP ಸಂಪರ್ಕದ ಮೂಲವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಮಾರ್ಗದ ಎಲ್ಲಿಯೂ ರೂಟಿಂಗ್ ಬದಲಿಸುವುದಿಲ್ಲ. ಸಾಮಾನ್ಯ VPN ರೂಟಿಂಗ್ ಅಥವಾ ಮೂಲ NAT ಯಾವುದೇ HTTP ಹೆಡರ್ ಇಲ್ಲದೆ ಸಂಚಾರವನ್ನು ತಲುಪಿಸುತ್ತದೆ. ಅದೇ ರೀತಿ, ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ TLS ಅಂತ್ಯಬಿಂದುವಿನ ವ್ಯವಸ್ಥೆಯನ್ನು ಬದಲಿಸದೆ ಸರಿಯಾಗಿ ಸಂರಕ್ಷಿತ HTTPS ವಿನಿಮಯವನ್ನು ಮರುಬರೆಯುವುದಿಲ್ಲ.

ವಿರುದ್ಧ ದೋಷವೂ ಅಷ್ಟೇ ಸಾಮಾನ್ಯ: HTTPS ಕ್ಲೈಂಟ್ ಒದಗಿಸಿದ ಫಾರ್ವರ್ಡಿಂಗ್ ಹೆಡರ್ ಅನ್ನು ಸತ್ಯವಾಗಿಸುವುದಿಲ್ಲ. ಅದು ಸುಳ್ಳು ಪ್ರತಿಪಾದನೆಯ ಸಾಗಣೆಯನ್ನು ನಿಜವಾದದ್ದಕ್ಕಿಂತ ಕಡಿಮೆ ರಕ್ಷಿಸುವುದಿಲ್ಲ.

ಸಹೋದ್ಯೋಗಿ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು ಹೆಡರ್ ಬದಲಾವಣೆಯನ್ನು ಸೂಚಿಸಿದರೆ, ರೋಗನಿರ್ಣಯ ಈಗಾಗಲೇ ತಪ್ಪಾಗಿ ಹೋಗಿದೆ. ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ, ಅಥವಾ ಹೆಡರ್ ಬರೆಯುವ ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆಯನ್ನು ಸರಿಪಡಿಸಿ.

ಪ್ರತಿಪಾದಿಸಲು ಅನುಮತಿ ಇರುವ ಪ್ರಾಕ್ಸಿಯನ್ನು ಹೆಸರಿಸಿ

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

NGINX ನಿಜವಾದ IP ಮಾಡ್ಯೂಲ್ ವಿಭಜನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತೋರಿಸುತ್ತದೆ. set_real_ip_from ಯಾರ ಪ್ರತಿಪಾದನೆ ಎಣಿಕೆಗೆ ಬರುತ್ತದೋ ಆ ಕಳುಹಿಸುವವರನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು real_ip_header ಯಾವ ಕ್ಷೇತ್ರ ಅದನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ; ಮೊದಲನೆಯದು ವಿಶ್ವಾಸವನ್ನು ಮಾಡುತ್ತದೆ, ಎರಡನೆಯದು ಎಲ್ಲಿ ನೋಡಬೇಕು ಎಂದು ಮಾತ್ರ ಹೇಳುತ್ತದೆ.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

ಕೇವಲ ಹೆಡರ್ ಆಯ್ಕೆ ಸೂಚನೆ ತಾನೇ ಮೌಲ್ಯವನ್ನು ಯಾರು ಕಳುಹಿಸಿದರು ಎಂಬುದರ ಬಗ್ಗೆ ಇನ್ನೂ ಏನನ್ನೂ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ.

ಸಾಗಣೆ ಭದ್ರತೆ ನೀವು ನಂಬುವ ಘಟಕಗಳ ನಡುವೆ ಇಡೀ ಮಾರ್ಗವನ್ನು ಸಾಗಬೇಕು. ಸರಿಯಾಗಿ ಸಾಮಾನ್ಯಗೊಳಿಸುವ ಅಂಚು ಆ ಮೌಲ್ಯವನ್ನು ಕೆಳಗಿನ ಅಸುರಕ್ಷಿತ ಹಂತವು ಪ್ರಯಾಣದಲ್ಲಿರುವಾಗ ಪ್ರತಿಪಾದನೆಯನ್ನು ಬೇರೆಯವರು ಸಂಪಾದಿಸಲು ಬಿಡುವ ಕ್ಷಣದಲ್ಲಿ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಬಹು-ಹಂತದ ಸರಪಳಿಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ವಹಿಸಿ

ಹಲವು ಪ್ರಾಕ್ಸಿಗಳಿಗೆ ಸ್ಪಷ್ಟ ಸರಪಳಿ ಮಾದರಿ ಬೇಕು. ಯಾವುದೋ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಹಾಗೆ ಮಾಡಿದ್ದರಿಂದ ಅಲ್ಪವಿರಾಮದಿಂದ ಬೇರ್ಪಟ್ಟ ಎಡತುದಿ ಅಥವಾ ಬಲತುದಿಯ ಮೌಲ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಡಿ; ನಿಮ್ಮ ಪ್ರಾಕ್ಸಿಗಳಲ್ಲಿ ಯಾವುದು ಸೇರಿಸುತ್ತದೆ, ಯಾವುದು ಬದಲಾಯಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದು ಒಳಬರುವ ಕ್ಷೇತ್ರವನ್ನು ಉಳಿಸುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ. ಉದಾಹರಣೆಗೆ, NGINX ತನ್ನ ವಿಶ್ವಸ್ತ ಗಣದ ವಿರುದ್ಧ ಪಟ್ಟಿಯನ್ನು ಹಿಂದಕ್ಕೆ ನಡೆದು ತನ್ನದಲ್ಲದ ಮೊದಲ ವಿಳಾಸದಲ್ಲಿ ನಿಲ್ಲಬಹುದು, ಮತ್ತು ಅದು ಆ ಉತ್ಪನ್ನದ ನಿಯಮ, ಪ್ರತಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನುಸರಿಸುವ ಕಾನೂನಲ್ಲ. ನಿಮ್ಮದೇ ಪ್ರಾಕ್ಸಿಯ ದಾಖಲೆಗಳನ್ನು ಅದೇ ಎರಡು ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ಓದಿ: ಅದು ಯಾವ ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಯಾವ ಕಳುಹಿಸುವವರನ್ನು ನಂಬುತ್ತದೆ?

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

ನೀವು ಹಂತವನ್ನು ಸೇರಿಸಿದಾಗ, ಆ ದಾಖಲೆಯನ್ನು ಮರುಪರಿಶೀಲಿಸಿ. ವಿಶ್ವಸ್ತ ಪ್ರಾಕ್ಸಿಯ ಮುಂದೆ ಸೇರಿಸಿದ ಹೊಸ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಯಾರೂ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪಾದಿಸದೆಯೇ ಯಾವ ವಿಳಾಸ ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸಬಹುದು.

ಎರಡೂ ಅವಲೋಕನಗಳನ್ನು ಲಾಗ್‌ನಲ್ಲಿ ಇರಿಸಿ

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

ಈ ಜೋಡಿಯ ಅರ್ಥವನ್ನು ನೆನಪಿಡಿ. ಹೆಡರ್ ನೀವು ನಂಬಲು ಆಯ್ಕೆ ಮಾಡಿದ ಘಟಕ ಒದಗಿಸುವ ಸಂದರ್ಭವನ್ನು ಸೇರಿಸುತ್ತದೆ; ಪೀರ್ ನಿಮ್ಮ ಹೋಸ್ಟ್ ನಿಜವಾಗಿ ನೋಡಿದ ಏಕೈಕ ವಿಳಾಸವಾಗಿ ಉಳಿಯುತ್ತದೆ. ಎರಡೂ ವೈಯಕ್ತಿಕ ಗುರುತಿನ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು ಯಾವುದನ್ನೇ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸುವ ವಿನ್ಯಾಸವು ಯಾರೋ ಒಬ್ಬರ ಬಗ್ಗೆ ತಪ್ಪಾಗುತ್ತದೆ.