> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Marcus Watts > Sent: Friday, July 21, 2006 4:21 PM > To: misc@openbsd.org > Subject: Re: Forward IP to remote location > > Various wrote: > > Subject: Re: Forward IP to remote location > > Date: Fri, 21 Jul 2006 15:47:24 -0400 > > Message-ID: > <[EMAIL PROTECTED]> > > From: "Dan Farrell" <[EMAIL PROTECTED]> > > To: "Nguyen Manh Thang" <[EMAIL PROTECTED]>, <misc@openbsd.org> > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > > Of > > > Nguyen Manh Thang > > > Sent: Friday, July 21, 2006 6:00 AM > > > To: misc@openbsd.org > > > Subject: Forward IP to remote location > > > > > > Hi, > > > I'm trying to forward one or more IP addresses from one location to > > > another. Location A has xxx.xxx.xxx.96/27 IP addresses. In Location A > > > there > > > is a CISCO Router, but I don't have access to this router. Location B > > is > > > connected to the Internet using cable modem. The IP address that > > comes to > > > the server in location B is 10.1.70.40, as you can see this is not > > ratable > > > IP address. Is there a way to run HTTP server at Location B using one > > of > > > the IP address in Location A? > > > > > > Thank you, > > > > > > Rossen > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > --- > > > --- > > > > > > I have the same your question. You not do yet? > > > > > > pls lead me do. > > > thanks > > > manh thang > > > > Maybe I'm missing something, but... Nope. > > > > When a surfer to your site wants to go xxx.xxx.xxx.98 they will go to > > location A, not to whatever cable modem location site A is at. The only > > way to make certain IP addresses appear to be coming from locations they > > weren't intended to come from (and have actual two-way communication) is > > as a result of hacking one or more networks. > > > > If this kind of thing worked, people would be hijacking websites left > > and right. > > > > > > Dan Farrell > > Applied Innovations > > [EMAIL PROTECTED] > > There's at least 3 ways to do this. 2 of them require physical > presence at the "bounce" site. The 3rd requires some form of > "trusted" access. > > Way #1 -- at location A, allocate an IP address and install a bridge. > The bridge should route all traffic for that IP address to location B, > possibly via some form of vpn or tunneling. At location B, attach > the web server to the other end of the bridge & give it the assigned > IP address. You might find it convenient to do some form of NAT somewhere > in here to map addresses. > > Way #2 - at location A, install a proxy squid server, and sshd. > On the web server at location B, make an ssh connection to the squid > server > that will forward remote connections from a given port to the web server > on the local host. Now teach the proxy squid server to talk to the > designated port that will forward via ssh to the remote server. > You don't need the proxy squid server if you can stand using > a non-standard port number >2048 in your URLs, or if you're > willing to make your sshd connection as root and forward 80. > > Way #3 - the CISCO router at location A probably has some means of > acquiring routing information. Supply it routing information that will > route data to for the designated location A IP address to location B. > You'll need to convince each intermediate point between A and B to > cooperate. If you can't establish such a path to B, you'll need > need to acquire some location C where you can have physical presence > and a routable path back to A. From location C you can of course use > #1,#2 to reach B. Unless you *really* value the routable IP address at > location A, AND you can convince the folks at location A to let you do > this, you're probably better off not doing this. > > Common factors to all of these: > > yes you can use openbsd for all the pieces. > (I'm not sure openbsd has any other specific > connection to this problem.) > you need some way to route incoming connections > to something at location B. If you can't directly > accept incoming connections on something at location > B then you need some form of network forwarding to > some point where you do have such access. > you need *some* level of cooperation at location A. > You need *something* at A that will see the incoming > packet connection for your public IP address at A, > that can *somehow* point this towards B. > This doesn't need to be the Cisco router, > but it does need to be something the router > can see. > > The last constraint is why you don't see people hijacking > websites left & right. > > -Marcus Watts >
Respectfully, I don't agree with the solutions (I can comment further if goaded) but for me it comes down to something simpler- "You'll need to convince each intermediate point between A and B to cooperate" = "You'll need to convince the Internet to cooperate." That's why I say it won't work... 'the Internet' isn't going to work with someone on this. Dan Farrell
