Jump to content
  • Network Namespaces For Rust Workaround


    Roy
    • Start Date: 04/21/2018
      Completion Date: 05/13/2018
      Expected Completion Date: 05/13/2018
     Share

    I will be looking into network namespaces with Docker containers. This workaround was explained in this thread regarding the current Rust networking issue. Keep in mind, this reply was made with the assumption we weren't using Docker containers. Docker handles its own networking in containers. Therefore, this will be a bit more tricky and complicated with Docker containers in my opinion.

     

    I will be trying to either change the default route in the Rust server container to the internal IP we have sourced out as the Rust external IP or using the "network namespaces" guide.

     

    Workarounds I've Tried But Don't Suit Our Needs

    Source Internal Machine IP (using Master Server Ports) Out As External Rust Address

    Although I dislike this workaround, it was worth a try. I tried sourcing all traffic going out from the machine internal IP on Valve Master Server ports as the external Rust address. This worked for a week until it suddenly stopped because the port it is sending out as isn't in the range of ports I made for the firewall. Unfortunately, I don't know all of Valve's Master Server ports because it isn't documented anywhere from what I've seen. If I can find a list ports, I will be able to make this workaround active again. When this workaround is working, the only downfall is we will only be able to host Rust servers on one external IP per machine. So if we looked into running two Rust servers on the same machine, they will have the same external address with different ports (e.g. 28015 and 28016).

     

    My current firewall uses port ranges 20000 - 30000 UDP/TCP. Unfortunately, the game server reports to the Valve Master Server on ports outside of that range. Hence why the workaround isn't working at the moment.

     

    I may try getting the ports it is currently sourcing out with using tcpdump. However, this will be complicated and I'd highly prefer if Valve would just list the ports.

     

    Translating The Machine's External IP To Rust's External IP

    I have also tried making a firewall rule that translated the machine's external IP (what Valve Master Server is reporting) to the Rust external IP. This works and basically makes it so if you try requesting the machine's external IP, it will be translated to Rust's external IP. The problem with this is we will likely only be able to run one Rust server on each machine and the server will look like it has two IPs (the fake IP used in the server browser listing and the real Rust IP). I personally dislike this workaround the most because it is inconsistent and sloppy. But it was still worth a try.

     

    This is a project moved from our old Technical Tasks database to the Projects database. Some sensitive information may have been cut out when moving to the public.

    Edited by Roy


    Leader: Roy Members - Roy
    Progress - 100%
     Share


    User Feedback

    Recommended Comments

    5-12-18

    Just an update, I started working on this tonight. I made some progress but I am currently stuck on making the server work with a separate Docker network. I created a new variable in the control panel and edited a core file in the control panel's source code.

     

    https://github.com/pterodactyl/daemon/blob/b73ec6b85bfe32c5d3a3e2a6bcf4f569f80f2b05/src/controllers/docker.js#L435

     

    This was changed to:

     

    NetworkMode: (config.env.NETWORK) ? config.env.NETWORK : Config.get('docker.network.name', 'pterodactyl_nw'),

    While using the following script to recreate a Docker network group:

     

    #!/bin/bash
    
    sudo docker network rm test
    sudo docker network create -d bridge -o "com.docker.network.bridge.enable_ip_masquerade"=false -o "com.docker.network.bridge.name"="csstest" -o "com.docker.network.bridge.host_binding_ipv4"="192.168.x.x" --ip-range 192.168.x.x/30 --subnet 192.168.x.x/28 test

     

    I believe I need to develop a better understanding of how Docker networks work and how networking works in general on this level. I am going into this blinded in my opinion. I have a lot of reading to do in order to better understand all of this material. Useful documentation of the Docker networking can be found here:

     

    https://docs.docker.com/network/

     

    Thank you for understanding.

     

    5-13-18

    Great News!

     

    I believe I have gotten this to work and the Rust server should be fully functional now.

     

    After spending eight - ten hours of testing, building Docker networks/containers/images, and so on, I figured it out.

     

    So here's my bash file that creates the Rust network:

     

    #!/bin/bash
    
    sudo docker network rm xxxxx
    sudo docker network create -d bridge -o "com.docker.network.bridge.enable_ip_masquerade"=false -o "com.docker.network.bridge.name"="xxxxxx" -o "com.docker.network.bridge.host_binding_ipv4"="0.0.0.0" -o "com.docker.network.bridge.enable_icc"=false -o "com.docker.network.driver.mtu"=1400 --subnet 192.168.x.x/28 --gateway 192.168.x.x xxxxx

     

    I did replace the last two IP blocks with x's because they're private.

     

    The problem I was running into had to do with the Docker container sourcing out as the default host machine IP. This was the issue before. I finally found this amazing article which explained exactly what I had to do. I built the network with com.docker.network.bridge.enable_ip_masquerade set to false. Afterwards, I added a Source NAT rule into the POSTROUTING IPTables list with the following command:

     

    sudo iptables -t nat -A POSTROUTING -s 192.168.x.x ! -o xxxxx -j SNAT --to-source 192.168.x.x

     

    Afterwards, the POSTROUTING list should look like this:

     

    Chain POSTROUTING (policy ACCEPT 2719 packets, 146K bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere
      648 37131 SNAT       all  --  any    !xxxxxx  192.168.x.x        anywhere             to:192.168.x.x
        0     0 MASQUERADE  tcp  --  any    any     192.168.x.x        192.168.x.x        tcp dpt:28015
        0     0 MASQUERADE  udp  --  any    any     192.168.x.x        192.168.x.x        udp dpt:28015

     

    And that's it. Keep in mind, after upgrading the control panel we will have to replace this line with the following to allow separate servers to run on their own networks through the containers:

     

    NetworkMode: (config.env.NETWORK) ? config.env.NETWORK : Config.get('docker.network.name', 'pterodactyl_nw'),

     

    P.S. I accidentally took down GS01 last night while trying to test Docker networks. One of the networks I made last night conflicted with the main network. Therefore, causing the entire machine to lose network connection. I had to go into the console itself to delete the conflicting network. I'M SORRY!

     

    Thank you!

     

    5-12-18

    And this is the server confirmed showing in the Valve Master Server under the correct IP:

     

    {"response":{"servers":[{"addr":"79.137.121.135:28015","gameport":28015,"steamid":"90114590318500871","name":"Games For Life|2x|04/18|low-pop|","appid":252490,"gamedir":"rust","version":"2086","product":"252490","region":-1,"players":0,"max_players":100,"bots":0,"map":"Procedural Map","secure":true,"dedicated":true,"os":"l","gametype":"mp100,cp0,qp0,v2086,h79dac7f9,stok,born1526087580,modded,oxide"}]}}

     

    Thanks.

     

    5-13-18

    As far as I am aware, this is confirmed working.

     

    I will go ahead and close this task.

     

    Thanks.

    Link to comment
    Share on other sites


    Guest
    This is now closed for further comments

×
×
  • Create New...