Minecraft caur VPN: kura adrese jāliek serveru sarakstā?

VPN galapunkta ievadīšana Minecraft serveru sarakstā šķiet loģiska un katru reizi neizdodas, jo šī adrese izbeidz tuneli, nevis mitina spēli. Spēlētājam, kas pieslēdzies tam pašam VPN, jau ir ceļš uz spēles hostu, tāpēc ierakstā jānorāda hosts un ports, kurā spēle klausās. Izlabojiet šos divus un pārējā problēma būs parasta pakalpojuma sasniedzamība, daudz īsāks kontrolsaraksts, nekā šķiet sākumā.

Divas adreses, divi uzdevumi

Viena adrese ir publiska infrastruktūra: transporta galapunkts, kas pārvadā šifrētas paketes starp vienaudžiem. Otra ir privāta adrese mašīnai, kas darbina īpašo serveri. Tās nav savstarpēji aizvietojamas, un vienas aizstāšana ar otru rada atteiktu savienojumu vai taimautu, kas izskatās kā ugunsmūra problēma.

Ar noklusējuma portu spēlētājs ieraksta 10.60.0.20:25565 un neko citu. Mojang Java servera lejupielādes lapa norāda 25565 kā noklusējuma portu, un servera operatoram, kurš nomainīja portu, ir jātic, nevis jāšaubās pēc vecas mācības.

Padariet šo adresi par īstu pakalpojumu

Sasniedzama adrese ir nepieciešama un nepietiekama. Īpašajam serverim jādarbojas, jābūt saderīgam ar versiju, ko darbina spēlētāja klients, un jāklausās adresē, uz kuru tunelis var piegādāt. Process, kas piesaistīts tikai loopback, nekļūst sasniedzams tāpēc, ka kāds mašīnai pievienoja vēl vienu adresi.

Apstipriniet klausītāju pirms ugunsmūra aizskaršanas:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

Pirmā rinda parāda, kam process patiešām piesaistījās, bet otrā – vai vienaudzis var pabeigt TCP rokasspiedienu. Kad piesaiste ir 127.0.0.1, nekāds VPN konfigurācijas apjoms nemaina rezultātu, un šī vienīgā detaļa izskaidro pārsteidzoši daudz ziņojumu «VPN ir salūzis».

Vienaudžu politika, ugunsmūris un atgriešanās ceļš

Virs klausītāja ir divi atļauju jautājumi. VPN vienaudžu konfigurācijai jāļauj datplūsma starp diviem vienaudžiem, un spēles hosta ugunsmūrim jāpieņem spēles ports no šī vienaudža. Turiet abus ierobežotus ar spēles pakalpojumu un atļautajiem vienaudžiem, nevis izslēdziet hosta ugunsmūri, kas divu rindu noteikumu apmaina pret daudz lielāku problēmu. Šauri noteikumi ir arī vienīgā šī versija, kas iztur drošības pārbaudi bez vienas rindkopas pamatojuma.

Pēc tam atcerieties, ko pierāda veiksmīgs ping. VPN vārtejas sasniegšana vai atbildes saņemšana no spēles hosta pierāda tikai to, ka ICMP ir šķērsojis ceļu. Spēles savienojumam vajag konkrēto portu atvērtu abos virzienos, un atgriešanās ceļš ir tikpat svarīgs kā izejošais.

Kad serveris atrodas aiz vārtejas

Iepriekšējā piemērā spēles serveris ir vienaudzis, kas adrešu plānu tur vienkāršu. Ja serveris tā vietā atrodas LAN tīklā aiz VPN vārtejas, spēlētājam vajag maršrutējamu servera privāto adresi, vārtejai jābūt konfigurētai pāradresācijai šim LAN tīklam, un LAN hostam vajag atgriešanās maršrutu uz tunelēto klientu. Ja atgriešanās ceļš tiek palaists garām, rokasspiediens mirst pusceļā, un tas ir mulsinošākais no trim bojājumiem.

Nekopējiet piemēra vienaudža adresi uz citu mašīnu, lai atdarinātu šo topoloģiju. Adreses piemērā apraksta lomas, un vienas adreses izmantošana divās lomās rada pārklāšanos, ko maršrutēšana nevar atrisināt.

Atklāšana, konti un ko nemainīt

Automātiskā LAN atklāšana ir ērtība, kas balstīta uz paziņojumiem. Maršrutētam VPN nav jāpārvadā šie apraides pakešu sūtījumi, tāpēc trūkstošs ieraksts LAN sarakstā neko nepasaka par to, vai skaidrā privātā adrese darbojas. Ierakstiet adresi un tad spriediet. Ja savienojas, atklāšanas robs ir lietojamības neērtība, nevis bojājums, un to var dokumentēt tāpat, nevis izmeklēt.

Saglabājiet neskartu arī spēles parasto konta autentifikāciju un uzņemšanas politiku. Strādājošs privātais maršruts dod ceļu, nevis dalību, un nekāda adaptera prioritāšu pārkārtošana neaizstāj tā galamērķa noteikšanu, kuru klientam vajadzētu izmantot.