Minecraft per VPN: kuris adresas rašomas serverių sąraše?

Rašyti VPN galinį tašką į Minecraft serverių sąrašą atrodo logiška ir kaskart nepavyksta, nes tas adresas užbaigia tunelį, o ne talpina žaidimą. Žaidėjas, prisijungęs prie to paties VPN, jau turi kelią iki žaidimo hosto, todėl įrašas turi nurodyti hostą ir prievadą, kuriuo klausosi žaidimas. Sutvarkykite šiuos du dalykus ir likusi problema bus įprastas paslaugos pasiekiamumas, daug trumpesnis kontrolinis sąrašas, nei atrodo iš pradžių.

Du adresai, du darbai

Vienas adresas yra viešoji infrastruktūra: transporto galinis taškas, kuris perneša šifruotus paketus tarp lygiaverčių mazgų. Kitas yra privatus adresas mašinos, kuri paleidžia dedikuotą serverį. Jie nėra keičiami, o vieną pakeitus kitu gaunamas atmestas ryšys arba laukimo pabaiga, kuri atrodo kaip užkardos problema.

Su numatytuoju prievadu žaidėjas įrašo 10.60.0.20:25565 ir nieko daugiau. Mojang Java serverio atsisiuntimo puslapis nurodo 25565 kaip numatytąjį, o serverio operatoriumi, kuris pakeitė prievadą, reikia tikėti, o ne abejoti pagal seną pamoką.

Padarykite tą adresą tikra paslauga

Pasiekiamas adresas yra būtinas ir nepakankamas. Dedikuotas serveris turi veikti, būti suderinamas su versija, kurią paleidžia žaidėjo klientas, ir klausytis adreso, į kurį tunelis gali pristatyti. Procesas, susietas tik su loopback, netampa pasiekiamas todėl, kad kas nors pridėjo mašinai kitą adresą.

Patvirtinkite klausytoją prieš liesdami užkardą:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Pirmoji eilutė rodo, prie ko procesas iš tikrųjų prisirišo, o antroji – ar lygiavertis mazgas gali užbaigti TCP rankos paspaudimą. Kai susiejimas yra 127.0.0.1, jokia VPN konfigūracijos apimtis nekeičia rezultato, ir ši viena detalė paaiškina stebėtinai daug pranešimų „VPN sugedo“.

Mazgų politika, užkarda ir grįžimo kelias

Virš klausytojo yra du leidimų klausimai. VPN lygiaverčių mazgų konfigūracija turi leisti srautą tarp dviejų mazgų, o žaidimo hosto užkarda turi priimti žaidimo prievadą iš to mazgo. Laikykite abu apribotus žaidimo paslauga ir įgaliotais mazgais, o ne išjunkite hosto užkardą, kuri dviejų eilučių taisyklę iškeičia į daug didesnę problemą. Siauros taisyklės taip pat yra vienintelė to versija, kuri praeina saugumo peržiūrą be pastraipos pagrindimo.

Tada prisiminkite, ką įrodo sėkmingas ping. Pasiekti VPN šliuzą arba gauti atsakymą iš žaidimo hosto rodo tik tai, kad ICMP perėjo kelią. Žaidimo ryšiui reikia, kad konkretus prievadas būtų atidarytas abiem kryptimis, o grįžimo kelias toks pat svarbus kaip išėjimo.

Kai serveris stovi už šliuzo

Aukščiau pateiktame pavyzdyje žaidimo serveris yra lygiavertis mazgas, todėl adresų planas lieka paprastas. Jei serveris vietoj to yra LAN tinkle už VPN šliuzo, žaidėjui reikia maršrutizuojamo privataus serverio adreso, šliuzui reikia konfigūruoto persiuntimo tam LAN tinklui, o LAN hostui reikia grįžimo maršruto link tuneliuojamo kliento. Praleiskite grįžimo kelią ir rankos paspaudimas miršta pusiaukelėje, o tai yra pati painiausia iš trijų klaidų.

Nekopijuokite pavyzdžio mazgo adreso į kitą mašiną, kad imituotumėte šią topologiją. Adresai pavyzdyje apibūdina vaidmenis, o vieno adreso naudojimas dviem vaidmenimis sukuria persidengimą, kurio maršrutizavimas negali išspręsti.

Aptikimas, paskyros ir ko nekeisti

Automatinis LAN aptikimas yra patogumas, pastatytas ant pranešimų. Maršrutizuotam VPN nereikia perduoti tų transliacijų, todėl trūkstamas įrašas LAN sąraše nieko nesako apie tai, ar aiškus privatus adresas veikia. Įrašykite adresą ir tada vertinkite. Jei prisijungia, aptikimo spraga yra naudojimo nepatogumas, o ne gedimas, ir ją galima taip dokumentuoti, o ne tirti.

Išsaugokite ir įprastą žaidimo paskyros autentifikavimą bei priėmimo politiką. Veikiantis privatus maršrutas suteikia kelią, o ne narystę, ir joks adapterio prioritetų pertvarkymas nepakeičia paskirties, kurią klientas turėtų naudoti, nustatymo.