Minecraft per VPN: kiu adreso iras en la servilan liston?

Tajpi la VPN-finpunkton en la servilan liston de Minecraft ŝajnas logike kaj malsukcesas ĉiufoje, ĉar tiu adreso finas la tunelon anstataŭ gastigi la ludon. Ludanto aliĝinta al la sama VPN jam havas vojon al la luda gastiganto, do la enskribo devas nomi la gastiganton kaj la pordon, sur kiu la ludo aŭskultas. Ĝustigu tiujn du kaj la resto de la problemo estas ordinara servoatingebleco, multe pli mallonga kontrol-listo ol ĝi unue ŝajnas.

Du adresoj, du taskoj

Unu adreso estas publika infrastrukturo: la transporta finpunkto, kiu portas ĉifritajn pakojn inter samtavoloj. La alia estas privata adreso de la maŝino, kiu funkciigas la dediĉitan servilon. Ili ne estas interŝanĝeblaj, kaj anstataŭigi unu per la alia produktas rifuzitan konekton aŭ tempolimon, kiu aspektas kiel fajroŝirma problemo.

Kun la defaŭlta pordo, la ludanto tajpas 10.60.0.20:25565 kaj nenion alian. La elŝuta paĝo de Mojang por la Java-servilo nomas 25565 la defaŭlta, kaj al servila operatoro, kiu ŝanĝis la pordon, oni devas kredi anstataŭ dubi laŭ malnova lernilo.

Faru tiun adreson vera servo

Atingebla adreso estas necesa kaj ne sufiĉa. La dediĉita servilo devas funkcii, devas esti kongrua kun la versio, kiun rulas la kliento de la ludanto, kaj devas aŭskulti sur adreso, al kiu la tunelo povas liveri. Procezo ligita nur al loopback ne fariĝas atingebla ĉar iu aldonis alian adreson al la maŝino.

Konfirmu la aŭskultanton antaŭ ol tuŝi fajroŝirmilon:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

La unua linio montras, al kio la procezo efektive ligiĝis, kaj la dua montras, ĉu samtavolo povas fini TCP-manpremon. Kiam la ligo estas 127.0.0.1, nenia kvanto da VPN-agordo ŝanĝas la rezulton, kaj tiu unu detalo klarigas surprizan nombron da raportoj «la VPN rompiĝis».

Samtavola politiko, fajroŝirmilo kaj la revena vojo

Du permesaj demandoj sidas super la aŭskultanto. La samtavola agordo de la VPN devas permesi trafikon inter la du samtavoloj, kaj la fajroŝirmilo de la luda gastiganto devas akcepti la ludan pordon de tiu samtavolo. Tenu ambaŭ limigitaj al la luda servo kaj la rajtigitaj samtavoloj anstataŭ malŝalti la fajroŝirmilon de la gastiganto, kio interŝanĝas du-linian regulon kontraŭ multe pli granda problemo. Mallarĝaj reguloj estas ankaŭ la sola versio de tio, kiu trapasas sekurecan revizion sen alineo da pravigo.

Poste memoru, kion pruvas sukcesa ping. Atingi la VPN-pordegon aŭ ricevi respondon de la luda gastiganto nur montras, ke ICMP trapasis la vojon. Luda konekto bezonas la specifan pordon malfermita en ambaŭ direktojn, kaj la revena vojo gravas same kiel la elira.

Kiam la servilo staras malantaŭ la pordego

La supra ekzemplo havas la ludan servilon kiel samtavolon, kio tenas la adresan planon simpla. Se la servilo anstataŭe loĝas en LAN malantaŭ VPN-pordego, la ludanto bezonas la itineran privatan adreson de la servilo, la pordego bezonas konfiguritan plusendadon por tiu LAN, kaj la gastiganto en la LAN bezonas itineron reen al la tunela kliento. Manku la revena vojo kaj la manpremo mortas duonvoje, kio estas la plej konfuza el la tri fiaskoj.

Ne kopiu la ekzemplan samtavolan adreson al alia maŝino por imiti tiun ĉi topologion. Adresoj en ekzemplo priskribas rolojn, kaj reuzi unu en du roloj kreas koincidon, kiun itinrado ne povas solvi.

Malkovro, kontoj kaj kion ne ŝanĝi

Aŭtomata LAN-trovo estas komforto konstruita sur anoncoj. Itinita VPN ne devas porti tiujn dissendojn, do mankanta enskribo en la LAN-listo diras nenion pri tio, ĉu la eksplicita privata adreso funkcias. Tajpu la adreson, poste juĝu. Se ĝi konektas, la trovmaniko estas ĝenaĵo de uzebleco, ne difekto, kaj ĝi povas esti dokumentita tiel anstataŭ esplorita.

Konservu ankaŭ sendifekta la normalan kontan aŭtentikigon kaj akceptpolitikon de la ludo. Funkcianta privata itinero donas vojon, ne membrecon, kaj nenia reorganizado de adaptilaj prioritatoj anstataŭas identigi la celon, kiun la kliento devus uzi.