HAProxy 302 ಖಾಸಗಿ ಅಪ್ಲಿಕೇಶನ್ಗೆ: ಎರಡನೇ ಹಾಪ್ ಯಾರು ತೆರೆಯುತ್ತಾರೆ?

ಯಾರೋ ಸಾರ್ವಜನಿಕ HAProxy ಹೋಸ್ಟ್ ಅನ್ನು ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ಗೆ ತಿರುಗಿಸಿ, ಬ್ರೌಸರ್ ಏಕೆ ಅನುಸರಿಸಲಾಗದು ಎಂದು ಕೇಳುತ್ತಾರೆ. ಪ್ರಾಕ್ಸಿ ತನ್ನ VPN ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪುತ್ತದೆ, ಮರುನಿರ್ದೇಶನವು Location ಹೆಡರ್ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ನಂತರ ಸುರಂಗದ ಒಳಗೆ ಮಾತ್ರ ಇರುವ ವಿಳಾಸವನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಹೊರಗಿನಿಂದ ಪುಟ ಸುಮ್ಮನೆ ನೇತಾಡುತ್ತದೆ. ಎರಡನೇ ಸಂಪರ್ಕವನ್ನು ಯಾವ ಕಡೆ ತೆರೆಯುತ್ತದೆ ಎಂಬುದು ನಿರ್ಣಯ, ಮತ್ತು ಅದೇ ಮರುನಿರ್ದೇಶನವನ್ನು backend-ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.

ಸಂರಚನೆಯಲ್ಲಿ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ಮಾರ್ಗಗಳು

ಮರುನಿರ್ದೇಶನವು ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗೆ ವಿನಿಮಯವನ್ನು ಮುಗಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ Location ಓದಿ, ತಾನು ಇರುವಲ್ಲಿಂದ ಹೊಸ ವಿನಂತಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅಂದರೆ ನೀವು ಎಂದೂ ನಿಯಂತ್ರಿಸದ ಜಾಲಬಂಧದಿಂದ. ಪ್ರಾಕ್ಸಿ ಇನ್ನು ಪಾಲ್ಗೊಳ್ಳುವುದಿಲ್ಲ. ಮುಂದಿನದೆಲ್ಲವೂ ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ DNS, ಮಾರ್ಗ ಮತ್ತು ನಂಬಿಕೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ ಬಳಕೆದಾರರು ಬ್ರೌಸರ್ ಎಲ್ಲಿ ತೆರೆದರೋ ಅದರ ಪ್ರಕಾರ ಫಲಿತಾಂಶ ಬದಲಾಗುತ್ತದೆ:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

ಪ್ರಾಕ್ಸಿಯ backend ಎರಡನೇ ಹಂತವನ್ನು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಅದನ್ನು ಈಗಾಗಲೇ ಇರುವ ಮಾರ್ಗದಲ್ಲಿ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಒಂದೇ ಸಾರ್ವಜನಿಕ ಹೆಸರಿನೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿರುತ್ತದೆ. ಸುರಂಗ ಬಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಅನುಸರಿಸಲಾಗದ URL ಬದಲು ದೋಷ ಪಡೆಯುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವೇ ವೈಫಲ್ಯವನ್ನು ನಿಡಾನಯೋಗ್ಯವಾಗಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ದೋಷ ಲಾಗ್ಗಳಿರುವಲ್ಲಿಯೇ ಕಾಣಿಸುತ್ತದೆ:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy ನ ಮರುನಿರ್ದೇಶನ ದಾಖಲೆ ನಿಖರವಾಗಿ ಈ ಗೆರೆಯನ್ನು ಎಳೆಯುತ್ತದೆ: ಕ್ಲೈಂಟ್ಗೆ ಮರುನಿರ್ದೇಶನದಿಂದ ಉತ್ತರಿಸುವುದು ವಿನಂತಿಯನ್ನು backend-ಗೆ ಕಳುಹಿಸುವುದಕ್ಕಿಂತ ಬೇರೆ ಕ್ರಿಯೆ. ಎರಡು ಸೂಚನೆಗಳು ಸಂರಚನಾ ಕಡತದಲ್ಲಿ ಕೆಲವು ಸಾಲುಗಳ ಅಂತರದಲ್ಲಿವೆ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತವೆ. ಒಂದು ವಿನಂತಿಯನ್ನು ಮುಗಿಸುತ್ತದೆ, ಇನ್ನೊಂದು ಪ್ರಾಕ್ಸಿಯದ್ದಾದ ಎರಡನೇ ವಿನಂತಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಬ್ರೌಸರ್ಗೆ ಏನು ಬೇಕು ಮತ್ತು ಸರ್ವರ್ನ VPN ಅದಕ್ಕೆ ಏನು ಕೊಡುವುದಿಲ್ಲ

