Minecraft VPN ಮೂಲಕ: ಸರ್ವರ್ ಪಟ್ಟಿಗೆ ಯಾವ ವಿಳಾಸ ಹೋಗುತ್ತದೆ?

Minecraft ನ ಸರ್ವರ್ ಪಟ್ಟಿಗೆ VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಟೈಪ್ ಮಾಡುವುದು ತಾರ್ಕಿಕವೆನಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಬಾರಿಯೂ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಆ ವಿಳಾಸವು ಸುರಂಗವನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ, ಆಟವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವುದಿಲ್ಲ. ಅದೇ VPN ಗೆ ಸೇರಿದ ಆಟಗಾರನಿಗೆ ಈಗಾಗಲೇ ಆಟದ ಹೋಸ್ಟ್ಗೆ ಮಾರ್ಗವಿದೆ, ಆದ್ದರಿಂದ ನಮೂದು ಹೋಸ್ಟ್ ಮತ್ತು ಆಟವು ಆಲಿಸುವ ಪೋರ್ಟ್ ಅನ್ನು ಹೆಸರಿಸಬೇಕು. ಈ ಎರಡನ್ನು ಸರಿಪಡಿಸಿದರೆ ಉಳಿದ ಸಮಸ್ಯೆ ಸಾಮಾನ್ಯ ಸೇವಾ-ತಲುಪುವಿಕೆ, ಇದು ಮೊದಲಿಗೆ ತೋರುವುದಕ್ಕಿಂತ ಬಹಳ ಚಿಕ್ಕ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ.

ಎರಡು ವಿಳಾಸಗಳು, ಎರಡು ಕೆಲಸಗಳು

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

ಡೀಫಾಲ್ಟ್ ಪೋರ್ಟ್ನೊಂದಿಗೆ, ಆಟಗಾರ 10.60.0.20:25565 ಎಂದು ಟೈಪ್ ಮಾಡುತ್ತಾನೆ ಮತ್ತು ಬೇರೇನೂ ಇಲ್ಲ. Mojang ನ Java ಸರ್ವರ್ ಡೌನ್ಲೋಡ್ ಪುಟವು 25565 ಅನ್ನು ಡೀಫಾಲ್ಟ್ ಎಂದು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಪೋರ್ಟ್ ಬದಲಿಸಿದ ಸರ್ವರ್ ಆಪರೇಟರ್ ಅನ್ನು ಹಳೆಯ ಟ್ಯುಟೋರಿಯಲ್ನಿಂದ ಸಂದೇಹಿಸುವ ಬದಲು ನಂಬಬೇಕು.

ಆ ವಿಳಾಸವನ್ನು ನಿಜವಾದ ಸೇವೆಯನ್ನಾಗಿಸಿ

ತಲುಪಬಹುದಾದ ವಿಳಾಸ ಅಗತ್ಯ ಮತ್ತು ಸಾಕಾಗದು. ಮೀಸಲಾದ ಸರ್ವರ್ ಚಾಲನೆಯಲ್ಲಿರಬೇಕು, ಆಟಗಾರನ ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸುವ ಆವೃತ್ತಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಮತ್ತು ಸುರಂಗವು ತಲುಪಿಸಬಲ್ಲ ವಿಳಾಸದಲ್ಲಿ ಆಲಿಸಬೇಕು. loopback ಗೆ ಮಾತ್ರ ಬಂಧಿಸಲಾದ ಪ್ರಕ್ರಿಯೆಯು ಯಾರೋ ಯಂತ್ರಕ್ಕೆ ಇನ್ನೊಂದು ವಿಳಾಸ ಸೇರಿಸಿದ್ದರಿಂದ ತಲುಪಬಹುದಾದದ್ದಾಗುವುದಿಲ್ಲ.

ಫೈರ್ವಾಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಆಲಿಸುವವರನ್ನು ಖಚಿತಪಡಿಸಿ:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

ಮೊದಲ ಸಾಲು ಪ್ರಕ್ರಿಯೆಯು ವಾಸ್ತವವಾಗಿ ಯಾವುದಕ್ಕೆ ಬಂಧಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಸಹವರ್ತಿ TCP ಕೈಕುಲುಕುವಿಕೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಬಹುದೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಬಂಧನ 127.0.0.1 ಆಗಿದ್ದಾಗ, VPN ಸಂರಚನೆಯ ಯಾವುದೇ ಪ್ರಮಾಣವೂ ಫಲಿತಾಂಶವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಒಂದೇ ವಿವರವು «VPN ಮುರಿದಿದೆ» ಎಂಬ ಆಶ್ಚರ್ಯಕರ ಸಂಖ್ಯೆಯ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಸಹವರ್ತಿ ನೀತಿ, ಫೈರ್ವಾಲ್ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ

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

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

ಸರ್ವರ್ ಗೇಟ್ವೇ ಹಿಂದೆ ಇದ್ದಾಗ

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

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

ಅನ್ವೇಷಣೆ, ಖಾತೆಗಳು ಮತ್ತು ಏನನ್ನು ಬದಲಾಯಿಸಬಾರದು

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

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