Nebula punchy ಸೆಟ್ಟಿಂಗ್ಗಳು: ಯಾವುದು ನಿಮ್ಮ NAT ಸರಿಪಡಿಸುತ್ತದೆ

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

ಸಮಯಕ್ಕಿಂತ ಮೊದಲು ಎಂಡ್ಪಾಯಿಂಟ್ ದೃಢೀಕರಿಸಿ

ನಿರೀಕ್ಷಿತ ವಿಳಾಸದಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣಿಸದ ಪಿಯರ್ ಅನ್ನು punch ಟ್ಯೂನಿಂಗ್ ಕಾಪಾಡುವುದಿಲ್ಲ. ದೀಪಸ್ತಂಭವು ಪಿಯರ್ ಬಗ್ಗೆ ಏನು ತಿಳಿದಿದೆ ಮತ್ತು ಪಿಯರ್ನ ಸ್ವಂತ ಸಂರಚನೆ ಏನು ಘೋಷಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹಳೆಯ bootstrap ವಿಳಾಸ ಅಥವಾ ತಪ್ಪಾಗಿ ಪ್ರಕಟವಾದ ಖಾಸಗಿ ವಿಳಾಸ ಪ್ರತಿಯೊಂದು ದಾಟುವ ಉಪಾಯವನ್ನೂ ವಿಫಲಗೊಳಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರವು ನಂಬಲರ್ಹವಾಗಿದೆಯೇ ಎಂದೂ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ನಂಬಲರ್ಹವಲ್ಲದ ಗುರುತು NAT ಮುಖ್ಯವಾಗುವ ಬಹಳ ಮೊದಲೇ ಸಂಭಾಷಣೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ನಂತರ UDP ದೀಪಸ್ತಂಭವನ್ನು ತಲುಪುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಸಮಯದ ಮೌಲ್ಯಗಳನ್ನು ಕೊನೆಯದಾಗಿ ನೋಡಬೇಕು, ಮೊದಲಾಗಿ ಅಲ್ಲ.

ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಜೋಡಿಯನ್ನು ಬರೆದಿಡಿ, ನಂತರದ ಹೋಲಿಕೆಗಳು ಎರಡು ಬೇರೆ ಯಂತ್ರಗಳ ಬದಲು ಅದೇ ಪಿಯರ್ಗಳನ್ನು ಬಳಸುವಂತೆ.

punch ಮ್ಯಾಪಿಂಗ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, respond ದಿಕ್ಕನ್ನು ತೆರೆಯುತ್ತದೆ

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

ನೇರ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡಿ ನಂತರ ಕ್ಷೀಣಿಸಿದರೆ punch ಆರಿಸಿ. ಮಾರ್ಗ ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಎಂದಿಗೂ ರೂಪುಗೊಳ್ಳದಿದ್ದರೆ respond ಆರಿಸಿ. ಎರಡನ್ನೂ ಆನ್ ಮಾಡಿ ನಿರೀಕ್ಷಿಸುವುದು ಐದು ನಿಮಿಷದ ಸರಿಪಡಿಸುವಿಕೆಯನ್ನು ಒಂದು ವಾರದ ಟ್ಯೂನಿಂಗ್ ಆಗಿ ಮಾಡುವ ದಾರಿ.

ವಿಳಂಬಗಳು ಯಾವಾಗ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಆಗುತ್ತದೆಯೇ ಎಂಬುದನ್ನಲ್ಲ

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

ಕಾರ್ಯವಿಧಾನ ಸರಿಯಾಗುವವರೆಗೆ ಅವನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ. ನಂತರ ಒಂದನ್ನು ಸರಿಹೊಂದಿಸಿ, ಮತ್ತು ಹಳೆಯ ಮೌಲ್ಯವನ್ನು ಬರೆದಿಡಿ.

ರಿಲೇ ಪ್ರಾಮಾಣಿಕ ಉತ್ತರವಾದಾಗ

ಕೆಲವು NAT ಸಂಯೋಜನೆಗಳು ಸಮಯವನ್ನು ಹೇಗೇ ಜೋಡಿಸಿದರೂ ನೇರ ಮಾರ್ಗವನ್ನು ಬೆಂಬಲಿಸಲಾರವು. ಎರಡೂ ಕಡೆ ಸಮಪ್ರಮಾಣ NAT, ಅಥವಾ ಕೇಳದೆ ಬರುವ ಒಳಹರಿವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಸಾಡುವ ಫೈರ್ವಾಲ್, ಚುಚ್ಚಲು ಏನನ್ನೂ ಬಿಡುವುದಿಲ್ಲ.

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

ವಿಫಲವಾದ ಜೋಡಿಯನ್ನು ನಿಷ್ಕ್ರಿಯತೆಯ ನಂತರ ಪರೀಕ್ಷಿಸಿ

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

ಯಾವ ಸೆಟ್ಟಿಂಗ್ ಬದಲಾಯಿತು, ಸಮಯ, ಮತ್ತು ನೇರ ಮಾರ್ಗ ಬಂತೇ ಅಥವಾ ಸಂಚಾರ ರಿಲೇಯಲ್ಲೇ ಉಳಿಯಿತೇ ಎಂದು ಬರೆಯಿರಿ. ಉಳಿದಿದ್ದರೆ ಉತ್ತರ ರಿಲೇ ಮತ್ತು ಸಾಮರ್ಥ್ಯದ ಟಿಪ್ಪಣಿ, ಮತ್ತು ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಒಳ್ಳೆಯ ಫಲಿತಾಂಶ. ಬಂದಿದ್ದರೆ ಮುಂದಿನ ಪ್ರಶ್ನೆ ಅದು ಒಂದು ಗಂಟೆಯ ನಿಷ್ಕ್ರಿಯತೆಯನ್ನು ತಾಳುತ್ತದೆಯೇ ಎಂಬುದು, ಏಕೆಂದರೆ ಕ್ಷೀಣಿಸುವ ಮ್ಯಾಪಿಂಗ್ punch ಇರುವುದಕ್ಕೆ ಕಾರಣವಾದ ಸಮಸ್ಯೆಯೇ.