ಬ್ರೌಸರ್ನ ಸ್ವಂತ ವಿನಂತಿಗೆ ಅದಕ್ಕೆ ಇಲ್ಲದಿರಬಹುದಾದ ನಾಲ್ಕು ವಿಷಯಗಳು ಬೇಕು: ಖಾಸಗಿ ಹೆಸರಿಗೆ DNS ಉತ್ತರ, ಆ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗ, ಕೇಳುತ್ತಿರುವ ಸೇವೆಯನ್ನು ತಲುಪುವ ಅನುಮತಿ, ಮತ್ತು ಆ ಸೇವೆ ಒದಗಿಸುವ ಪ್ರಮಾಣಪತ್ರದ ಮೇಲೆ ನಂಬಿಕೆ. ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್ ತನ್ನ ಸುರಂಗದ ಮೂಲಕ ನಾಲ್ಕನ್ನೂ ಹೊಂದಿದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಆ ಸುರಂಗದಲ್ಲಿ ಎಂದೂ ಇರದ ಕ್ಲೈಂಟ್ಗೆ ಹರಿಯುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸುರಂಗ ಹೋಸ್ಟ್ನ ಗುಣ, URL ನದಲ್ಲ.

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

ಪ್ರಾಕ್ಸಿ ಮಾತ್ರ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪಬಲ್ಲಾಗ

ಮರುನಿರ್ದೇಶನ ಕ್ರಿಯೆಯನ್ನು ತೆಗೆದು ಆ ವಿನಂತಿಗಳನ್ನು ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ backend-ಗೆ ಕಳುಹಿಸಿ. Frontend ತನ್ನ ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, backend ವಿನಂತಿ ನಿಜವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ನ ಮಾರ್ಗದಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ರಾಕ್ಸಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ವಿವರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ತಾನೇ ಗಮ್ಯಸ್ಥಾನವಾಗುತ್ತದೆ. ಒಳಗಿನ ಪೋರ್ಟ್ 8080-ರಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕೇಳುವ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸರ್ವರ್ ಬ್ಲಾಕ್ ಚಿಕ್ಕದು:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

ಆ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿಯ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಬಗ್ಗೆ ಹೇಳಿಕೆಯಾಗಿ ಓದಿ: 10.40.0.20 ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್ನಿಂದಲೇ ತಲುಪಬಹುದಾಗಿರಬೇಕು, ಅಂದರೆ ಇಲ್ಲಿ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗದ ಬದಲು VPN ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ. check ಕೀವರ್ಡ್ ಆ ಮಾರ್ಗ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ತಿಳಿಸುತ್ತದೆ, ಮತ್ತು ಆರೋಗ್ಯ ಮಾರ್ಗ ಅಪ್ಲಿಕೇಶನ್ ಮೇಲೆ ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರತಿ ಪರಿಶೀಲನೆ ಸರ್ವರ್ ಅನ್ನು ಡೌನ್ ಎಂದು ಗುರುತಿಸುತ್ತದೆ. ಯಶಸ್ವಿ ಪರಿಶೀಲನೆ ಕ್ಲೈಂಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ ಮತ್ತು backend ಅನ್ನು ಯಾರು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ನೀತಿಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಈ ತುಣುಕು ಪೂರ್ಣ frontend ಅಲ್ಲ. ಶ್ರೋತೃ, ದೃಢೀಕರಣ, ಅನುಮತಿಸಿದ ಹೋಸ್ಟ್ ಮತ್ತು ಮಾರ್ಗದ ಆಯ್ಕೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಯಾರು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ನಿಯಮವನ್ನು ಉಳಿಸಿ. Backend ಪ್ರೋಟೋಕಾಲ್ ಕೂಡ ಹೊಂದಿಸಿ, ಏಕೆಂದರೆ HTTPS backend-ಗೆ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಮತ್ತು ಸರ್ವರ್ ಗುರುತಿನ ಸಂರಚನೆ ಬೇಕು, ಮತ್ತು ಆ ಪರಿಶೀಲನೆಯನ್ನು ಬಿಟ್ಟರೆ ಖಾಸಗಿ ಸಂಪರ್ಕ ಪರಿಶೀಲಿಸದ ಸಂಪರ್ಕವಾಗುತ್ತದೆ.

