Firefox 127.0.0.1:8000 ಕಡೆ ತೋರಿಸುತ್ತದೆ, N2N ಎಡ್ಜ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಪೀರ್ ತನ್ನ ಓವರ್‌ಲೇ ವಿಳಾಸದಲ್ಲಿ ping ಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ಇನ್ನೂ ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಆ ಸರಪಳಿಯಲ್ಲಿ ಯಾವುದೂ ವಿರೋಧಾಭಾಸವಲ್ಲ. ಓವರ್‌ಲೇ ಹೋಸ್ಟ್‌ಗೆ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ತಲುಪಬಹುದಾದ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ; ಅದು ಪ್ರಾಕ್ಸಿ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರಚಿಸುವುದಿಲ್ಲ. ಬ್ರೌಸರ್ ಪೀರ್‌ಗೆ ಮಾರ್ಗವನ್ನು ಕೇಳುತ್ತಿಲ್ಲ. ಅದು ಸ್ಥಳೀಯ ಲಿಸನರ್ ಕೇಳುತ್ತಿದೆ.

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

ಎರಡು ಸಂಪರ್ಕಗಳು, ಒಂದಲ್ಲ

ಮೊದಲ ಸಂಪರ್ಕ ಬ್ರೌಸರ್‌ನಿಂದ loopback ಪೋರ್ಟ್‌ನಲ್ಲಿ ಕೇಳುವ ಯಾವುದಕ್ಕೂ ಹೋಗುತ್ತದೆ. ಅದು ಸ್ಥಳೀಯ ಸಾಕೆಟ್, ಮತ್ತು ಅದನ್ನು ಯಾವುದೂ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಒಂದು ಪ್ಯಾಕೆಟ್ ಕೂಡ N2N ತಲುಪುವ ಮೊದಲು ಸಂಪರ್ಕ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ. ಎರಡನೆಯದು ಪ್ರಾಕ್ಸಿ ಪ್ರಕ್ರಿಯೆಯಿಂದ ಅದು ಪಡೆಯುವ ಮೂಲಕ್ಕೆ ಹೋಗುತ್ತದೆ. ಆ ಮಾರ್ಗವನ್ನು ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್‌ನ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯ ಅಪ್‌ಲಿಂಕ್, ಇನ್ನೊಂದು ಟನೆಲ್, ಅಥವಾ ಓವರ್‌ಲೇಗೆ ಸಂಬಂಧವಿಲ್ಲದ ನೀತಿ-ಮಾರ್ಗವಾಗಿರಬಹುದು.

ಪೀರ್‌ಗೆ ping ಮಾಡುವುದು ಓವರ್‌ಲೇ ಎಡ್ಜ್ ವಿಳಾಸಗಳ ನಡುವೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತಲುಪಿಸಬಹುದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು ಪೋರ್ಟ್ 8000 ನಲ್ಲಿ ಲಿಸನರ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಹೋಸ್ಟ್ ಮೂಲವನ್ನು ತಲುಪಬಹುದೇ ಎಂಬುದನ್ನೂ ಅಲ್ಲ. ಪ್ರತ್ಯೇಕ ವೈಫಲ್ಯಗಳು, ಪ್ರತ್ಯೇಕ ಪರಿಹಾರಗಳು.

ಲಿಸನರ್ ಎಲ್ಲಿ ಇರಬೇಕು

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

ಸಂರಚನಾ ಫೈಲ್ ಬದಲು ಸಾಕೆಟ್ ಪಟ್ಟಿಯಿಂದ ನಿಜವಾದ ಬೈಂಡ್ ಪರಿಶೀಲಿಸಿ. ಓವರ್‌ಲೇ ಮೇಲೇಳುವ ಮೊದಲು ಪ್ರಾರಂಭವಾದ ಡೀಮನ್ ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾಗಿರಬಹುದು.

localhost ಪೀರ್ ಅಲ್ಲ

