Minecraft VPN દ્વારા: સર્વર યાદીમાં કયું સરનામું જાય છે?
VPN એન્ડપોઇન્ટ ટનલ બનાવે છે; રમતને હોસ્ટનું ખાનગી સરનામું અને પોર્ટ જોઈએ. ભૂમિકાઓને સરનામાં સાથે જોડો, પછી શ્રોતા, માર્ગ અને હોસ્ટ નિયમો તપાસો.
Minecraft ની સર્વર યાદીમાં VPN એન્ડપોઇન્ટ લખવું તાર્કિક લાગે છે અને દરેક વખતે નિષ્ફળ જાય છે, કારણ કે તે સરનામું ટનલ સમાપ્ત કરે છે, રમતનું હોસ્ટિંગ કરતું નથી. તે જ VPN સાથે જોડાયેલા ખેલાડી પાસે પહેલેથી રમતના હોસ્ટ સુધીનો માર્ગ છે, તેથી એન્ટ્રીએ હોસ્ટ અને જે પોર્ટ પર રમત સાંભળે છે તે જણાવવું જોઈએ. આ બે સાચા કરો અને બાકીની સમસ્યા સામાન્ય સેવા-પ્રાપ્યતા છે, જે પ્રથમ નજરે લાગે તે કરતાં ઘણી ટૂંકી ચેકલિસ્ટ છે.
બે સરનામાં, બે કામ
એક સરનામું જાહેર ઇન્ફ્રાસ્ટ્રક્ચર છે: પીઅર્સ વચ્ચે એન્ક્રિપ્ટેડ પેકેટ લઈ જતું ટ્રાન્સપોર્ટ એન્ડપોઇન્ટ. બીજું સમર્પિત સર્વર ચલાવતા મશીનનું ખાનગી સરનામું છે. તે અદલાબદલી કરી શકાય તેવા નથી, અને એકને બીજા સાથે બદલવાથી કનેક્શન નકારવામાં આવે છે અથવા ફાયરવોલ સમસ્યા જેવો દેખાતો ટાઇમઆઉટ થાય છે.
| Role | Address | Where it belongs |
|---|---|---|
| Public transport endpoint | 203.0.113.40 | VPN client configuration, never the game |
| Game host on the VPN | 10.60.0.20 | Server address field, with the port |
| Player peer | 10.60.0.30 | Assigned by the tunnel, nothing to type |
ડિફોલ્ટ પોર્ટ સાથે, ખેલાડી 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 યાદીમાં એન્ટ્રી ન હોવી એ વિશે કંઈ કહેતું નથી કે સ્પષ્ટ ખાનગી સરનામું કામ કરે છે કે નહીં. સરનામું લખો, પછી ન્યાય કરો. જો જોડાય તો શોધની ખાલી જગ્યા ઉપયોગિતાની તકલીફ છે, ખામી નથી, અને તપાસ કરવાને બદલે તેને તે રીતે દસ્તાવેજીકૃત કરી શકાય છે.
રમતની સામાન્ય એકાઉન્ટ પ્રમાણીકરણ અને પ્રવેશ નીતિ પણ અકબંધ રાખો. કામ કરતો ખાનગી માર્ગ માર્ગ આપે છે, સભ્યપદ નહીં, અને એડેપ્ટર પ્રાથમિકતાનું મિશ્રણ ક્લાયન્ટે વાપરવાનું લક્ષ્ય ઓળખવાનું સ્થાન લેતું નથી.