ವಿಜಯ ಘೋಷಿಸುವ ಮೊದಲು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಈಗ ಪ್ರಾಕ್ಸಿಯಿಂದ ಬರುವ ಸಂಪರ್ಕವನ್ನು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಲಾಗ್ಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್ ವಿಳಾಸದ ಯಾವುದೇ ಮೆಟಾಡೇಟಾ ಪ್ರಾಕ್ಸಿಯನ್ನು ವಿವರಿಸುತ್ತವೆ, ಬೇರೆ ರೀತಿ ವ್ಯವಸ್ಥೆ ಮಾಡದಿದ್ದರೆ. ಗುರುತು ಮತ್ತು ರವಾನೆಯಾದ ವಿಳಾಸಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ, ಮತ್ತು ಊಹಿಸುವ ಬದಲು ನಿರ್ಣಯವನ್ನು ಪರೀಕ್ಷಿಸಿ.

ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಮರುನಿರ್ದೇಶನಗಳು ಇನ್ನೂ ಒಳಮುಖವಾಗಿ ತೋರಿಸುತ್ತವೆ

ಮೊದಲ ವಿನಂತಿಯನ್ನು ರವಾನಿಸುವುದು ಸಂಯೋಜನೆಯ ಅರ್ಧ ಮಾತ್ರ. ಅಪ್ಲಿಕೇಶನ್ ಸಂಪೂರ್ಣ ಮರುನಿರ್ದೇಶನಗಳು, ಕಠಿಣವಾಗಿ ಸಂಕೇತಿಸಿದ ಸಂಪನ್ಮೂಲ URLಗಳು, ಅಥವಾ ಒಳಗೆ ತಿಳಿದಿರುವ ಹೆಸರಿಗೆ ಸೀಮಿತವಾದ ಕುಕಿಗಳನ್ನು ಹೊರಡಿಸಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬ್ರೌಸರ್ ಅನ್ನು ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಒಳಗಿನ ಹೆಸರಿಗೆ ತೋರಿಸುವ Location ಹೆಡರ್ ಮೂಲ ಸಮಸ್ಯೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ತಪ್ಪಾಗಿ ಪ್ರಾಕ್ಸಿ ವೈಫಲ್ಯ ಎಂದು ನಿಡಾನ ಮಾಡಲಾಗುತ್ತದೆ.

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

ರವಾನೆಯಾದ ಮೆಟಾಡೇಟಾವನ್ನು ನಿಗದಿತ ಪ್ರಾಕ್ಸಿಯಿಂದ ಮಾತ್ರ ನಂಬಿ. ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಹೊಂದಿಸಬಹುದಾದ ಹೆಡರ್ ಎಂದಿಗೂ ಅಧಿಕಾರ ಮೌಲ್ಯವಾಗಬಾರದು, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರಾಕ್ಸಿ ಕರೆ ಮಾಡುವವನು ಬೇರೊಬ್ಬರ ಗುರುತನ್ನು ಕ್ಲೇಮ್ ಮಾಡುವ ದಾರಿಯಾಗುತ್ತದೆ. ಈ ನಿಯಮ ಮರುನಿರ್ದೇಶನ ಪ್ರಶ್ನೆಯಿಂದ ಸ್ವತಂತ್ರವಾಗಿದೆ ಮತ್ತು ಮುಂದಿನ ಯಾವುದೇ ಮರು ವಿನ್ಯಾಸವನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತದೆ.

ನಿಮ್ಮ ಬಳಿ ವಾಸ್ತವವಾಗಿ ಯಾವ ವಿನ್ಯಾಸವಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