ಬ್ರೌಸರ್‌ನ ಪ್ರಾಕ್ಸಿ ಕ್ಷೇತ್ರದಲ್ಲಿ, localhost ಬ್ರೌಸರ್‌ನ ಸ್ವಂತ ಯಂತ್ರಕ್ಕೆ ತೋರಿಸುತ್ತದೆ. ಅದು ಎಡ್ಜ್ ಅಲ್ಲ, ಸೂಪರ್‌ನೋಡ್ ಅಲ್ಲ, ಮತ್ತು ಟನೆಲ್‌ನ ದೂರದ ತುದಿಯ ಹೋಸ್ಟ್ ಅಲ್ಲ. ಪ್ರಾಕ್ಸಿ ಬೇರೆ ಪೀರ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತಿದ್ದರೆ, ಆ ಪೀರ್‌ನ ತಲುಪಬಹುದಾದ ಓವರ್‌ಲೇ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಕ್ಷೇತ್ರದಲ್ಲಿ ಹಾಕಿ, ನಂತರ ಲಿಸನರ್ ನಿಮ್ಮ ಎಡ್ಜ್ ವಿಳಾಸದಿಂದ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಸೂಪರ್‌ನೋಡ್‌ಗಳು ಎಡ್ಜ್‌ಗಳಿಗೆ ಪರಸ್ಪರ ಹುಡುಕಲು ಸಹಾಯ ಮಾಡುತ್ತವೆ; ಅವು ಪ್ರಾಕ್ಸಿ ಸೇವೆ ಅಲ್ಲ. ಸೂಪರ್‌ನೋಡ್ ವಿಳಾಸವನ್ನು ಪ್ರಾಕ್ಸಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಎಂದು ಪರಿಗಣಿಸಿದರೆ ಅದೇ ನಿರಾಕರಣೆ ಹೆಚ್ಚುವರಿ ಗೊಂದಲದ ಹೆಜ್ಜೆಯೊಂದಿಗೆ ಬರುತ್ತದೆ.

ಮಾರ್ಗವು handshake ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ

ವಿಳಾಸ ಸರಿಯಾಗಿದ್ದರೂ, ರೂಟಿಂಗ್ ಪ್ರಾಕ್ಸಿಂಗ್ ಅಲ್ಲ. HTTP ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕ CONNECT ವಿನಂತಿ ಅಥವಾ ಸಂಪೂರ್ಣ-ರೂಪದ ವಿನಂತಿ ಸಾಲಿನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು SOCKS ಪ್ರಾಕ್ಸಿ ಆವೃತ್ತಿ ಮತ್ತು ವಿಧಾನದ ಮಾತುಕತೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ರೂಟರ್ ಅಥವಾ ಓವರ್‌ಲೇ ಬೈಟ್‌ಗಳನ್ನು ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ; ಅದು ಆ ಸಂದೇಶಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವುದಿಲ್ಲ ಅಥವಾ ನಿಮಗಾಗಿ ಮುಂದಿನ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವುದಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ping ಮತ್ತು SSH ಗೆ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಬ್ರೌಸರ್ ಪ್ರಾಕ್ಸಿಗೆ ವಿಫಲವಾಗಬಹುದು: ಬ್ರೌಸರ್‌ಗೆ ಸಹಕರಿಸುವ ಪ್ರಕ್ರಿಯೆ ಬೇಕು, ಕೇವಲ ತಲುಪುವಿಕೆ ಅಲ್ಲ.

ಗುರಿ ಕೇವಲ ಪೀರ್‌ನಲ್ಲಿನ ಸೇವೆಯನ್ನು ತಲುಪುವುದಾದರೆ, ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ತೆಗೆದು ಸೇವೆಯ ಓವರ್‌ಲೇ ವಿಳಾಸವನ್ನು ನೇರವಾಗಿ ಬಳಸಿ.

ಮಿತಿಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪರೀಕ್ಷಿಸಿ

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

N2N ಯೋಜನೆ ಎಡ್ಜ್‌ಗಳು ಮತ್ತು ಸೂಪರ್‌ನೋಡ್‌ಗಳನ್ನು ಓವರ್‌ಲೇ ಘಟಕಗಳಾಗಿ ದಾಖಲಿಸುತ್ತದೆ. ಅದು ಎಡ್ಜ್ ಅನ್ನು ಅನ್ವಯಿಕ ಪ್ರಾಕ್ಸಿಯಾಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ರೂಟಿಂಗ್ ಸಂರಚನೆ ಯಾರೂ ಪ್ರಾರಂಭಿಸದ ಪ್ರೋಟೋಕಾಲ್ ಹ್ಯಾಂಡ್ಲರ್ ಸೇರಿಸುವುದಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು