Question : IP Address

Hello all!

Let suppose I have 3 servers.

I am on the first server with the IP address: X.
I'm trying to view a page that is on the second server that has the IP address Y. The second server after I enter the correct information is sending me to the 3rd server. Between the second and third server is a firewall that allows only the IP address: Y, of the second server to get in.

But when I test to see which IP address is coming to the third server is my IP, from the first server (X).

How can I avoid that? I want to get to the third server with the second server IP address (Y).

first server: IP address: X ---> second server: IP Address Y ---> 3rd Server

Thank you, Radu

I got an answer from ASPGuru with a DLL, but is there any software solution (i mean proxy application or router)?

Answer : IP Address

I hate to shoot down my own answer, but here it goes..

The problem primarily rests on what the page on Z looks like. If the page is not really a page, but a whole website with links and everything, then when you present the page to X and they click on something they are going to be going directly to Z.

Now, if you install a proxy on Y and tell the X client to use that proxy, this may work, but the problem is that ALL traffic from X would go to Y, not just the traffic trying to get to Z.

What you need is to have X go to Y for all of it's Z pages w/out it knowing that Z even exists.

One solution using perl is more complex than you may want:

a) When the page in Y presents a link that the user will click on to get to Z, in reallity it will be alink to:

   Ysite.myco.com/perlcgi?http://Zsite.myco.com/Zpage.html

Clicking on it invokes Y with the Z link as an argument.

b) The "perlcgi" script looks at it's paramter and retrieves the page (pretending to be a web client).

Here is you have a choice. You can either:

c) Scan the Zpage.html as it goes through the perlcgi script and gets forwarded to X, converting ALL the links on the page to Ysite.myco.com/perlcgi?<link> redirections (this includes html, gifs, etc.).

Pros: Can handle virtually any kind of page on Z.

Cons: Very complex. For example, if the link is to a GIF file that resides on Z:

  <IMG HREF="http://Zpage.myco.com/gifs/mygif.gif">

It would need to convert that into

  <IMG HREF="http://Ypage.myco.com/perlcgi?http://etc..">

This causes a separate instance of perlcgi to be invoked that requests the GIF. So the perlcgi needs to know the difference between processing an HTML and processing a GIF. And don't even let me get started on the security issues..

So just because it's TECHNICALLY feasible, doesn't mean it's a good answer.

A very different approach is that the script on Y access the Z pages, parses them to extract the relevant information, and produces a NEW page that is returned to the X client. The new page is a page on Y that was built for that one access.

Pros: This is how CGI is supposed to work, including JSP, ASP, etc. Clean, secure.

Cons: Works only if the Z info can be extracted and formatted. That is, if Z can be thought of as a "database" of information that is retrieved to build the "dynamic" pages. Only instead of using SQL to access the data, you use HTML and you parse the data out of the resulting Z page.  Obviously this only works if you know exactly what the pages on Z look like so you can parse them.

Maybe all the stuff I spewed here will inspire someone with an alternate solution. You may also want to post this in the PERL area.

Dave