ಪ್ರತಿ ಬಳಕೆದಾರನಿಗೂ ಈಗಾಗಲೇ ಅಧಿಕೃತ VPN ಪ್ರವೇಶವಿದ್ದರೆ, ಖಾಸಗಿ URL-ಗೆ ಮರುನಿರ್ದೇಶನ ಉದ್ದೇಶಪೂರ್ವಕ ವಿನ್ಯಾಸವಾಗಿರಬಹುದು. ಆ ಅವಶ್ಯಕತೆಯನ್ನು ಊಹಿಸುವ ಬದಲು ಸ್ಪಷ್ಟವಾಗಿ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಎರಡು ವಿನ್ಯಾಸಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಜನಸಂಖ್ಯೆಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತವೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಹೋಟೆಲ್ ಜಾಲಬಂಧದಿಂದಲೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಇನ್ನೊಂದು ಸಾರ್ವಜನಿಕ URL ಲೋಡ್ ಮಾಡಬಲ್ಲ ಯಾರಿಗಾದರೂ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಡ್ಡುತ್ತದೆ. ಆ ಭೇದ ವಿನ್ಯಾಸ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಇರಬೇಕು.

ಬಳಕೆದಾರರ ಜಾಲಬಂಧದಲ್ಲಿರುವ ಯಂತ್ರದಿಂದ ಪರಿಶೀಲನೆ ನಡೆಸಿ ಮತ್ತು ಬ್ರೌಸರ್ ಮಾಡುವ ಪ್ರತಿ ಹಾಪ್ ಅನ್ನು ಅನುಸರಿಸಿ, ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆಯಷ್ಟೇ ಅಲ್ಲ. ವಿಳಾಸ ಪಟ್ಟಿ ಮತ್ತು ಪ್ರತಿ ಮುಂದಿನ ವಿನಂತಿಯ ಮೇಲೆ ಕಣ್ಣಿಡಿ, ಏಕೆಂದರೆ ಸಂಪನ್ಮೂಲ ಟ್ಯಾಗ್ನಲ್ಲಿ ಒಂದೇ ಸಂಪೂರ್ಣ URL ಮೊದಲ ಹಾಪ್ ದಾಟಿದ ಹರಿವನ್ನು ಮುರಿಯಲು ಸಾಕು. ಸೈನ್-ಇನ್ ಸಾರ್ವಜನಿಕ ಹೆಸರಿನ ಮೂಲಕ ಕೆಲಸ ಮಾಡಬೇಕು, ಮತ್ತು ನಿರಾಕರಿಸಬೇಕಾದ ಸಂಪನ್ಮೂಲಗಳು ನಿರಾಕರಿಸಲ್ಪಟ್ಟೇ ಇರಬೇಕು.

ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಪ್ರಕಟಿಸುವುದು ಪ್ರತ್ಯೇಕ ಪ್ರವೇಶ ನಿರ್ಣಯ, ಪ್ರಾಕ್ಸಿಯ ಸ್ವಂತ VPN ಅನ್ನು ಅದರ ಸಾರ್ವಜನಿಕ URL ಲೋಡ್ ಮಾಡಬಲ್ಲ ಎಲ್ಲರಿಗೂ ಪಾರದರ್ಶಕವಾಗಿ ವಿಸ್ತರಿಸುವುದಲ್ಲ. ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಮತ್ತು ಒಳಗೆ ಯಾರಿಗೆ ಬಿಡುತ್ತಾರೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ. ನಿಯೋಜನೆಯ ನಂತರ ಆ ಪ್ರಶ್ನೆಯನ್ನು ನಿರ್ಧರಿಸುವುದೇ ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ಆಕಸ್ಮಿಕವಾಗಿ ಸಾರ್ವಜನಿಕವಾಗುವ ದಾರಿ.

ಎರಡರಲ್ಲಿ ಯಾವುದನ್ನು ಕಟ್ಟಿದಿರಿ ಮತ್ತು ಏಕೆ ಎಂದು ಬರೆಯಿರಿ. ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಇನ್ನೊಂದನ್ನು ಊಹಿಸುತ್ತಾರೆ. ಸೌಲಭ್ಯಕ್ಕಾಗಿ ಸೇರಿಸಿದ ಒಂದೇ ಮರುನಿರ್ದೇಶನ ಮೂಲ ವೈಫಲ್ಯವನ್ನು ಮತ್ತೆ ಸೃಷ್ಟಿಸಲು ಸಾಕು, ಮತ್ತು ಲಕ್ಷಣ ನೀವು ಈಗತಾನೇ ಸರಿಪಡಿಸಿದ್ದಂತೆಯೇ ಕಾಣುತ್ತದೆ.