5

I am planning to ship a "home server" type device to customers, that communicates with their (Android or iPhone) smart phone. The problem is that, depending on their internet service provider, the customer has no outside-reachable IPv4 address (DS-lite tunneling), so the smart phone can't just use an IPv4 DNS record to find the server.

Alternatives I can think of:

  • Make the server use an IPv6 DynDNS service, and make IPv6 take preference over IPv4 on the smart phone. Since the solution should work without the customer having to sign up for a DynDNS service, I have not found any service that allows me to do that.

  • Set up my own "directory server", such that the home server registers it's serial number in intervals - so similar like DynDNS, but on the application layer via HTTPS. A client could then simply enter the serial number into the app to find the server. Due to authentication/encryption requirements, this solution is harder to implement than I like.

Any other ideas on how to make a home server reachable? I would really like to avoid running my own "cloud service". Some type of peer to peer network discovery, perhaps?

[UPDATE:] This is what I am essentially looking for:

Home server                            Relay         DynDNS        Client
|                                      |             |             |
|-------- open tunnel to port 80 ----->|             |             |
|<-success, listening on 192.0.2.1:80 -|             |             |
|                                      |             |             |
|----- Register "my.ddns.net" ---------------------->|             |
|<------------ "my.ddns.net" is now 192.0.2.1 -------|             |
|                                      |             |             |
|                                      |<- GET http://my.ddns.net -|
|<------- GET http://my.ddns.net   ----|             |             |
|--- HTTP response ------------------->|             |             |
|                                      |----- HTTP response ------>|
kasperd
  • 1,952
  • 1
  • 20
  • 31
knipknap
  • 5,934
  • 7
  • 39
  • 43
  • 1
    It is not entirely clear to me which problem you are trying to solve. Finding the IPv6 address of a device which does have an IPv6 address is something which DNS is designed to do. Creating your own dynamic DNS service for the users is not that hard, in particular not if the device to be addressed is running your code. Getting a client which potentially only has IPv4 to connect to a server which only has IPv6 can be tricky. To answer the later you need to provide much more information about your needs. Feel free to message me on chat, as it could probably take several roundtrips to clarify. – kasperd Jun 21 '15 at 17:27
  • Thanks, I have updated my question, hopefully that explains it better. The question is unclear because I don't know what I am really looking for - I just know that I want the client to be able to talk to the home server, regardless of whether the home server is behind a firewall/NAT/DS lite tunnel. – knipknap Jun 21 '15 at 18:07
  • 1
    What is `Relay` in that diagram? Is that an existing service or something you want to implement? – kasperd Jun 21 '15 at 18:50
  • Optimally, an existing service. Implementing this seems difficult, and also expensive, considering I would need to have a pool of public ip addresses available. Well, unless the public IP is an IPv6 address space, which should be good enough I guess. – knipknap Jun 21 '15 at 19:12
  • 2
    If you only need HTTP support, then `Relay` can be implemented using only a single IPv4 address. I know, because I have implemented [such a service](http://v4-frontend.netiter.com/). My specific implementation would require `Home server` to have IPv6, and the hostname must be resolved using DNS. And in that case `Relay` would only be involved if `Client` is on an IPv4-only network. If `Client` has IPv6 as well, it will communicate directly with `Home server` without involving `Relay`. – kasperd Jun 21 '15 at 19:24
  • 1
    If you want to implement `Relay` yourself, then one way to do so would be for each `Home server` to open a persistent TCP connection to `Relay`. The first it need to do is to inform `Relay` what name it is using. Then `Relay` can use the `Host` header on incoming HTTP requests to direct each request to the proper `Home server`. You might be able to use ssh reverse port forwarding for the communication between `Home server` and `Relay`. That reduces the amount of code you need to implement. And you can rely on existing code for the most security sensitive parts. – kasperd Jun 21 '15 at 19:30
  • Ahh, your service is a really neat trick, that would actually solve the IP addressing issue of DS lite tunnels! I am still going to try and find a way to solve the tunneling issue as well, but if all else fails, I guess that will have to do. – knipknap Jun 21 '15 at 19:35
  • Your idea of using the HTTP host header is perfect. I think it can't be done any better than that. Thanks, that's what I am going to do! – knipknap Jun 21 '15 at 19:38
  • I have several apps that do this (to find NAS, media players and printer) except that they use the LAN instead of a central server. The ones I've tcpdumped use multicast, at least one uses UPNP (UDP port 1900) and another uses multicast DNS (UDP port 5353). – arnt Jun 22 '15 at 14:05
  • 1
    @kasperd thank you very much for your valuable insights and for Netiter! I'm definitely spreading the word :) thanks to the others too – fr_andres Feb 20 '18 at 00:13

2 Answers2

2

Making connection from the internet to a server in a home is difficult. IPv6 is not available everywhere yet and with IPv4 you don't always have a public address available (with multiple NAT layers or DS-Lite).

The only reliable solution today is to have a publicly reachable server as rendezvous point and let the home box maintain a permanent collection to that server. Mobile devices (which might be behind NAT as well) can then reach the home box through the server or set up STUN/TURN style connectivity.

Sander Steffann
  • 9,509
  • 35
  • 40
  • I guess you are right. Poking a hole into routers/firewalls would also be solved if the home server maintains the connection. Surely there has to be an existing service that does this? – knipknap Jun 21 '15 at 16:45
  • 1
    Punching holes in NAT is best done with STUN and TURN – Sander Steffann Jun 21 '15 at 16:46
  • Thanks, that is a good starting point. However, it appears that TURN is not really an option, as it only supports UDP between the relay and the peer. – knipknap Jun 21 '15 at 17:14
1

Thanks to the other responses, I had the starting points to find some existing solutions: ngrok and localtunnel solve the problem by mapping a dedicated subdomain to each Home Server, and dispatching requests based on HTTP(S) GET requests.

The latter is an open source project, and the server, as well as a javascript client are on Github.

knipknap
  • 5,934
  • 7
  • 39
  • 43