I was gonna disregard your comment as flamebait, but then i decided i'd rather respond.įirst off, I disagree somewhat with the opinion that this ISP is neglecting their goal of providing service. Nothing will ever change unless people start Tell them what do you want them to change.įor the love of God, not the other way around. Tell them why you need NTP for security reasons (to have your logs useful). We all know that using SSH or NTP is not insecure in itself, but when everyone tunnels everything bastardizing HTTP protocol, no one will ever notice when some day there is Back Orifice traffic hidden there between NTP, SSH, Telnet, FTP, IRC, et cetera. Insecure (in the opinion of firewall management team) protocols traffic are ruined when their You also compromise the firewall security if you use covert channels to hide all the forbidden traffic. Two-way TCP traffic (like IRC, SSH, FTP, Telnet. Tunnel anything which uses long and interactive I am sorry, but the only reasonable advice I can give you is to change your ISP if they do not open more ports.Īre you also going to tunnel them through HTTP? I would like to sync the system's clock using NTP.ĭoes anyone know of any public time servers that can do some type of NTP over HTTP, to get through the firewall? My ISP keeps my server behind a tight firewall, only allowing outgoing HTTP(S) and SMTP. But when they're talking about kernel patches on the main page, I can pretty much guess it's not going to be 2 minutes and fiddle-free. I went to the CIPE site and they don't even have documentation online (downloadable texinfo format doesn't count, any more than if it were available in Sumerian on a stone tablet under a camel somewhere) so I can't get a sense of the scale of the installation process. In a few minutes I can explain over the phone or via IM to anyone, regardless of partial language barriers, how to set up their end of the link. Possibly more importantly for my applications, though, ppp-over-ssh can be implemented in about 2 minutes using ubiquitous components - no fiddling around or building of complex software is required. And the rsync job proceeds at the expected rate. Keyboard echo is slow during that time, but not any more than I'd expect across a fully-congested slow line halfway around the planet. I'm using ppp-over-ssh in a few sites now, including one where I have to open an inbound terminal session over the top of a 2-hour daily rsync job that completely saturates the 128K line in question. Try using TCP-over-TCP in a congested network, and watch it grind to a halt. You've probably never used it when that happens. there's even a nifty hack to tunnel stuff through http proxy. it does work as a solution to arrange ssh from 'the wild' to computers behind firewall, for example if your cablemodem/adsl/whatever isp is retarded in their pricing schemes. there is no problems with this tcp-over-tcp solution, the connections aren't unreliable or like that, granted i haven't tried it with sh** connections like 14kbps modems or so. It's very possible to be behind a firewall, forward a port on outside of the firewall computer with ssh to the computers thats behind the firewall port 21, and serve ftp while being behind the firewall that doesnt allow incoming connections.(note that the transfers don't 'proxy', but rather go straight, pasv doesnt work though.). udp over tcp (with use of ppp or whatever) is where it gets nasty, sometimes though being the only solution possible, because of either retarded mcse bofhs or other reasons.(ppp-over-tcp isn't possible at the moment though with just plain windows solutions, unless somebody has made some nifty hack during last month)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |