Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


VPS behind a regular NAT with access to its router
New on LowEndTalk? Please Register and read our Community Rules.

VPS behind a regular NAT with access to its router

robertsdotpmrobertsdotpm Member
edited May 26 in Requests

Hello, I am a software engineer developing peer-to-peer networking code and I'm very interested to see if any hosts could hook me up with a shell on a device behind a regular, consumer-grade router (or perhaps a router with a ubiquitous firmware like Open-WRT.) It would be ideal if I had access to the router; it supported UPnP; and supported IPv4 and IPv6.

I am aware of hosts that offer 'NATed VPS' but they usually control how ports are assigned to the VPS and I would need to have a regular NAT for testing port opening and NAT traversal code. It would also be an advantage if I could get multiple offers in geographically distant locations as P2P code needs two to tango.

I will be sending minimal traffic on these devices and only require that they be able to run Python 3 without running out resources. By the way: if anyone wants to self-host me on their own LAN then I have no requirement for this to be commercially hosted (as long as you own the computers of course!) It would actually be better if this were hosted by regular users and not in a data center so I could test more realistic networking conditions.

Thanks for reading!

Comments

  • Just buy a 911.re package and you can have all the residential compromised computers you want.

  • fynixfynix Member

    @dane_doherty said: you can have all the residential compromised computers you want

    And you are suggesting this?

  • Peppery9Peppery9 Member

    Sounds shady.

    Congrats on your first post!

  • @Peppery9 said:
    Sounds shady.

    Congrats on your first post!

    Why does it sound shady? I'm developing open source software and have already released code for peer-to-peer networking in the past. Such code is useful for a range of use-cases like: peer-to-peer calling, video game servers, distributed CDNs, file sharing, and even financial ledgers. But unfortunately, the only real way to test this kind of code is to see how it interacts with the kind of routers home users will have. In the past I've used cloud virtualization like ESXi to setup virtual routers, but this approach is very complex and time consuming to do. I am hoping for something simpler.

    @dane_doherty said:
    Just buy a 911.re package and you can have all the residential compromised computers you want.

    I'm not interested in doing anything illegal. There is nothing illegal about peer-to-peer networking...

  • ralfralf Member

    Surely you could test exactly what you want by getting two VPS that support nested virtualisation. You would then also be able to control what the NAT is doing and experiment with different setups.

  • Haha, "recommend"? No, no. They are terrible. I'm quite sure their official client is malware (despite having code signing which is impressive for such shady operation).

    But in the end:

    • they mostly deliver what they promise
    • I think at this point they have no real competitors remaining
  • taizitaizi Member

    they are a good provider at this price level, for better quality, pay more money.

  • While part of me wants to say hell yeah you can use a RPI4 behind one of my extra routers, another, more intelligent, part of me is skeptical about giving a random person use of my home internet connection.

    Interesting request though.

  • @BlazinDimes said:
    While part of me wants to say hell yeah you can use a RPI4 behind one of my extra routers, another, more intelligent, part of me is skeptical about giving a random person use of my home internet connection.

    Interesting request though.

    It's okay, I understand. It seems like there are also no hosts that support this kind of thing. I think I will have to do what that other user suggested and just setup all the virtualization and networking myself.

  • @robertsdotpm said:
    I think I will have to do what that other user suggested and just setup all the virtualization and networking myself.

    That's the conclusion 99% of us immediately came to. Most devs I know would just do this at home and have the most efficient test setup. It's too easy to get cheap and basic NAT routers.

  • @TimboJones said:

    @robertsdotpm said:
    I think I will have to do what that other user suggested and just setup all the virtualization and networking myself.

    That's the conclusion 99% of us immediately came to. Most devs I know would just do this at home and have the most efficient test setup. It's too easy to get cheap and basic NAT routers.

    Well, the problem with that is I wouldn't be able to test NAT traversal code that relies on hole punching techniques (which is a critical part of my software.) For that to work you need to be able to send packets between peers so that both peers have sent out a packet before receiving one. It's non-obvious how you would simulate this behaviour in a test setup because it depends on timing issues and routing from the actual Internet.

    Packets sent between hosts on a LAN are going to exhibit much different behaviours from the router compared to the Internet. This may mean covering up timing issues, assumptions about the NAT, router, or any number of issues that arise from this kind of code.

  • yoursunnyyoursunny Member, IPv6 Advocate

    NAT is evil.
    Use IPv6 instead.

    Timing behavior can be simulated by injecting delay with tc command.
    OpenWRT firmware may be installed on any KVM server.

  • devpdevp Member

    @robertsdotpm said: Why does it sound shady? I'm developing open source software and have already released code for peer-to-peer networking in the past. Such code is useful for a range of use-cases like: peer-to-peer calling, video game servers, distributed CDNs, file sharing, and even financial ledgers. But unfortunately, the only real way to test this kind of code is to see how it interacts with the kind of routers home users will have. In the past I've used cloud virtualization like ESXi to setup virtual routers, but this approach is very complex and time consuming to do. I am hoping for something simpler.

    Setup a local lan network and check in virtual machines.

    @BlazinDimes said: While part of me wants to say hell yeah you can use a RPI4

    RPI can be used as a router and customised as per custom configuration for network.

  • @robertsdotpm said:

    @TimboJones said:

    @robertsdotpm said:
    I think I will have to do what that other user suggested and just setup all the virtualization and networking myself.

    That's the conclusion 99% of us immediately came to. Most devs I know would just do this at home and have the most efficient test setup. It's too easy to get cheap and basic NAT routers.

    Well, the problem with that is I wouldn't be able to test NAT traversal code that relies on hole punching techniques (which is a critical part of my software.) For that to work you need to be able to send packets between peers so that both peers have sent out a packet before receiving one. It's non-obvious how you would simulate this behaviour in a test setup because it depends on timing issues and routing from the actual Internet.

    Packets sent between hosts on a LAN are going to exhibit much different behaviours from the router compared to the Internet. This may mean covering up timing issues, assumptions about the NAT, router, or any number of issues that arise from this kind of code.

    Fucking trivial. Your increased and variable bandwidth (for starters) is as simple as using WiFi instead of Ethernet, two hosts and a router. Then there's Linux programs to help with delays or packet shaping for more use cases. Hole punching doesn't rely on timing.

    But first, get it started and working and then you'll get decent interest and testers with more use cases.

    (Given your need to control the packets and ordering, every developer I know would implement this on a test setup with three hosts, multiple NICs each and write the software themselves.)

    Thanked by 1devp
  • @yoursunny said:
    NAT is evil.
    Use IPv6 instead.

    Timing behavior can be simulated by injecting delay with tc command.
    OpenWRT firmware may be installed on any KVM server.

    Already supporting IPv6! I've put a huge amount of time into IPv6 compatibility.

    @TimboJones said:

    @robertsdotpm said:

    @TimboJones said:

    @robertsdotpm said:
    I think I will have to do what that other user suggested and just setup all the virtualization and networking myself.

    That's the conclusion 99% of us immediately came to. Most devs I know would just do this at home and have the most efficient test setup. It's too easy to get cheap and basic NAT routers.

    Well, the problem with that is I wouldn't be able to test NAT traversal code that relies on hole punching techniques (which is a critical part of my software.) For that to work you need to be able to send packets between peers so that both peers have sent out a packet before receiving one. It's non-obvious how you would simulate this behaviour in a test setup because it depends on timing issues and routing from the actual Internet.

    Packets sent between hosts on a LAN are going to exhibit much different behaviours from the router compared to the Internet. This may mean covering up timing issues, assumptions about the NAT, router, or any number of issues that arise from this kind of code.

    Fucking trivial. Your increased and variable bandwidth (for starters) is as simple as using WiFi instead of Ethernet, two hosts and a router. Then there's Linux programs to help with delays or packet shaping for more use cases. Hole punching doesn't rely on timing.

    But first, get it started and working and then you'll get decent interest and testers with more use cases.

    (Given your need to control the packets and ordering, every developer I know would implement this on a test setup with three hosts, multiple NICs each and write the software themselves.)

    Hole punching does depend on timing. When you send out a packet from the router the NAT creates a mapping that says "inbound packets from dest IP AND/OR dest port may be forwarded to source host." (dest IP may be any depending on NAT type.) If peer Bs packets arrive at peer A before peer B sent out a packet then they will be dropped. Lets be specific and say that I'm talking about TCP.

    There is a little-known quirk of TCP wherein its possible to establish a working 'connection' between two hosts by simultaneously connecting to each others externally mapped NAT ports. What I said about packets being dropped would mean that packets in the TCP three-way handshake are dropped which would cause the connection to fail. For the connection to succeed both hosts need to have their in-flight SYN packets cross their routers before their respective partners SYNs arrive.

    Testing this on a LAN does me no good as the NAT behaviour is likely to be different than external packets. The only way to be sure I have working code is to test this in the real world, with real timing and routers. I am sensing a lot of pretentiousness in your posts by implying that all of this is easy or obvious when you yourself don't seem well-versed in peer-to-peer technology, lmao.

  • ralfralf Member

    There's a Windows tool called fiddler that adds latency and drops packets randomly depending on the desired error rates. (TIL it seems fiddler is made by an independent company, but I first discovered it doing Xbox games development as it was what everyone used to simulate packet loss)

    If you just want long latency, buy a cheap KVM instance somewhere far away from you and set up two wireguard instances on it that forward packets between each other with -j MASQ, and connect to them from different hosts on your local net. Bingo. Exactly the kind of setup you're begging others for, but completely under your control and suitable for repeatable test scenarios.

  • TimboJonesTimboJones Member
    edited May 29

    @robertsdotpm said:

    (Given your need to control the packets and ordering, every developer I know would implement this on a test setup with three hosts, multiple NICs each and write the software themselves.)

    Hole punching does depend on timing. When you send out a packet from the router the NAT creates a mapping that says "inbound packets from dest IP AND/OR dest port may be forwarded to source host." (dest IP may be any depending on NAT type.) If peer Bs packets arrive at peer A before peer B sent out a packet then they will be dropped. Lets be specific and say that I'm talking about TCP.

    Quantum packets, lol. That doesn't make sense. Check your work. If peer Bs packets arrive at peer A before peer B sent out a packet then they will be time traveling.

    There is a little-known quirk of TCP wherein its possible to establish a working 'connection' between two hosts by simultaneously connecting to each others externally mapped NAT ports. What I said about packets being dropped would mean that packets in the TCP three-way handshake are dropped which would cause the connection to fail. For the connection to succeed both hosts need to have their in-flight SYN packets cross their routers before their respective partners SYNs arrive.

    Testing this on a LAN does me no good as the NAT behaviour is likely to be different than external packets. The only way to be sure I have working code is to test this in the real world, with real timing and routers. I am sensing a lot of pretentiousness in your posts by implying that all of this is easy or obvious when you yourself don't seem well-versed in peer-to-peer technology, lmao.

    Wow. You really have zero testing experience nor know what you really need, you're just being lazy.

    Again, for something where you need to control the timing conditions, having control over your hosts is the most effective way to develop and test this. The internet is an uncontrolled variable that makes reproduction harder. And not sure how testing with a real world NAT router (and a setup to easily swap in other routers, since that's really the DUT) isn't real world testing. It sounds like you'll make something that only works under limited conditions and difficult to use. No thanks.

    https://tailscale.com/blog/how-nat-traversal-works/

Sign In or Register to comment.