Hi,
I have a workstation with a private IP address getting its signal from a wireless AP that is behind a cable modem. I would like to SSH into another workstation with a private IP address getting its signal from a wireless AP that is behind a cable modem. Can I do this? If so, how?
Thanx, John
snipped-for-privacy@gmail.com hath wroth:
Yeah, it's easy with dynamic DNS. Your routers or an application running on the computahs updates the WAN IP address to a dynamic DNS service provider. You don't need to know the IP address of the other side of the link, just the FQDN (fully qualified domain name).
List of dynamic DNS service providers:
You will need to configure the router on the receiving side -- the only box there with a real Internet IP address -- to forward connections to a chosen port to the internal SSH server you want to reach.
You can then use the naming schemes suggested (e.g. "dyndns.com" etc.) to ease reaching the router by having a name for it, and in case its address changes.
The short answer is no. The longer answer is maybe. private ips are better called unroutable IPs. Now, the cable provider may give your cable modem a public IP address. On the other hand they may not. If they do, and your cable modem also acts as a router, and that router allows port forwarding then you could ask the routers to forward port 22 to your internal machine.
Unfortunately the updates to the public routing tables are usually very slow. A week is not uncommon. And in a week your IP on your modem/router may have changed 7 times. Ie, it will depend not only on the dynamic dns but also on how often your local dns server updates its cache.
Unruh hath wroth:
True. Most broadband providers supply routeable IP's to their customers. I know of some that do not. However, these also have the option of redirecting a routeable IP address to the non-routeable private IP delivered to the customer. It's kinda like the misnamed DMZ feature in most small routers. Many wireless ISP's do this to avoid having to beg or pay for a large block of routeable IP addresses. Most home users don't require a routeable IP. Of course the ISP's charge for this feature.
A cable modem is a bridge, which knows nothing about routeing. There are cable routers, which combine a cable modem and an ethernet router in one package.
Not exactly. I just added a new sub-domain to my dyndns.com account. About 3 minutes to get recognized by my ISP's nameserver. My DNS lookup initially went to the authoritative nameserver at dyndns.com for my domain and did the lookup. No big deal for sub-domains. As long as the resolver can find an authoritative nameserver for the domain, the updates are almost instantaneous.
What methinks you're thinking of is new domains. These can take a few days because the local nameserver doesn't have a clue who the authoritative nameserver is for that new domain. Last time I created a new domain on Joker.com, it took about 2 days for SBC to get the update. About the same for 1and1.com.
It's really loads of fun when the local ISP's primary and secondary DNS servers don't agree. I've been there a few times. They were intentionally delaying updates on the secondary so that if the primary got trashed during an update, the secondary would still be useable.
Most of the local ISP's flushes their DNS cache once per day.
If using W2K or XP don't forget about the local DNS cache. ipconfig /displaydns ipconfig /flushdns
You mean you want to connect from outside into a box that's behind a NAT system?
This is easy if the NAT device (your AP, in this case) supports "port forwarding" - set it so that port 22/tcp gets forwarded to the appropriate internal address.
-- Mark Rafn snipped-for-privacy@dagon.net
YMMV. I had a Telus ADSL and when they would change my routable address, it usually took almost a week for the change to propagate to the University where I work. I think that Telus put a long "stale date" on the DNS address and/or the DNS caches here took a long time.
I also changed the address of one of my mail machines here, and mail was still being delivered to the other one a month later. (Ie, there were DNS caches out there that had not refreshed themselves for a month).
Do NOT trust that just because your DNS server is serving out the new address that anyone else in the world knows it. If your provider changes the address more ofteh than once in a few months the chances of your being able to use DNS to discover the new address are slim.
Nope. Simple address change of a dynamic address associated with a fixed name. Or simple MX record change to another machine on exactly the same subdomain.
string.physic.ubc.ca to info.physics.ubc.ca or a simple IP change to the same address.
Whatever the cause the symptoms are that you cannot trust DNS to get your name or IP change out there anytime soon.
Unruh> The short answer is no. The longer answer is maybe. private Unruh> ips are better called unroutable IPs.
That doesn't make sense -- any IP address is perfectly "routable;" entire organizations with large, complex networks route these packets every day. The are correctly called "private" addresses for their intended use: they must be kept within private networks, since they are not globally unique and hence cannot be used on the public Internet.
Besides, these address ranges are defined in RFC 1918, entitled "Address Allocation for Private Internets," which refers explicitly and repeatedly to "private address space" and "private addresses."
Unruh> Unfortunately the updates to the public routing tables are Unruh> usually very slow. A week is not uncommon.
I'm sorry, but this is nonsense. Convergence time for routing protocols is commonly measured in seconds, a few minutes at the outside perhaps for changes in the topology of the Internet at a large scale involving complex BGP relationships.
Also, this has nothing to do with the text preceding your comment: he was talking about the DNS; you responded with a comment about routing tables.
Now perhaps, you meant to say something about changes to the DNS, rather than "routing tables." Even allowing that, your comment is still incorrect. Changes to second-level delegations (as when you register a new domain or transfer one) take two days to be completely effective once actually done by the TLD nameservers, since that is the enforced TTL on those NS records. But this fact is irrelevant to a service such as dyndns.org, which is changing records within their own zones, and can change them just as quickly as it likes. These names can be updated within seconds or minutes of a DHCP change on a client.
Unruh> depend not only on the dynamic dns but also on how often your Unruh> local dns server updates its cache.
The "local DNS server" does not determine this; it is determined on a per-RR basis by their TTL values, which are in turn set by the owner of the containing zone -- in this case, the "dynamic DNS" service provider.
The trick is not to rely on your service provider to update DNS records. I use a 3rd party DNS provider and an applet on my PC that checks the router WAN IP every 15 mins and updates my DNS entry appropriately. Mark McIntyre
Yes you can. If you are on the same network it is a complex matter of knowing the IP of the other machine, setting the firewalls to allow port 22, having an ssh server running on the other machine and on port 22 (default), and having an account on the other machine. If the 2 machines are on different networks then the router has to additionally allow port forwarding for port 22 as well as direct the incoming connection to the IP of the destination machine. I remotely connect to my network from another network this way.
Jeff,
So, couldn't I write a script that flushes the dns cache and then performs a direct dns query to one of the dyndns DNS server, and then have the remote workstation run the script before I attempt to SSH in?
Thanx, Ed
You can switch, at least to try, from SSH to ViPNet. ViPNet VPN is more flexible the SSH to help you.
snipped-for-privacy@gmail.com hath wroth:
I'm not sure what that would accomplish or what problem that would solve. The client on the other end of the SSH session is not registered in the internet DNS datapile unless you arrange for a dynamic DNS service provider (which is what I previously suggested). You could register a private domain and then create sub-domains for each machine. I've seen that done, and rapidly un-done when they discover that such DNS updates are not sufficiently fast to maintain connectivity. A DDNS service provider such as dyndns.com has clients that check for changes in IP every 5 minutes with short TTL (time to live) for their DNS records. My guess is that any change will be publicly available in perhaps 10 minutes. Try the same stunt with an ISP's DNS server and it will take a day or more. Of course, you could run your own public DNS server, which would give you more control, and probably solve the update delay problem. I know some corporations that do just that and do have all their workstations registered in sub-domains. I don't think the effort involved is justified for just a single SSH session. Keep it simple.
Some details on DNS (which are only marginally relivent). You could easily flush your DNS cache on the workstation with: ipconfig /flushdns However, you cannot do that so easily if your routers (there are two in this system) cache DNS queries. The only way to do that on a cheap router is to power cycle the router. The solution is to just not use the DNS cache on the routers and point your clients DNS servers directly to the ISP's DNS server. Some routers have provisions for setting DHCP assigned DNS servers to fixed IP's other than the router itself. Some don't.
If I read between the lines of what you're suggesting, your script will eventually provide the exact same functionality as a DDNS service. The remote client finds the WAN IP address of its router,
Incidentally, the most common screwup with DDNS is forgetting to disarm the XP and W2K DNS update mis-feature. See:
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.