Gilles 'SO- stop being evil''s questions

I'm trying to understand what this output from traceroute means. I changed the IP addresses for privacy but retained the public/private IP range distinction.

traceroute.db -e -n 10.1.1.9
traceroute to (10.1.1.9), 30 hops max, 60 byte packets
 1  10.0.0.1  0.596 ms  0.588 ms  0.577 ms
 2  10.0.0.2  1.032 ms  1.029 ms  1.084 ms
 3  10.0.0.3  3.360 ms  3.355 ms  3.338 ms
 4  23.0.0.4  3.974 ms  4.592 ms  4.584 ms
 5  23.0.0.5  13.442 ms  13.445 ms  13.434 ms
 6  45.0.0.6  13.195 ms  12.924 ms  12.913 ms
 7  67.0.0.7  52.088 ms  51.683 ms  52.040 ms
 8  10.1.1.8  46.878 ms  44.575 ms  44.815 ms
 9  10.1.1.9  45.932 ms  45.603 ms  45.593 ms

The first 10.0.* range is inside my organisation. The last 10.1.* range is another site of my organisation. The intermediate addresses belong to various ISPs. I expect that there is some kind of VPN between the two sites, but I don't know much about our network topology.

What I don't understand is how the route can go from a private address through public addresses back into private addresses. Searching led me to Public IPs on MPLS Traceroute, which gives a possible explanation: MPLS. Is MPLS the only possible or most likely explanation? Otherwise what does this tell me about our network infrastructure?

Bonus question for my edification: in this scenario, who is generating the ICMP TTL exceeded packets and if relevant mangling their source and destination addresses?

I have an unreliable network connection between two machines: sometimes active TCP connections get dropped for reasons beyond my control. I want to establish a reliable TCP connection between the two machines.

If the network was reliable, I'd just run ssh -L 1234:localhost:1234 remotehost, with the server listening on port 1234 on remotehost, and point the client at localhost:1234. But if the ssh connection dies, so will the forwarded connection. How can I arrange to automatically restore the connection between the client and the server?

Non-solutions:

• This isn't for interactive applications, so screen does not apply.
• This isn't just about reconnecting an SSH tunnel automatically, � la autossh. I want to continue using the same tunneled TCP connection, not start a new one.
• In principle, a VPN would do the trick. But it seems overkill when I just want one TCP connection, and I'd like a solution that works even if I don't have root permissions on either side.

I have a dim memory of a program called rocks that did just that, but it seems to have fallen off the face of the web. I'm mostly interested in Linux on both sides (though I'd expect a program at this level to be portable to other unices), but if you know of a program that works between QNX and VMS, all the better.

Consider a firewalled network with the high-level requirement that normal web browsing should work, but nothing else (e.g. ssh and Skype are forbidden). All traffic is blocked, except for outgoing HTTP(S) traffic which goes via a mandatory proxy.

What should the proxy do with HTTP CONNECT traffic? At one extreme, it could allow everything through, which would make the firewall ineffective. At the other extreme, it could be blocked: would this completely block HTTPS (I've noticed that wget uses CONNECT to tunnel https through $https_proxy: is this the universal method?)? (Assume the proxy is not going to play man-in-the-middle hoping that clients wouldn't notice the fake certificates.)

In other words, what is the practical “normal” use of CONNECT (with a proxy in the mix), and what is a good approximation of restricting its use to the “normal” cases?

_{(This is what I meant to ask when I asked my previous question.)}

Consider a firewalled network with the high-level requirement that normal web browsing should work, but nothing else (e.g. ssh and skype are forbidden). (Incoming connections are denied as a matter of course.)

What should be done to HTTP CONNECT traffic? At one extreme, it could allow everything through, which would make the firewall ineffective. At the other extreme, it could be blocked: would this completely block HTTPS? (Assume the firewall is not going to play man-in-the-middle hoping that clients wouldn't notice the fake certificates.)

In other words, what is the practical “normal” use of CONNECT, and what is a good approximation of restricting its use to the “normal” cases?