OpenVPN ಮೇಲೆ ಖಾಲಿ LAN ಗೇಮ್ ಪಟ್ಟಿ? ಶೋಧನೆಯ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ಸೆಷನ್ಗೆ ಸೇರುವುದನ್ನು ಅದನ್ನು ಕಂಡುಹಿಡಿಯುವುದರಿಂದ ಬೇರ್ಪಡಿಸಿ

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

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

ಟನೆಲ್ ಮುಟ್ಟುವ ಮೊದಲು ನೇರ ಸೇರುವಿಕೆಯನ್ನು ಪ್ರಯತ್ನಿಸಿ

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

ಶೋಧನಾ ಪೋರ್ಟ್ ಮತ್ತು ಸೆಷನ್ ಪೋರ್ಟ್ ಒಂದೇ ಸಂಖ್ಯೆ ಎಂದು ಭಾವಿಸಬೇಡಿ. ಗೇಮ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು UDP ಪೋರ್ಟ್ನಲ್ಲಿ ಘೋಷಿಸಿ ಇನ್ನೊಂದರಲ್ಲಿ ಆಟಗಾರರನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಮತ್ತು ತಪ್ಪು ಪೋರ್ಟ್ಗಾಗಿ ನಿರ್ಮಿಸಿದ ರಿಲೇ ಖಾಲಿಯಾಗಿಯೇ ಉಳಿಯುವ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ.

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

ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ

ರೂಟ್ ಮಾಡಿದ TUN ಟನೆಲ್ ಪೀರ್ಗಳ ನಡುವೆ IP ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಪೀರ್ನ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಸ್ಥಳೀಯ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಸೀಮಿತ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ವಿಳಾಸ 255.255.255.255 ಅದನ್ನು ಹೊರಡಿಸುವ ಇಂಟರ್ಫೇಸ್ ಒಳಗೇ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಸಬ್ನೆಟ್ಗೆ ನಿರ್ದೇಶಿತ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಪ್ರತ್ಯೇಕ ಪ್ರಕರಣ, ರೌಟರ್ಗಳು ಘೋಷಣೆಗಳನ್ನು ಪ್ರವಾಹ ಮಾಡಲು ಸಾಮಾನ್ಯ ಪರವಾನಗಿ ಅಲ್ಲ.

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

ಮಲ್ಟಿಕಾಸ್ಟ್ ಶೋಧನೆಗೆ ಬೇರೆ ವಿಳಾಸ ವರ್ಗದೊಂದಿಗೆ ಅದೇ ಸಮಸ್ಯೆ ಇದೆ, ಮತ್ತು ಅದಕ್ಕೆ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ವಿನಾಯಿತಿಯ ಬದಲು ಮಲ್ಟಿಕಾಸ್ಟ್ ರೂಟಿಂಗ್ ಅಥವಾ ರಿಲೇ ಬೇಕು.

ರಿಲೇ ಸಮರ್ಥನೀಯವಾದಾಗ ಅದನ್ನು ಸಂಕುಚಿತವಾಗಿ ಇರಿಸಿ

ಸ್ವಯಂಚಾಲಿತ ಶೋಧನೆ ಅಗತ್ಯವಾದರೆ, ಮೊದಲು ನಿಜವಾದ ವಿನಿಮಯವನ್ನು ಗುರುತಿಸಿ: ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಅಥವಾ ಮಲ್ಟಿಕಾಸ್ಟ್, ಗಮ್ಯ ವಿಳಾಸ, UDP ಪೋರ್ಟ್, ಅದನ್ನು ಕಳುಹಿಸುವ ಇಂಟರ್ಫೇಸ್, ಮತ್ತು ಉತ್ತರದ ಒಳಗಿನ ವಿಳಾಸ. ಈ ಐದು ಸತ್ಯಗಳಿಗೆ ಸೀಮಿತವಾದ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಸೂಕ್ತವಾದ ರಿಲೇ ಇಡೀ Ethernet ವಿಭಾಗವನ್ನು ವಿಸ್ತರಿಸುವುದಕ್ಕಿಂತ ಬಹಳ ಸಂಕುಚಿತ.

ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬದಲಿಸದೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದು ಸಾಲದಾಗಬಹುದು. ಪೇಲೋಡ್ ಸ್ವೀಕರಿಸುವವರಿಗೆ ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸಲು ಹೇಳಿದರೆ, ರಿಲೇ ನಿರುಪಯುಕ್ತ ಉತ್ತರ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ರಿಲೇ ಇರುವ ಮೊದಲು ಗೇಮ್ನ ಸ್ವಂತ ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಘೋಷಿತ ವಿಳಾಸ ಸೆಟ್ಟಿಂಗ್ ಪ್ರಯತ್ನಿಸಬೇಕು.

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

ವಿನ್ಯಾಸಕ್ಕೆ Ethernet ಬೇಕಾದಾಗ ಮಾತ್ರ ಸೇತುವೆ ಮಾಡಿ

Ethernet ಫ್ರೇಮ್ಗಳು TAP ಒಳಗೆ ಚಲಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ TAP ಟನೆಲ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇತುವೆ ಮಾಡಿದ ಬ್ರಾಡ್ಕಾಸ್ಟ್ ಡೊಮೇನ್ಗೆ ಸೇರಬಹುದು. ಕೇವಲ dev tun ಅನ್ನು dev tap ಗೆ ಬದಲಿಸುವುದು ಆ ಸೇತುವೆಯನ್ನು ನಿರ್ಮಿಸುವುದಿಲ್ಲ, ಸರ್ವರ್ ಸಂರಚನೆಯನ್ನು ಹೊಂದಾಣಿಕೆಯಾಗಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಹೊಸ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುವಂತೆ ಮಾಡುವುದಿಲ್ಲ. OpenVPN ಸೇತುವೆ ಮಾರ್ಗದರ್ಶಿ ಒಂದು ಖಾಲಿ ಲಾಬಿಗೆ ಚಿಕಿತ್ಸೆ ಅಲ್ಲ, ವಿಶಾಲ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

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

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