Minecraft fia in VPN: hokker adres heart yn 'e serverlist?

It VPN-einpunt yn 'e serverlist fan Minecraft typje fielt logysk en mislearret elke kear, om't dat adres de tunnel einiget yn stee fan it spul te hosten. In spiler dy't oan deselde VPN ferbûn is, hat al in paad nei de host fan it spul, dus de ynfier moat de host en de poarte neame dêr't it spul op harket. Krij dy twa goed en de rest fan it probleem is gewoane tsjinstberikberens, in folle koartere checklist as't earst liket.

Twa adressen, twa taken

It iene adres is publike ynfrastruktuer: it transporteinpunt dat fersifere pakketten tusken peers draacht. It oare is in privee-adres fan 'e masine dy't de tawijde server draait. Se binne net útwikselber, en it iene troch it oare ferfange jout in wegere ferbining of in time-out dy't as in firewallprobleem liket.

Mei de standertpoarte typt de spiler 10.60.0.20:25565 en neat oars. Mojang syn Java-serverdownloadside neamt 25565 as standert, en in serverbehearder dy't de poarte feroare hat, moat men leauwe yn stee fan it út in âld hânlieding te betwifeljen.

Meitsje dat adres in echte tsjinst

In berikber adres is needsaaklik en net genôch. De tawijde server moat draaie, kompatibel wêze mei de ferzje dy't de klant fan 'e spiler draait, en harkje op in adres dêr't de tunnel nei leverje kin. In proses dat allinnich oan loopback bûn is, wurdt net berikber om't immen noch in adres oan 'e masine taheakke hat.

Befêstigje de listener foardat jo in firewall oanreitsje:

ss -lntp | grep 25565
nc -vz 10.60.0.20 25565

De earste rigel lit sjen wêr't it proses echt oan bûn is, en de twadde oft in peer in TCP-hânjaan foltôgje kin. As de bining 127.0.0.1 is, feroaret gjin inkele VPN-konfiguraasje de útkomst, en dat iene detail ferklearret in ferrassend oantal «de VPN is stikken»-rapporten.

Peerbelied, firewall en de weromwei

Twa tastimmingfragen sitte boppe de listener. De peer-konfiguraasje fan 'e VPN moat ferkear tusken de twa peers tastean, en de firewall fan 'e host fan it spul moat de spulpoarte fan dy peer akseptearje. Hâld beide beheind ta de tsjinst fan it spul en de autorisearre peers yn stee fan de firewall fan 'e host út te skeakeljen, wat in regel fan twa rigels foar in folle grutter probleem ferruilet. Nauwe regels binne ek de ienige ferzje hjirfan dy't in feilichheidsaudit oerlibbet sûnder in paragraaf rjochtfeardiging.

Tink dan oan wat in suksesfolle ping bewissiget. De VPN-gateway berikke, of antwurd fan 'e host fan it spul krije, lit allinnich sjen dat ICMP it paad krúst hat. In spulferbining hat de krekte poarte nedich dy't yn beide rjochtingen iepen is, en it werompaad jildt likefolle as it útgeande.

As de server efter de gateway stiet

Yn it foarbyld hjirboppe is de spulserver in peer, wat it adresplan ienfâldich hâldt. As de server yn stee op in LAN efter in VPN-gateway wennet, hat de spiler it routbere privee-adres fan 'e server nedich, moat de gateway trochstjoering foar dat LAN konfigurearre hawwe, en hat de LAN-host in rûte werom nei de tunnelklant nedich. Mist it werompaad en de hânjaan stjert healwei, wat de meast betiizjende fan 'e trije flaters is.

Kopiearje it peeradres fan it foarbyld net nei in oare masine om dizze topology nei te bearen. Adressen yn in foarbyld beskriuwe rollen, en ien oer twa rollen wergebrûke skept in oerlaap dy't routing net oplosse kin.

Untdekking, akkounts en wat net te feroarjen

Automatyske LAN-ûntdekking is in geriif boud op oankundigings. In routed VPN hoecht dy útstjoerings net te dragen, dus in ûntbrekkende ynfier yn 'e LAN-list seit neat oer oft it eksplisite privee-adres wurket. Typ it adres en oardielje dan. As it ferbynt, is it gat yn 'e ûntdekking in brûkberheidslas en gjin flater, en it kin as sadanich dokumintearre wurde yn stee fan ûndersocht.

Hâld ek de normale akkountautentikaasje en talittingsbelied fan it spul yntakt. In wurkjende privee-rûte jout in paad, gjin lidmaatskip, en gjin skommeljen mei adapterprioriteit ferfangt it identifisearjen fan 'e bestimming dy't de klant brûke moat.