ಪೋರ್ಟ್ ಚೆಕರ್ ತೆರೆದಿದೆ ಎನ್ನುತ್ತದೆಯೇ? Minecraft ಆಟಗಾರರು ಇನ್ನೂ ಏಕೆ ಸೇರಲು ಸಾಧ್ಯವಿಲ್ಲ

ಯಾರೋ ಪೋರ್ಟ್ ಪರಿಶೀಲನೆ ನಡೆಸುತ್ತಾರೆ, ತೆರೆದಿದೆ ಎಂಬ ಪದವನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಸರ್ವರ್ ಬಗೆಹರಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಆ ಫಲಿತಾಂಶದ ನಿಜವಾದ ಅರ್ಥ ಸೀಮಿತವಾಗಿದೆ: ಚೆಕರ್ನ ಸ್ಥಳದಿಂದ, ಆ ಕ್ಷಣದಲ್ಲಿ, ಆ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ಗೆ TCP ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿತ್ತು. ಇದು Minecraft ಪ್ರೋಟೋಕಾಲ್ ಕೈಕುಲುಕು, ಖಾತೆ ದೃಢೀಕರಣ, ಅಥವಾ ಸರ್ವರ್ ಆಟಗಾರನನ್ನು ಜಗತ್ತಿಗೆ ಸೇರಿಸಿತೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

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

ಪ್ರೋಬ್ ತಾನು ನೋಡಬಲ್ಲದನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸುತ್ತದೆ

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

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

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

ಸಾಕೆಟ್ ಮತ್ತು ಆಟಗಾರನ ನಡುವೆ ನಾಲ್ಕು ಪದರಗಳು

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

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

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

ಒಳಗಿನ ಆಟಗಾರ ಏಕೆ ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ

ಅದೇ LAN ನಲ್ಲಿರುವ ಅಥವಾ ಆ LAN ತಲುಪುವ VPN ನಲ್ಲಿರುವ ಆಟಗಾರ ಒಳಗಿನಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ತಲುಪಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ. ವಿನಂತಿ ರೌಟರ್ನ ಬಾಹ್ಯ ವಿಳಾಸಕ್ಕೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ರೌಟರ್ ಅದನ್ನು ಮತ್ತೆ ಒಳಕ್ಕೆ ಅನುವಾದಿಸಬೇಕು, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ hairpinning ಅಥವಾ NAT ಪ್ರತಿಫಲನ ಎನ್ನುತ್ತಾರೆ. ಇದು ಕೆಲಸ ಮಾಡಲು ಮುಂದಿನ ಅನುವಾದ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಎರಡೂ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಮತ್ತು ಅನೇಕ ಗ್ರಾಹಕ ರೌಟರ್ಗಳು ಇದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಹೊರಗಿನ ಅತಿಥಿ ಸೇರುತ್ತಾನೆ ಮತ್ತು ಸರ್ವರ್ ಪಕ್ಕ ಕುಳಿತ ವ್ಯಕ್ತಿ ಸೇರಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬಾಹ್ಯ ಮಾರ್ಗ ನಿಜವಾಗಿಯೂ ಸರಿಯಾಗಿದೆ; ಒಳಗಿನ ಸುತ್ತುದಾರಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಅದು ಆಟಗಾರನ ಪರದೆಯಿಂದ ಸರ್ವರ್ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಯಾವುದು ಸಂಭವಿಸಿತು ಎಂದು ಸರ್ವರ್ನ ಸ್ವಂತ ಲಾಗ್ ನಿರ್ಧರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಎಂದೂ ಅನುವಾದವಾಗದ ಸಂಪರ್ಕ ಅದನ್ನು ತಲುಪುವುದೇ ಇಲ್ಲ.

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

Netgate ನ NAT ಪ್ರತಿಫಲನ ದಸ್ತಾವೇಜು ಬಾಹ್ಯ ಮತ್ತು ಒಳಗಿನ ವ್ಯತ್ಯಾಸ ಮತ್ತು split-DNS ಪರ್ಯಾಯವನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಅದನ್ನು ಕಾರ್ಯವಿಧಾನದ ವಿವರಣೆಯಾಗಿ ಓದಿ, ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ VPN ಪೂರೈಕೆದಾರ ಅಥವಾ ರೌಟರ್ ಎಲ್ಲಾ loopback ಬಗೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬ ಭರವಸೆಯಾಗಿ ಅಲ್ಲ.

ಪ್ರತಿ ದೃಷ್ಟಿಕೋನದಿಂದ ಸಾಕ್ಷ್ಯ ಸಂಗ್ರಹಿಸಿ

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

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