[opensuse] Maybe OT: Dynamic DNS services and openSUSE
I would like to enable remote access to openSUSE systems that are running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them. The idea is to use a telephone with a local phone company SIM (supplied by the local owner of the system), connected to the openSUSE box via a USB cable. Obviously the local phone company has to allow tethering in such a way that one can find the telephone. It is not enough that the telephone can find us. How best to do this? Our biggest worry is that we may make assumptions about what the local telephone companies allow. My initial thought is to use some dynamic DNS service. I guess that assumes that there is a route back to the telephone. I have seen suggestions that a tunnel be created. Might that be more robust in the light of local phone company differences? I guess we need a 'lowest common denominator' solution. Anyone know of a good tutorial on this? Something written this century. There seems to be lots of old info that is usually very incomplete. And they all seem to be about using the connection to access the internet. Not for the internet to access you. I must be crap at choosing search words... Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Sep 10, 2012 at 01:45:10PM +0200, Roger Oberholtzer wrote:
I would like to enable remote access to openSUSE systems that are running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them.
The idea is to use a telephone with a local phone company SIM (supplied by the local owner of the system), connected to the openSUSE box via a USB cable. Obviously the local phone company has to allow tethering in such a way that one can find the telephone. It is not enough that the telephone can find us.
How best to do this? Our biggest worry is that we may make assumptions about what the local telephone companies allow. My initial thought is to use some dynamic DNS service. I guess that assumes that there is a route back to the telephone. I have seen suggestions that a tunnel be created. Might that be more robust in the light of local phone company differences? I guess we need a 'lowest common denominator' solution.
openvpn as I told on a similar topic (maybe even to you?) some months back. Dynamic DNS will not provide a solution. Cause many if not all of these mobile network providers make use of addresses as defined by RFC 1918. Therfore you have access from the mobile device to the public but no way back. Well you might consider to work with port forwarding and some other less or more smart tricks. But at the end all this will cause pita.
Anyone know of a good tutorial on this? Something written this century. There seems to be lots of old info that is usually very incomplete. And they all seem to be about using the connection to access the internet. Not for the internet to access you. I must be crap at choosing search words...
All you need is provided by SUSE. YaST has a CA management module. Well, some general understanding about how a CA is expected to work and how to control the certificates is required. The big advantage: all the documentation I used was written in the last five years. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Mon, 2012-09-10 at 14:06 +0200, Lars Müller wrote:
openvpn as I told on a similar topic (maybe even to you?) some months back.
Guilty. It was me back in December. I am now actually going to do this. So I confess I re-started information gathering. Obviously I need to brush up on openVPN and certificates. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2012-09-10 at 15:07 +0200, Roger Oberholtzer wrote:
On Mon, 2012-09-10 at 14:06 +0200, Lars Müller wrote:
openvpn as I told on a similar topic (maybe even to you?) some months back.
Guilty. It was me back in December. I am now actually going to do this. So I confess I re-started information gathering. Obviously I need to brush up on openVPN and certificates.
Just tried getting info on this at work (it is for work). The internet ain't what it used to be... This Page Cannot Be Displayed Based on your corporate access policies, access to this web site ( http://openvpn.net/ ) has been blocked because the web category "Filter Avoidance" is not allowed. If you have questions, please contact your corporate network administrator and provide the codes shown below. ________________________________________________________________________ Notification codes: (1, WEBCAT, BLOCK-WEBCAT, 0x03af4a7b, 1347282463.877, AAAEAQAAAAAAAAAAlf8AEP8AAAD/AAAAAAAAAAAAAAE=, http://openvpn.net/) Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 10 Sep 2012 15:11:45 +0200
Roger Oberholtzer
On Mon, 2012-09-10 at 15:07 +0200, Roger Oberholtzer wrote:
On Mon, 2012-09-10 at 14:06 +0200, Lars Müller wrote:
openvpn as I told on a similar topic (maybe even to you?) some months back.
Guilty. It was me back in December. I am now actually going to do this. So I confess I re-started information gathering. Obviously I need to brush up on openVPN and certificates.
Just tried getting info on this at work (it is for work). The internet ain't what it used to be...
This Page Cannot Be Displayed Based on your corporate access policies, access to this web site ( http://openvpn.net/ ) has been blocked because the web category "Filter Avoidance" is not allowed. If you have questions, please contact your corporate network administrator and provide the codes shown below.
________________________________________________________________________ Notification codes: (1, WEBCAT, BLOCK-WEBCAT, 0x03af4a7b, 1347282463.877, AAAEAQAAAAAAAAAAlf8AEP8AAAD/AAAAAAAAAAAAAAE=, http://openvpn.net/)
Yours sincerely,
Roger Oberholtzer
Ramböll RST / Systems
Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________
Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se
Hi Not sure if something like iodine (ipv4 tunnel over DNS), there is an android client (and packages for openSUSE, built them last week ;) ) http://www.anticensure.com/?__new_url=aHR0cDovL2NvZGUua3J5by5zZS9pb2RpbmUv http://blog.bokhorst.biz/5123/computers-and-internet/iodine-dns-tunnel-for-a... -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop up 0:11, 3 users, load average: 0.09, 0.18, 0.18 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Malcolm wrote:
Hi Not sure if something like iodine (ipv4 tunnel over DNS), there is an android client (and packages for openSUSE, built them last week;) ) http://www.anticensure.com/?__new_url=aHR0cDovL2NvZGUua3J5by5zZS9pb2RpbmUv http://blog.bokhorst.biz/5123/computers-and-internet/iodine-dns-tunnel-for-a...
Why not just configure OpenVPN to use UDP port 53? It can also be configured to use TCP port 80, but running TCP over TCP is not a good idea. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2012-09-10 at 14:06 +0200, Lars Müller wrote:
openvpn as I told on a similar topic (maybe even to you?) some months back.
Guilty. It was me back in December. I am now actually going to do this. So I confess I re-started information gathering. Obviously I need to brush up on openVPN and certificates.
It's not really that complicated - getting a working test-setup won't take you more than a couple of hours. -- Per Jessen, Zürich (25.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2012-09-10 at 14:06 +0200, Lars Müller wrote: (Sorry if these are dumb questions. And I guess there are lists more suited. I ask here because it is on openSUSE that I will do all this. And, there is lots of expertise on this list...)
openvpn as I told on a similar topic (maybe even to you?) some months back.
Took a look at openVPN. Aside from the fact that this would surely require that I upgrade a DMZ server that otherwise works great (running openSUSE 10.0), I have a question about ports. It seems that openVPN requires one port, with the possibility of a second. The machine where I would need to run the server is in a DMZ behind the company firewall. It is pretty much a Windows shop, and my Linux box is looked at with a great amount of suspicion. I have gotten them to open port 143 for ssh. Other than that it is http/s and smtp. Not much. But it has been enough for now. I use ssh to get in to the place. Don't tell the admins... Perhaps I could use that port as the openVPN port, and then do my ssh through the vpn. Anyone see any issues with that? As I want to access a number of vehicles, each one would have a unique VPN. Would we need a unique port open in the DMZ for each VPN to each vehicle? How about to the internal machines that want to access these various VPNs? Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Mon, 2012-09-10 at 14:06 +0200, Lars Müller wrote:
(Sorry if these are dumb questions. And I guess there are lists more suited. I ask here because it is on openSUSE that I will do all this. And, there is lots of expertise on this list...)
openvpn as I told on a similar topic (maybe even to you?) some months back.
Took a look at openVPN. Aside from the fact that this would surely require that I upgrade a DMZ server that otherwise works great (running openSUSE 10.0), I have a question about ports.
It seems that openVPN requires one port, with the possibility of a second. The machine where I would need to run the server is in a DMZ behind the company firewall. It is pretty much a Windows shop, and my Linux box is looked at with a great amount of suspicion. I have gotten them to open port 143 for ssh. Other than that it is http/s and smtp. Not much. But it has been enough for now.
I use ssh to get in to the place. Don't tell the admins... Perhaps I could use that port as the openVPN port, and then do my ssh through the vpn. Anyone see any issues with that?
Once you have established a VPN, you can do anything and everything. Port 143 is a bit odd (it's really meant for IMAP), but I guess it could work.
As I want to access a number of vehicles, each one would have a unique VPN.
Each vehicle would be a client, but all of them would be on the same VPN. I have a number of servers in remote datacentres that are connected like this.
Would we need a unique port open in the DMZ for each VPN to each vehicle?
No, just one port.
How about to the internal machines that want to access these various VPNs?
Can't help you with that one - it's just an internal routing issue for those internal macines to get to the openVPN server. -- Per Jessen, Zürich (19.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-09-11 at 09:27 +0200, Per Jessen wrote:
Once you have established a VPN, you can do anything and everything. Port 143 is a bit odd (it's really meant for IMAP), but I guess it could work.
My mistake. I do have 143 open for imap. I meant to write the ssh port 22. That is the one I might have to 'sacrifice' to openVPN. I fear that if I use the suggested openVPN port little flags will go off somewhere in the admin room. Every once in a while they have an external audit of the network done. I get a list of mysterious open ports and suggestions of services that need a version update. Perhaps if I have something other than ssh on port 22 flags will go off anyway....
As I want to access a number of vehicles, each one would have a unique VPN.
Each vehicle would be a client, but all of them would be on the same VPN. I have a number of servers in remote datacentres that are connected like this.
I see. I was thinking each vehicle would be on a separate VPN. I don't need that. I just thought that was the way it was. I guess this opens up the way for vehicles to contact each other as well. Interesting. Prepare for my other thread: openVPN abuse...
Would we need a unique port open in the DMZ for each VPN to each vehicle?
No, just one port.
How about to the internal machines that want to access these various VPNs?
Can't help you with that one - it's just an internal routing issue for those internal macines to get to the openVPN server.
I am guessing that these would also simply be clients. As long as I can get them (meaning the openVPN client on those machines) to use port 22, the rest should 'just work'? The biggest woe is having to update the openSUSE 10.0 machine in the DMZ. I wonder if I would be better running a virtual machine on that system instead. Provided I could get one to run on such an old OS. The kernel is 2.6.13-15.18-default. But as a apache/mail/ssh machine, it is working great. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
My mistake. I do have 143 open for imap. I meant to write the ssh port 22. That is the one I might have to 'sacrifice' to openVPN. I fear that if I use the suggested openVPN port little flags will go off somewhere in the admin room. Every once in a while they have an external audit of the network done. I get a list of mysterious open ports and suggestions of services that need a version update. Perhaps if I have something other than ssh on port 22 flags will go off anyway....
If this is to support some business need, why is it necessary to hide it from IT? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-09-11 at 08:20 -0400, James Knott wrote:
Roger Oberholtzer wrote:
My mistake. I do have 143 open for imap. I meant to write the ssh port 22. That is the one I might have to 'sacrifice' to openVPN. I fear that if I use the suggested openVPN port little flags will go off somewhere in the admin room. Every once in a while they have an external audit of the network done. I get a list of mysterious open ports and suggestions of services that need a version update. Perhaps if I have something other than ssh on port 22 flags will go off anyway....
If this is to support some business need, why is it necessary to hide it from IT?
Not so much 'hide' as 'discourage interest'. They will come with a requirement that we install Windows in the vehicles so we can use some Microsoft solution to the problem. I don't have the time nor the energy for that discussion. Our business unit within the larger company seems to solve things differently than the corporate services might suggest. To them, all engineers should be happy with MS Office, and a few CAD applications that they, at some level, suspect could be done better in Visual Basic. Sigh. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2012-09-11 at 09:27 +0200, Per Jessen wrote:
Once you have established a VPN, you can do anything and everything. Port 143 is a bit odd (it's really meant for IMAP), but I guess it could work.
My mistake. I do have 143 open for imap. I meant to write the ssh port 22. That is the one I might have to 'sacrifice' to openVPN. I fear that if I use the suggested openVPN port little flags will go off somewhere in the admin room. Every once in a while they have an external audit of the network done. I get a list of mysterious open ports and suggestions of services that need a version update. Perhaps if I have something other than ssh on port 22 flags will go off anyway....
Why don't you pick a non-priviledged one, 32444 for instance? I guess you'd still have to explain what it would be for. Abusing port 22 for something else seems more suspicious to me.
As I want to access a number of vehicles, each one would have a unique VPN.
Each vehicle would be a client, but all of them would be on the same VPN. I have a number of servers in remote datacentres that are connected like this.
I see. I was thinking each vehicle would be on a separate VPN. I don't need that. I just thought that was the way it was. I guess this opens up the way for vehicles to contact each other as well. Interesting.
That is configurable, I think you need to enable it explicitly. You could essentially look at all connections as separate /30 networks, I tend to look at mine as one network.
How about to the internal machines that want to access these various VPNs?
Can't help you with that one - it's just an internal routing issue for those internal macines to get to the openVPN server.
I am guessing that these would also simply be clients.
Not necessarily - let's say you establish a VPN on 10.11.12. Your VPN server would be 10.11.12.1, vehicle #34 would be 10.11.12.34. Each client connection is point-to-point, but the server is just a single point to which all the clients connect. An internal machine that need to talk to "vehicle34.rogers.vpn" = 10.11.12.34 just needs a static route to the openVPN server. -- Per Jessen, Zürich (24.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-09-11 at 14:29 +0200, Per Jessen wrote:
Why don't you pick a non-priviledged one, 32444 for instance? I guess you'd still have to explain what it would be for. Abusing port 22 for something else seems more suspicious to me.
This may be a better way to go. It surely does not need to be a well known address < 1024 since we control all components. Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, 2012-09-11 at 14:29 +0200, Per Jessen wrote:
Why don't you pick a non-priviledged one, 32444 for instance? I guess you'd still have to explain what it would be for. Abusing port 22 for something else seems more suspicious to me.
This may be a better way to go. It surely does not need to be a well known address < 1024 since we control all components.
Exactly - the IANA allocated port for openVPN is 1194. -- Per Jessen, Zürich (24.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Why don't you pick a non-priviledged one, 32444 for instance? I guess
you'd still have to explain what it would be for. Abusing port 22 for something else seems more suspicious to me. This may be a better way to go. It surely does not need to be a well known address < 1024 since we control all components.
OpenVPN uses UDP port 1194 by default. Why is it necessary to use something else? As I mentioned in another note, IPSec is also supported by Android devices, or, if it keeps your IT guys happy, PPTP. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
As I want to access a number of vehicles, each one would have a unique VPN. Would we need a unique port open in the DMZ for each VPN to each vehicle? How about to the internal machines that want to access these various VPNs?
As I understand it, later versions of OpenVPN support multiple tunnels through the same port, though I have no experience with that. However, that still leaves the question of routing. Each one would require a specific route IIRC. Have you given consideration to that IPv6 tunnel method that I mentioned earlier? It should work very well in this situation. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 2012-09-11 at 07:50 -0400, James Knott wrote:
Have you given consideration to that IPv6 tunnel method that I mentioned earlier? It should work very well in this situation.
A bit. We are not using IPv6 on our internal network. Wouldn't that be required to use this? Yours sincerely, Roger Oberholtzer Ramböll RST / Systems Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Have you given consideration to that IPv6 tunnel method that I mentioned
earlier? It should work very well in this situation. A bit. We are not using IPv6 on our internal network. Wouldn't that be required to use this?
If you run Ethernet, your network already supports IPv6. As for your application, if you are using a single computer to access the remotes, you don't have to support IPv6 beyond that computer. You would just run the tunnel client in single address mode. You'd then have to ensure the UDP port for it is enabled through the firewall. If you want several computers to be able to use IPv6, then you could use the client in router mode which will provide a subnet available to all computers. However, if you do that, you definitely want to talk to your IT guys. With this client, you tunnel to a "tunnel broker" to access the IPv6 Internet. IPv6 is supported on Linux and with Windows staring with XP SP3, so if you have a subnet & router, it will just work. BTW, that client uses UDP if behind NAT or IP protocol 43, if connected to a public IPv4 address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
How best to do this? Our biggest worry is that we may make assumptions about what the local telephone companies allow. My initial thought is to use some dynamic DNS service. I guess that assumes that there is a route back to the telephone. I have seen suggestions that a tunnel be created. Might that be more robust in the light of local phone company differences? I guess we need a 'lowest common denominator' solution.
A *BIG* problems is that many cell companies provide RFC1918 addresses to the mobile devices and then use NAT to reach the Internet. If that's the case with the company you use, then there's no way you'll be able to reach them. The way around that is to use a VPN from the remote computer that can pass through NAT. Another is to use an IPv6 tunnelling protocol that can pass through NAT. I use one from http://gogonet.gogo6.com. This tunnel works through NAT and provides a public IPv6 address or subnet, depending on configuration. In order to get a static address, the remotes will have to register the connection. Otherwise, the address will change. I have an IPv6 subnet configured on my home network that has 2^72 addresses. I run the client in single address mode on my notebook computer, when I'm away from home. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Sep 10, 2012 at 1:45 PM, Roger Oberholtzer
I would like to enable remote access to openSUSE systems that are running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them.
The idea is to use a telephone with a local phone company SIM (supplied by the local owner of the system), connected to the openSUSE box via a USB cable. Obviously the local phone company has to allow tethering in such a way that one can find the telephone. It is not enough that the telephone can find us.
How best to do this? Our biggest worry is that we may make assumptions about what the local telephone companies allow. My initial thought is to use some dynamic DNS service. I guess that assumes that there is a route back to the telephone. I have seen suggestions that a tunnel be created. Might that be more robust in the light of local phone company differences? I guess we need a 'lowest common denominator' solution.
Anyone know of a good tutorial on this? Something written this century. There seems to be lots of old info that is usually very incomplete. And they all seem to be about using the connection to access the internet. Not for the internet to access you. I must be crap at choosing search words...
I'm guessing your problem is, you need to connect to the remote computer, but you don't know at any point what that remote IP will be (employee laptops in a mobile situation using GPRS/3G/Edge via mobile networks to connect, and the employee cannot be expected to discover and inform you what the temporary IP address is) Just brain storming here... - Use a standard mobile phone with a data contract - Enable WiFi hotspot on a mobile phone when a connection is required at a remote location (definitely possible with Android phones, not sure on iPhones... last iPhone I had, tethering wasn't allowed unless I rooted the phone) - Use standard WiFi to connect the laptop to the WiFi hotspot provided by the mobile phone - Use ddclient in combination with DynDNS to auto-assign a URL/subdomain to the mobile device - You should then be able to connect to the remote computer using a preassigned domain/subdomain for that device.. (simplified example: ssh rogersscomputer.ramboll.se) In theory you should be able to use a service like DynDNS to assign a known URL to a dynamically changing IP address. The software that you use on the client-side (ddclient) is included within the openSUSE repositories. I've found that if you set a reasonable check interval (whatever your definition of reasonable is), DynDNS reacts very quickly and you have a valid URL/domain/subdomain you can connect to. DynDNS provides a web-tool to create your ddclient.conf file. You would need to prepare each remote computer at some point, installing ddclient and enabling the service... opening any ports etc for your remote login. Another thought, depending on what level of remote access you require... you could install TeamViewer on each remote computer, note the unique 9 digit ID TeamViewer assigns that computer. Then the remote employee only has to connect to his/her WiFi hotpsot provided by his/her Android phone, launch TeamViewer (desktop icon) and tell you the 4 digit one-time-use password that TeamViewer generates for that session. You can then log in and have full GUI access as that user (and can su to root as needed). C. -- openSUSE 12.2 x86_64, KDE 4.9.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Sep 10, 2012 at 2:16 PM, C
Just brain storming here...
- Use a standard mobile phone with a data contract - Enable WiFi hotspot on a mobile phone when a connection is required at a remote location (definitely possible with Android phones, not sure on iPhones... last iPhone I had, tethering wasn't allowed unless I rooted the phone) - Use standard WiFi to connect the laptop to the WiFi hotspot provided by the mobile phone - Use ddclient in combination with DynDNS to auto-assign a URL/subdomain to the mobile device - You should then be able to connect to the remote computer using a preassigned domain/subdomain for that device.. (simplified example: ssh rogersscomputer.ramboll.se)
In theory you should be able to use a service like DynDNS to assign a known URL to a dynamically changing IP address. The software that you use on the client-side (ddclient) is included within the openSUSE repositories.
I've found that if you set a reasonable check interval (whatever your definition of reasonable is), DynDNS reacts very quickly and you have a valid URL/domain/subdomain you can connect to. DynDNS provides a web-tool to create your ddclient.conf file. You would need to prepare each remote computer at some point, installing ddclient and enabling the service... opening any ports etc for your remote login.
Another thought, depending on what level of remote access you require... you could install TeamViewer on each remote computer, note the unique 9 digit ID TeamViewer assigns that computer. Then the remote employee only has to connect to his/her WiFi hotpsot provided by his/her Android phone, launch TeamViewer (desktop icon) and tell you the 4 digit one-time-use password that TeamViewer generates for that session. You can then log in and have full GUI access as that user (and can su to root as needed).
Crap, I forgot about the RFC1918 thing... as already noted, that puts DynDNS out of the running. Will a TeamViewer solution work in this case? i've had that app work in situations where nothing else would work... but never tried it over a mobie connection. C. -- openSUSE 12.2 x86_64, KDE 4.9.1 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
C wrote:
- Use a standard mobile phone with a data contract - Enable WiFi hotspot on a mobile phone when a connection is required at a remote location (definitely possible with Android phones, not sure on iPhones... last iPhone I had, tethering wasn't allowed unless I rooted the phone) - Use standard WiFi to connect the laptop to the WiFi hotspot provided by the mobile phone - Use ddclient in combination with DynDNS to auto-assign a URL/subdomain to the mobile device
The problem is that mobile carriers generally assign RFC1918 addresses to mobile devices. This means that the phone is unreachable. DynDNS can't help here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/10/2012 05:16 AM, C wrote:
I would like to enable remote access to openSUSE systems that are
running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them.
We had to do this to allow home-based sysadmins access to a server located in a foreign country that didn't have wired Internet connectivity. Command-line level access was fine. We used a cell-modem USB card from AT&T connected to a USB firewall- router with RJ-45 jacks. The router had wifi, but the server didn't. There was no problem with outgoing ssh connections, but the subnet AT&T assigned to the cell-card was RFC-1918 IPV-4 (private subnet) and so wasn't directly reachable from the outside. So we set up a third intermediary server and used ssh's port forwarding capability to forward the cell-card server's port 22 to an arbitrary port on the intermediary server. The home-office admin would then ssh to the pre-arranged port (maybe 2222?) and thus would connect to the cell-modem server on the private subnet. This of course required that an ssh session was maintained from the remote end, but it worked since we had someone on-site to restart it when the connection crashed. This could have been automated of course. The connections we got were rather bad, with large round-trip packet times. Forget about X-11. But it worked well enough for our requirements. I can forward the ssh port-forwarding ju-ju if anyone's interested. If there's a better way to do this, please let me know! Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer
I would like to enable remote access to openSUSE systems that are running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them.
The idea is to use a telephone with a local phone company SIM (supplied by the local owner of the system), connected to the openSUSE box via a USB cable. Obviously the local phone company has to allow tethering in such a way that one can find the telephone. It is not enough that the telephone can find us.
How best to do this? Our biggest worry is that we may make assumptions about what the local telephone companies allow. My initial thought is to use some dynamic DNS service. I guess that assumes that there is a route back to the telephone. I have seen suggestions that a tunnel be created. Might that be more robust in the light of local phone company differences? I guess we need a 'lowest common denominator' solution.
Anyone know of a good tutorial on this? Something written this century. There seems to be lots of old info that is usually very incomplete. And they all seem to be about using the connection to access the internet. Not for the internet to access you. I must be crap at choosing search words...
Yours sincerely,
Roger Oberholtzer
Ramböll RST / Systems
Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________
Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se
I do this to a old laptop nat'ed behind a cheap router. The laptop has a non-routable ip. On laptop: ssh -R (creates outbound socket to a stable server) autossh (wrapper that makes ssh -R robust, part of opensuse) On server, ssh forwarder (I don't recall details)
From any pc in the world, ssh -p my_port server_name
I do something similar to run a webserver on that same laptop. It's not fancy, but it works from the internet. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On laptop: ssh -R (creates outbound socket to a stable server) autossh (wrapper that makes ssh -R robust, part of opensuse)
The problem with that is you're running TCP on top of TCP which can cause flow control problems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I would like to enable remote access to openSUSE systems that are running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them.
Forgot to mention, Android phones support IPSec. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 10 Sep 2012 23:45:10 Roger Oberholtzer wrote:
I would like to enable remote access to openSUSE systems that are running in road vehicles around the world. The idea is to use tethering via a USB telephone. The thing is that we want to access the devices remotely. It is not that the vehicles need to access anything. We need to access them.
The idea is to use a telephone with a local phone company SIM (supplied by the local owner of the system), connected to the openSUSE box via a USB cable. Obviously the local phone company has to allow tethering in such a way that one can find the telephone. It is not enough that the telephone can find us.
Back around 2000, I work on a setup where around 100 linux servers connected back to base via TCP/IP dialup via Telco sevices that allocated dynamic IP addresses. The call initiation was at the client end and there was no way to connect/call the remote end. So this sounds somewhat similar to your situation - I'll describe the approach we took in case it sparks some ideas. What we did is to install software on the client that would initiate calls, both on a load-determined periodic schedule and when critical events occurred (e.g. if the person at the client end toggled the UPS power, the client would connect to base). We layered IPSEC over the top of the carrier network and a incoming IPSEC server at base would identified each client by its associated IPSEC key and initiate a "session" with a "central host". The central host would only see our higher level VPN addresses, not the carrier level addressing. The host would them drive the whole conversation, pushing and pulling data from the remote end. The idea was to keep the client connection software simple so that it could not stuff up - implemented with shell scripts. Complexity was confined to the application level software (Java). If I were to repeat this with Android, which bits to implement in the phone or on the client would again be dictated by trying to make the implementation of the client side simple - the connection software cannot fail, there is no inexpensive way to fix it if it's not working. Whether I'd use IPSEC would also be revisted - not sure what the state of play is with VPN's these days. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
C -
Greg Freemyer -
James Knott -
Lars Müller -
Lew Wolfgang -
Malcolm -
michael＠actrix.gen.nz -
Per Jessen -
Roger Oberholtzer