KriegTiger Posted July 8, 2020 Share Posted July 8, 2020 New cluster setup - transfers work, but not travel I've run a dedicated server under linux for a while now (literally years). It was running on a wimpy little i5-3200 processor and 8gb 12gb memory. I recently upgraded hardware and got the server up again (i5-6600k, 32gb memory) and with the extra horsepower I was going to run a clustered setup. Everything seems to work fine - I can see both individual server instances in my lan/favorites filter, I can connect to each one individually just fine, and items/dinos dropped into monolith data/creature tabs appear on the counterpart system just fine. The problem I'm stuck at is that I have been utterly unable to use the 'travel to another server' function at the console or transmitter. Here's my setup: Server system: Single installation of ARK handling 2 instances (one set of Game.ini and GameUserSettings.ini, exclusive/whitelist file, etc. only launch options are different for map/session/port info, see below) IP - 192.168.1.4 Firewall - none ark1 startup options: (carriage returns inserted for readability) TheIsland?SessionName=HNP-Island?AltSaveDirectoryName=TheIsland?listen?MaxPlayers=10?QueryPort=27015?RCONPort=27020?Port=7777? ServerAutoForceRespawnWildDinosInterval=86400 -clusterid=HNPCluster -NoTransferFromFiltering -ClusterDirOverride=/home/arkserver -exclusivejoin -automanagedmods ark2 startup options: Valguero_P?SessionName=HNP-Valguero?AltSaveDirectoryName=Valguero_P?listen?MaxPlayers=10?QueryPort=27017?RCONPort=27022?Port=7779? ServerAutoForceRespawnWildDinosInterval=86400 -clusterid=HNPCluster -NoTransferFromFiltering -ClusterDirOverride=/home/arkserver -exclusivejoin -automanagedmods GameUserSettings.ini relevant options: [ServerSettings] CrossARKAllowForeignDinoDownloads=True noTributeDownloads=False PreventDownloadSurvivors=False PreventDownloadItems=False PreventDownloadDinos=False Client system (Me): standard windows desktop with steam/ark install IP - 192.168.1.17 WIndows Firewall normal settings, plays ARK with the dedicated server just fine - always has. All mods pre-downloaded and unpacked via single/local session Server favorites info: entered manually by IP:PORT to steam as favorites, no DNS to worry about shows in steam UI with map name, session name, etc all perfectly properly Been banging my head on this all night.. any ideas? All manner of searches I've tried here in the server admin forums get me no useful results, only a ton of advertisements for other peoples' clustered servers. Link to comment Share on other sites More sharing options...
IanHighlander Posted July 8, 2020 Share Posted July 8, 2020 If you're playing from the same network, you need all the relevant ports for both servers open in firewalls but also your firewall/router needs to support NAT Loopback as the connection effectively goes out and comes back in external when you transfer like that. Link to comment Share on other sites More sharing options...
KriegTiger Posted July 8, 2020 Author Share Posted July 8, 2020 36 minutes ago, IanHighlander said: If you're playing from the same network, you need all the relevant ports for both servers open in firewalls but also your firewall/router needs to support NAT Loopback as the connection effectively goes out and comes back in external when you transfer like that. You gave an answer, but not an explanation. The answer suggests that my server needs to be able to register with Steam/ARK's server list and be browseable in the 'unofficial' lists in order for transfers to work even though both instances are on the same physical machine, are connected to directly via local LAN connections, and bypasses their status as 'favorites' where they are listed by said local IP's (IE that the server is initiating the connection and not the client). This also suggests that you would be absolutely unable to play a clustered setup if you have no internet connection at all. Is that correct? Link to comment Share on other sites More sharing options...
Larkfields Posted July 8, 2020 Share Posted July 8, 2020 Have you port-forwarded ports 7777 to 7780 inclusive? Link to comment Share on other sites More sharing options...
Popiyopi Posted July 8, 2020 Share Posted July 8, 2020 Try add this lines to GameUserSettings.ini PreventUploadDinos=False PreventUploadItems=False PreventUploadSurvivors=False Link to comment Share on other sites More sharing options...
KriegTiger Posted July 8, 2020 Author Share Posted July 8, 2020 1 hour ago, Popiyopi said: Try add this lines to GameUserSettings.ini PreventUploadDinos=False PreventUploadItems=False PreventUploadSurvivors=False Yes - these were noted in my original post. 4 hours ago, Larkfields said: Have you port-forwarded ports 7777 to 7780 inclusive? My network setup is... complicated. Short answer: Yes, I did forward those ports to the ark server so people can come in from the outside world, my friends are able to connect to the individual instances of the ARK servers from the outside world just like I am able to do it from my local network. Long answer: It appears to be more an issue that the 'travel to another server' cluster function requires successful registration to the Steam master list of unofficial servers. The problem is that my internet connection is via a cellular broadband service which apparently plays hell with stuff like this. My 4G-LTE modem gets an IP of 28.230.XXX.YYY but the IP the world sees (IE when you go to 'whatismyip.com') is 172.58.XXX.YYY - so there's intermediate traffic management of some sort that I have no influence over. I don't GET a generic world-facing IP address that I can just open ports on. So steamcmd would be attempting to register my servers as 172.58.XXX.YYY, the inbound connections go to that IP and then don't get routed/forwarded farther because of the ISP. My workaround is currently that I have a small hosted server that runs a VPN server which DOES have a direct world-facing IP address. Previously this system was used only for dns based adblock/filtering using pi-hole that I have also setup to be a port forwarding destination for my dedicated ARK server. That ARK server runs openVPN client and connects to the hosted VPN server, is assigned a static IP of 10.89.0.200, and all my port forwarding and NAT mangling of packets happens there. It works great, except for one problem: the ARK server only routes traffic back OUT on that vpn connection that comes in FROM it - so when I fire up the server to start with, it tries to register the session with Steam's servers using the non-vpn interface and route, which sends it out through my standard ISP connection, which will have it trying to get Steam to probe/list the 172.58.XXX.YYY address as the location of my server rather than the actual VPN server's IP of 50.116.XXX.YYY. If I could somehow force ARK to use the openVPN connection as it's default 'here's data for the internet' destination, or somehow manually specify (via GameUserSettings or manual registration process with Steam) that my servers exist at the 50.116.XXX.YYY location rather than the IP that shows up when the Steam API uses the default route path from my linux box, I'd be set. So far, that doesn't seem to be possible but I'm still digging. So currently my situation is just that me and my friends can drop dinos and items in the Obelisk terminals/Tek transmitters and they will show up on the other side just fine, but to actually GO to that other place you need to just disconnect and reconnect to the other server manually. This gives the game more of an 'Altered Carbon' feel than 'Stargate' when it comes to travelling between worlds - IE transferring your consciousness but leaving the meat behind. I could get crazy technical with creating a solution using a bridged interface, more packet mangling, etc (give me a single open port to the internet and I can do wild things and make security admins hate my guts; ahh the joys of being a Linux administrator for 20+ years.. F*#@ I'm old *sigh* anyways..) but then it's a matter of 'how much sleep do I want to lose over this instead of just using that Altered Carbon style feel to the game and enjoying what I have'. But I still haven't really answered your question in detail - I forwarded all those ports and done the necessary NAT translations - here are my settings (only relevant entries shown out of my whole firewall configuration). The trick was doing both SNAT and DNAT mangling on the packets before they reached the server so that it would get routed back out the vpn tunnel. The port allowances I'm doing are a bit wider than the bare minimum (27015:27020 are typical, I did 27000:27040 just to cover all bases), but this has allowed my server to work pretty much flawlessly other than the whole 'not listed on steam's unofficial server list' thing. *filter :OUTPUT ACCEPT [0:0] # Steam Ports, used for ARK -A INPUT -i eth0 -p udp -m udp --dport 4242 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 4380 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 7777:7780 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 25147 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 25147 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 27000:27040 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 27000:27040 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 27215 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 27217 -j ACCEPT -A INPUT -i tun0 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 4242 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 4380 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 7777 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 7778 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 7779 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 7780 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 27000:27040 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p tcp --destination-port 27000:27040 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 27215 -d 10.89.0.200 -j ACCEPT -A FORWARD -i eth0 -p udp --destination-port 27217 -d 10.89.0.200 -j ACCEPT -A FORWARD -i tun0 -j ACCE -A FORWARD -s 10.89.0.0/24 -i tun0 -o eth0 -j ACCEPT *nat :OUTPUT ACCEPT [0:0] #ARK rules for NAT if using a windows dedicated system -A PREROUTING -p udp -d 50.116.26.174 --dport 4242 -j DNAT --to-destination 10.89.0.200 -A PREROUTING -p udp -d 50.116.26.174 --dport 4380 -j DNAT --to-destination 10.89.0.200 -A PREROUTING -p udp -d 50.116.26.174 --dport 7777:7780 -j DNAT --to-destination 10.89.0.200 -A PREROUTING -p udp -d 50.116.26.174 --dport 27000:27040 -j DNAT --to-destination 10.89.0.200 -A PREROUTING -p tcp -d 50.116.26.174 --dport 27000:27040 -j DNAT --to-destination 10.89.0.200 -A PREROUTING -p udp -d 50.116.26.174 --dport 27215 -j DNAT --to-destination 10.89.0.200 -A PREROUTING -p udp -d 50.116.26.174 --dport 27217 -j DNAT --to-destination 10.89.0.200 -A POSTROUTING -d 10.89.0.200 -j SNAT --to-source 10.89.0.1 -A POSTROUTING -s 10.89.0.0/24 -o eth0 -j MASQUERADE This could all be avoided if WC would look at your favorites list for cluster server resources rather than publicly registered ones, which is what seems to be what is going on. So.. anybody know how I can tell steam (whether via steamCMD command line, steam client, or steampowered.com website) to pretty-please let me add two servers to their unofficial list so it shows up and is functional that way? Link to comment Share on other sites More sharing options...
IanHighlander Posted July 9, 2020 Share Posted July 9, 2020 23 hours ago, KriegTiger said: You gave an answer, but not an explanation. The answer suggests that my server needs to be able to register with Steam/ARK's server list and be browseable in the 'unofficial' lists in order for transfers to work even though both instances are on the same physical machine, are connected to directly via local LAN connections, and bypasses their status as 'favorites' where they are listed by said local IP's (IE that the server is initiating the connection and not the client). This also suggests that you would be absolutely unable to play a clustered setup if you have no internet connection at all. Is that correct? Correct on all counts. The transfer to server option does not use your favourites list. Servers should automatically register with Steam when they start and Steam will try and connect back to them to confirm their status (and monitor it). You need open connection to the correct ports for all your servers in order for Steam to be able to do this. To be honest, it's a naff system, but it is what it is. Link to comment Share on other sites More sharing options...
KriegTiger Posted July 9, 2020 Author Share Posted July 9, 2020 5 hours ago, IanHighlander said: Correct on all counts. The transfer to server option does not use your favourites list. Servers should automatically register with Steam when they start and Steam will try and connect back to them to confirm their status (and monitor it). You need open connection to the correct ports for all your servers in order for Steam to be able to do this. To be honest, it's a naff system, but it is what it is. Crap. I do have NAT and ports setup for full access already (shown above), but because of the complications in my ISP's handling of their IP space It's just not going to work the 'easy' way and I'm going to likely have to over-engineer a stupidly complex solution since I can't just fill out a form for Steam's server list that says 'hey, I have a server running at A.B.C.D:xyz. bummer. Link to comment Share on other sites More sharing options...
KriegTiger Posted July 9, 2020 Author Share Posted July 9, 2020 51 minutes ago, KriegTiger said: Crap. I do have NAT and ports setup for full access already (shown above), but because of the complications in my ISP's handling of their IP space It's just not going to work the 'easy' way and I'm going to likely have to over-engineer a stupidly complex solution since I can't just fill out a form for Steam's server list that says 'hey, I have a server running at A.B.C.D:xyz. bummer. I *could* try to tweak my server's default routes to use my 10.89.0.X VPN connection rather than the linux box's 192.168.1.X interface.. it would still be accessible by LAN clients, but at that point the server check-in process should go out through the tun0 interface and register the correct IP. I'll have to try it tonight when nobody is playing. Much easier solution, fingers crossed. Link to comment Share on other sites More sharing options...
KriegTiger Posted July 9, 2020 Author Share Posted July 9, 2020 2 hours ago, KriegTiger said: I *could* try to tweak my server's default routes to use my 10.89.0.X VPN connection rather than the linux box's 192.168.1.X interface.. it would still be accessible by LAN clients, but at that point the server check-in process should go out through the tun0 interface and register the correct IP. I'll have to try it tonight when nobody is playing. Much easier solution, fingers crossed. KISS rule for the win! Well.. 'simple'-ish compared to my other ideas anyway. Had to delete the default route for my system. This, however, meant that my ARK server no longer had a route to make a connection to the VPN server, so I added a host-gateway for the VPN server's IP to use my home internet gateway, and then once my VPN was connected I added a new default gw route of the IP for my VPN server's 'internal' IP. Net result: all my local LAN traffic on 192.168.1 (both to and from) the ARK server can function as it always has, but ARK/steamCMD's network calls by default all get shunted through the VPN tunnel and means that they register properly using that IP. Bounced the cluster servers to and checked the terminal - PRESTO! I can travel to another server now. Huzzah! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.