Author Topic: IP routing in Linux (Read 3640 times)

edy · « **on:** November 06, 2018, 06:49:57 pm »

Hi folks,

I am looking for a way to re-route one IP address to another (or at least that is what I think is needed). Let me explain the background of the issue and why I think it is needed.

There is a website I am accessing at say 10.20.40.80 (I randomly came up with those numbers). It returns to me HTML pages with content links but the problem is all the links for content in the page have the IP of my own local host (192.168.1.1) or some other strange IP (10.0.0.1, or 0.0.0.0, or whatever) substituted as all the links (that is, they are HARD-CODE in the HTML page code).... instead of the actual location of the files (10.20.40.80).

That is, say I browse to the page on "http://10.20.40.80/images.html" the HTML file that is returned has links that are in the format "http://0.0.0.0/image1.jpg", "http://0.0.0.0/image2.jpg", "http://0.0.0.0/image3.jpg" , etc... (for example). So what I do now is save the HTML file, use "sed" to substitute all instances of 0.0.0.0 (or whatever that particular site uses) to the ACTUAL IP address location where the images are (10.20.40.80). Then when I open up my substituted HTML page (the one I used "sed" on to replace all hard-coded IP addresses), it correctly loads all of the images.

If there was some way either in CHROME or in the IP routing table to tell Linux that from now on, every time you see the instance 0.0.0.0 (or whatever IP that particular site happens to be using that is incorrect) to instead replace it with the REAL IP of the site (10.20.40.80) then even if the HTML page comes back with the wrong IP addresses, clicking it will still lookup the correct IP (that is, all requests to 0.0.0.0 will be routed to the correct IP 10.20.40.80).

Like I said, it works fine as long as I save, substitute and reload the HTML page. But I would rather not have to do that each time. I am not sure if this is something I need to do in the IP routing, or if there is a proxy table I need to setup in Chrome, or some other system.

I also need to be able to change these substitutions on the fly, and get rid of them when needed without having to reboot. In case anyone is wondering, this happens with a certain drive of mine being accessed remotely (outside my local LAN)... I can reach it remotely but it spits back HTML pages with some internal IP hard-coded in every page.

Any thoughts, help, suggestions would be appreciated. Thanks!

vtwin@cox.net · « **Reply #1 on:** November 06, 2018, 06:57:38 pm »

there is an iptables pre-routing table you can use to "re-route" traffic, but this wont work for you since the ip addresses from the remote site appear to be your public ip address.

e.g. you go to a web site at http://10.20.40.80

and in the html file returned by the server, it contains references to

where 100.120.140.180 is your public ip address.

so, if I have interpreted your dilemma correctly, the answer is no, there is not.

edy · « **Reply #2 on:** November 06, 2018, 08:29:50 pm »

I will explain a little more detail so it makes sense. I almost need a "plug-in" or to build something that will either rewrite the hard-coded IP's in the returned HTML file, or allow a substitution of the hard-coded IP with the REAL IP when clicking. Let me explain more....

Website I am accessing is let's say for example, 10.20.40.80

I go to http://10.20.40.80/images.html in my browser. OK. So it returns a web page, whose content for example is this:

Code: [Select]

<html>
<body>
Thumbnails:
  <img src="http://0.0.0.0/image1.jpg"> 
  <img src="http://0.0.0.0/image2.jpg">
  <img src="http://0.0.0.0/image3.jpg">
</body>
</html>

Obviously the browser shows no images because the IP hard-coded in the returned HTML file is wrong. In this case it is 0.0.0.0. In other cases, the IP may be 55.1.0.0. Whatever the case may be, it is CONSISTENT but WRONG.

NOTE: I did NOT write those HTML pages. They are automatically generated by the hard-drive software, and just reveal content in various folders on the drive. The problem is the software erroneously (or maybe on purpose) uses the wrong IP when it returns the HTML file listing the files. It doesn't actually put in the publicly-listed IP. So even though you can query the hard drive and get an HTML page back from outside (on the public internet), it is using some strange IP from I don't know where on the page. This could be 0.0.0.0, it could be 10.0.0.10, it could even sometimes be 192.168.1.1 or similar. But *NOT* the public IP.

I need that HTML file that is returned from the server at 10.20.40.80 to look like this:

Code: [Select]

<html>
<body>
Thumbnails:
  <img src="http://10.20.40.80/image1.jpg"> 
  <img src="http://10.20.40.80/image2.jpg">
  <img src="http://10.20.40.80/image3.jpg">
</body>
</html>

So in the second case, the hard-coded IP is correct and images are properly loaded. OK. So what I am doing now is SAVING the first HTML file returned (with 0.0.0.0 hard-coded in it) and doing a "sed" replace operation which takes 0.0.0.0 --> 10.20.40.80. The resultant HTML file (the 2nd example above) will properly load the images from the server at 10.20.40.80.

OPTION 1:

If there is some kind of "filter" or "plug-in" which will pattern-match to the "0.0.0.0" (or whatever the wrong IP happens to be) prior to the page loading, or doing a replacement substitution WITHIN the browser itself, that could work. In that case, all instances of "0.0.0.0" in the page will end up turning into "10.20.40.80" and the page will reference the correct server directories.

OPTION 2:

If I can do an IP-routing subtitution say for OUTBOUND requests, that turns a request for "0.0.0.0" to instead query the IP 10.20.40.80, then even though the hard-coded HTML page that is loaded contains references to "0.0.0.0" everywhere, my LINUX system would actually be going to 10.20.40.80 (instead of 0.0.0.0) to grab the file.... Since the file is at 10.20.40.80 and NOT at 0.0.0.0.

Otherwise, as I mentioned, I have to SAVE each HTML file I get back, run a "sed" on it to replace all IP's, then reload in browser... which in theory I could automate but it is annoying and wastes time.

technix · « **Reply #3 on:** November 06, 2018, 10:04:52 pm »

This is not an IP routing problem, instead it is a HTML rewrite problem. You need to either create some server-side script to do that, or have the web pages to generate with correct addresses in the first place.

Try read up on Web development to find out how. Do keep in mind that Web development mindset is vastly different from embedded development, where speed, efficiency and code size usually takes a back seat, while ease of maintainance and ease of development takes the front seat.

PlainName · « **Reply #4 on:** November 06, 2018, 10:19:13 pm »

I have this when using putty to SSH into a box and the onward link to some IP on their LAN. In that case, my initial URL is of the form http://localhost:8001/... and putty (rather, plink but that's a command line putty) forwards from my local port to the remote IP.

Anyway, the web configurator on, say, the router at the remote end sends back it's page and hard codes its address in the URL, so I get exactly the problem seen here. Instead of http://localhost:8001/... coming back I get http://192.168.1.10/... and naturally my browser gives up at that point.

I found a fix is to wait until that happens, then manually replace the 192.168.etc in the address bar with localhost:8001 whilst retaining the rest of the page URL and it then works fine. I assume this is because the page elements have relative URLs and once the browser knows the proper base URL then everything falls into place. Could be that the problem reported here has a different cause, but trying this fix doesn't cost anything except for 5-10 seconds of typing...

IanMacdonald · « **Reply #5 on:** November 06, 2018, 10:31:04 pm »

<Correction on seeing last post>

I take it this is a router you are trying to configure via an SSH tunnel? If so the problem is bad practice on the part of the router manufacturer -img tags in webpages should use relative URLs, not absolute.

One resolution might be to add the remote IP address 192... as a second IP address for your LAN card. Provided of course this IP isn't used anywhere else on your local LAN. Then that IP will effectively be regarded as localhost, which will load the images via local port 80.

cdev · « **Reply #6 on:** November 06, 2018, 10:57:43 pm »

I am kind of confused as to whose web page it is, and what exactly you are trying to accomplish.

Assuming that the web page is not your own-

Perhaps the page you are viewing is being hosted on a misconfigured server that its owner does not realize is such.

Under that situation, which happens a fair amount, when they view their own web page it works for them. But not for others.

Virtual hosting allows a lot of on the fly rewriting of web pages so people can put many separate virtual web sites - under different domains, on the same physical server.

Using URL rewriting rules on the server. Is that what you are trying to do? SSH wont help you unless you have a login on the server machine and need to work on it as if it was your own.

Then you can basically set up a tunnel to a specific port on the remote machine and point to it as if its 'localhost' or another host on your LAN.

If you dont need the benefit of the ssh tunnel, you may also be able to make a change in your 'hosts' file to make a certain web host resolve as a different one, just to you (make sure to remove it when youre done using it)

Another situation occurs sometimes when somebody uses a drag and drop web editor tool, - for people who dont know HTML, I suspect that many corporate web sites are set uup via that kind of tool, links can be created by drag and drop, and usually they work but if something is not configured properly, the URLs are wrong to everybody else but not to them. If thats the case you should shoot them a heads up that this is happening.

PlainName · « **Reply #7 on:** November 06, 2018, 11:01:17 pm »

Quote

I take it this is a router you are trying to configure via an SSH tunnel? If so the problem is bad practice on the part of the router manufacturer

Me? In one case, yes - BT Hub5/6, but also have the problem with TP-Link TL-WA801ND WAPs. SMC switches are fine, though, so some manufacturers can get it right

edy · « **Reply #8 on:** November 06, 2018, 11:07:27 pm »

If there was some way to tell my Linux machine that when it is trying to connect to say http://192.168.1.151.... (or whatever the misconfigured IP is like http://0.0.0.0/... or whatever being hard-coded into the HTML files) that it instead should be trying to connect to 10.20.40.80.

That is, I would run a command that tells my computer that 192.168.1.151 is ACTUALLY 10.20.40.80. When it tries to connect to 192.168.1.151, it would instead connect to 10.20.40.80. Then it wouldn't matter that the page is hard-coding the IP in the links (either image tags or otherwise). My machine would just "forward" the request to the new IP.

Another approach would be to use a script to "wget" the HTML page, then use "sed" to convert the bad hard-coded IP to the actual server IP, then load the corrected HTML page in the browser. I would then do this every time I browsed to another directory of images. Like I said it is annoying and I have been managing but surely there must have been a simple way.

Sort of like making an "alias" or symbolic link that says IP 0.0.0.0 => 10.20.40.80. The computer would treat 0.0.0.0 as a link to 10.20.40.80 and not actually try to go to 0.0.0.0.

cdev · « **Reply #9 on:** November 06, 2018, 11:14:51 pm »

man hosts

That file is the /etc/hosts file on most (all?) Linux distributions.

vtwin@cox.net · « **Reply #10 on:** November 06, 2018, 11:48:35 pm »

iptables -t nat -A PREROUTING -s bad.ip.address.here/32 -p tcp --dport 80 -j DNAT --to-destination 10.20.40.80:80

?

Not aware of any way to dynamically do this in Chome, although you could probably develop a plug in to do it, but AFAIK nobody has developed something, what you're asking for is something I doubt anyone has ever had the need for.

Ian.M · « **Reply #11 on:** November 06, 2018, 11:56:01 pm »

Rewrite the URL in A tags and/or IMG tags with a user script running in the browser. Use Greasemonkey under Firefox or Tampermonkey under Chrome/Chromium/Opera.

edy · « **Reply #12 on:** November 06, 2018, 11:56:48 pm »

Thanks, I tried the hosts file... Entered something like this:

10.20.40.80 192.168.1.100

While I expected this to basically translate or forward all requests made to 192.168.1.100 to the proper server address on the internet 10.20.40.80, it did not work. On the other hand, if I did this....

10.20.40.80 made-up-domain-name.com

This would load up the proper server website by going to that "fake" domain, no problem! My hosts file basically takes over as the primary DNS in this case, and looks up "made-up-domain-name.com" and passes me through to 10.20.40.80.

But when I give it another IP address, it doesn't work. Maybe I'll put quotes around it and see what happens. Like so....

10.20.40.80 "192.168.1.100"

Well it doesn't seem to work. If it did, I would just take the hard-coded IP coming back in the HTML file (such as 192.168.1.100) and make that be looked up in my hosts file as 10.20.40.80.... So all links and images in the HTML file will be actually redirecting lookups to 10.20.40.80. That works for text-based domain names but I can't seem to trick it into taking an "IP"-formatted type text and making the hosts file pull that.

I believe this is the fault of GOOGLE CHROME which figures that since it is an IP address, not text, it doesn't even bother going to the hosts file at all.

edy · « **Reply #13 on:** November 06, 2018, 11:58:12 pm »

Quote from: Ian.M on November 06, 2018, 11:56:01 pm

Rewrite the URL in A tags and/or IMG tags with a user script running in the browser. Use Greasemonkey under Firefox or Tampermonkey under Chrome/Chromium/Opera.

Hmmm... Thanks I will look into this! This may do the trick. I'll keep you posted.

edy · « **Reply #14 on:** November 07, 2018, 02:40:43 am »

Ok, I have installed Tampermonkey on my Chrome Browser on Ubuntu and created the following SCRIPT:

Code: [Select]

// ==UserScript==
// @name         IP_Changer
// ==/UserScript==

(function() {
    'use strict';

    // Your code here...
    var links = document.getElementsByTagName("a"); //array
    var regex = /(192.168.1.100)/ig;
    for (var i=0,imax=links.length; i<imax; i++)
    {
       links[i].href = links[i].href.replace(regex,"10.20.40.80");
    }

    var images = document.getElementsByTagName("img"); //array
    for (i=0,imax=images.length; i<imax; i++)
    {
       images[i].src = images[i].src.replace(regex,"10.20.40.80");
    }
}
)();

It is supposed to create an array (called "links") of all <a href> tags and also an array called "images" of all <img> tags. For each array, I am going through all of the tags and replacing the string matched by regex ("192.168.1.100") with the server IP address which is 10.20.40.80. Or so I thought.

I loaded up the following local HTML file and it did nothing:

Code: [Select]

<html>
<header>
</header>
<body>
<a href="http://192.168.1.100:80/image1.jpg">Test</a><br>
<a href="http://192.168.1.100:80/image2.jpg">Test</a><br>
<a href="http://192.168.1.100:80/image3.jpg">Test</a><br>

<img src="http://192.168.1.100:80/image1.jpg"><br>
<img src="http://192.168.1.100:80/image2.jpg"><br>
<img src="http://192.168.1.100:80/image3.jpg"><br>
</body>
</html>

My script above should theoretically change the HTML code to be this:

Code: [Select]

<html>
<header>
</header>
<body>
<a href="http://10.20.40.80:80/image1.jpg">Test</a><br>
<a href="http://10.20.40.80:80/image2.jpg">Test</a><br>
<a href="http://10.20.40.80:80/image3.jpg">Test</a><br>

<img src="http://10.20.40.80:80/image1.jpg"><br>
<img src="http://10.20.40.80:80/image2.jpg"><br>
<img src="http://10.20.40.80:80/image3.jpg"><br>
</body>
</html>

What am I doing wrong? I also added @match * and @include * to the UserScript area to apply to all websites. Nothing is happening.

sokoloff · « **Reply #15 on:** November 07, 2018, 02:45:35 am »

Quote from: edy on November 07, 2018, 02:40:43 am

My script above should theoretically change the HTML code to be this:

Code: [Select]
<html> <header> </header> <body> <a href="http://10.20.40.80:80/image1.jpg">Test</a><br> <a href="http://10.20.40.80:80/image2.jpg">Test</a><br> <a href="http://10.20.40.80:80/image3.jpg">Test</a><br> <img src="http://10.20.40.80:80/image1.jpg"><br> <img src="http://10.20.40.80:80/image2.jpg"><br> <img src="http://10.20.40.80:80/image3.jpg"><br> </body> </html>

Why not just change the HTML to this instead?

Code: [Select]

<html>
<header>
</header>
<body>
<a href="/image1.jpg">Test</a><br>
<a href="/image2.jpg">Test</a><br>
<a href="/image3.jpg">Test</a><br>

<img src="/image1.jpg"><br>
<img src="/image2.jpg"><br>
<img src="/image3.jpg"><br>
</body>
</html>

That way, it's portable to any server you want to host it on. (And will work on http or https, once you get that setup correctly.)

edy · « **Reply #16 on:** November 07, 2018, 02:53:49 am »

Quote from: sokoloff on November 07, 2018, 02:45:35 am

Why not just change the HTML to this instead?
That way, it's portable to any server you want to host it on. (And will work on http or https, once you get that setup correctly.)

I am not generating the code. It is being generated by the hard-drive software. When I access the hard-drive over the internet by going directly to it's internet-facing IP (in this case, 10.20.40.80 for example) it is replying with that HTML file that you see above (with hard-coded IP's of 192.168.1.100). That is probably the address of the hard-drive on the local network. It gives me that HTML page but none of the content is loaded, because the hard-drive software thinks I am accessing things from the local network (like a computer on the same network 192.168.x.x and the hard-drive say is at 192.168.1.100). If I was on the same local network it would load fine.

However, being outside the local network, I need to replace all of the 192.168.1.100's in the HTML page that I fetch to the internet-facing IP that the hard-drive is on... in this example, 10.20.40.80. So I am trying to use a script within the browser itself to substitute the local IP (being hard-coded into the HTML page) to the external IP (which is where the hard-drive resides on the internet). That way, the HTML page would correctly fetch all of the images and the links would be valid outside the local network from where I am trying to access the hard-drive.

As mentioned before, I was saving the HTML file, using "sed" to substitute/replace all 192.168.1.100 --> 10.20.40.80 and then reloading the resulting HTML file, and it would then grab everything from the hard-drive and show things correctly. However that is annoying as there are folders and directories and each time I browse to a new directory I have to repeat this task. If the script could do it for me, it would find "192.168.1.100" automatically on every page and replace it with "10.20.40.80".

NOTE: I found a small bug in my code above... regex should be /192\.168\.1\.100/ig (otherwise using only . it would match on any character, so even 192?168x?1?100 would match, where ? could be any character, whereas using \. means it has to be a period). It should be this:

var regex = /192\.168\.1\.100/ig;

Anyways, it still doesn't work.

edy · « **Reply #17 on:** November 07, 2018, 03:30:22 am »

OK.... Figured it out...

FIRSTLY, I can't just open a file:///test.html for tampermonkey to work. Unbeknownst to me, it has to be fetched from a web-server to work! Therefore I invoked a webserver using "python -m SimpleHTTPServer" in the directory with my test.html file, and then fetched it via the link http://0.0.0.0/test.html.

SECONDLY, I simplified the script significantly... It is now just a basic text substitution script:

Code: [Select]

// ==UserScript==
// @name    IP_Changer
// @match   *
// @include *
// ==/UserScript==

(function() {
    'use strict';

    // Your code here...
   document.body.innerHTML= document.body.innerHTML.replace(/192\.168\.1\.100/g,"10.20.40.80");
}
)();

All it does is go through the whole file looking for the 192.168.1.100 and replace it with 10.20.40.80 which is perfectly fine for the job!

Monkeh · « **Reply #18 on:** November 07, 2018, 03:58:09 am »

I'd just like to take a moment and say there's a 99.9% chance whatever this device is, it shouldn't be exposed.

BradC · « **Reply #19 on:** November 07, 2018, 06:20:35 am »

Quote from: Monkeh on November 07, 2018, 03:58:09 am

I'd just like to take a moment and say there's a 99.9% chance whatever this device is, it shouldn't be exposed.

I think you're under-selling that point by about 0.1%.

IanMacdonald · « **Reply #20 on:** November 07, 2018, 09:42:10 am »

If it's being accessed via an SSH tunnel, it isn't being exposed.

-Well, provided the firewall is set to only allow the SSH port to connect, and the password isn't 12345.

sokoloff · « **Reply #21 on:** November 07, 2018, 11:45:51 am »

Quote from: edy on November 07, 2018, 02:53:49 am

Quote from: sokoloff on November 07, 2018, 02:45:35 am
Why not just change the HTML to this instead?
That way, it's portable to any server you want to host it on. (And will work on http or https, once you get that setup correctly.)

I am not generating the code. It is being generated by the hard-drive software. When I access the hard-drive over the internet by going directly to it's internet-facing IP (in this case, 10.20.40.80 for example) it is replying with that HTML file that you see above (with hard-coded IP's of 192.168.1.100). That is probably the address of the hard-drive on the local network. It gives me that HTML page but none of the content is loaded, because the hard-drive software thinks I am accessing things from the local network (like a computer on the same network 192.168.x.x and the hard-drive say is at 192.168.1.100). If I was on the same local network it would load fine.

My main point wasn't who is generating the HTML; my main point was don't put the protocol and IP in the URLs at all, so that it will work from any browser that can hit the original resource.

Consider something like the following:

Code: [Select]

document.body.innerHTML= document.body.innerHTML.replace(/http:\/\/192.168.1.100:80/g, '');(Replace all occurrences of http://192.168.1.100:80 with the empty string.

sokoloff · « **Reply #22 on:** November 07, 2018, 12:05:51 pm »

This code might be slightly easier to understand by not having to do all the magic escaping to generate a global-search regular expression by hand:

Code: [Select]

document.body.innerHTML= document.body.innerHTML.replace(new Regexp('http://192.168.1.100:80', 'g'), '');(Replace all occurrences of http://192.168.1.100:80 with the empty string.)

Red Squirrel · « **Reply #23 on:** November 07, 2018, 03:13:41 pm »

I agree this is more a html/web design issue than IP routing issue. Don't hard code IP addresses in html. Instead setup a DNS server and then setup a proper domain/hostname. The IP only needs to be changed in the DNS server after that. You will need to submit the IP of the DNS server to a domain registrar so they can register it. Then you use ns1.yourdomain.com etc on your registrar to point a domain to that DNS server. So you will want a static IP for the DNS server at very least. Worse case scenario you can find a DNS service online that handles that part. Though if this is for intranet this this is much easier as you have full control of your IP space and can setup a static yourself.

Also, try to only use relative links. ex:

Code: [Select]

href="/page.html"
instead of

Code: [Select]

href="http://host/page.html"

Ian.M · « **Reply #24 on:** November 07, 2018, 04:00:51 pm »

I think everyone is missing the elephant in the room.

Code: [Select]

// ==UserScript==
// @name    IP_Changer
// @match   *
// @include *
// ==/UserScript==

Edy is running the replace on the body.innerHTML of *EVERY* web page he visits using Chrome (with Tampermonkey extension enabled). Obviously most of the time the replace doesn't find 192.168.1.100 in the page source so the innerHTML string is unchanged, but it still gets replaced so the page will re-render. That must be slugging web performance noticeably. It really needs to be restricted so it *ONLY* runs on pages at the external IP address of the server that's generating the pages with LAN only URLs in.

Portability, by making the URLs relative to the server root, isn't really that important as the user script fix has to be manually installed in each browser that's used to access it, and it will still need patching if the server's LAN address ever changes. Also the external IP address still needs to be hard coded in the script header, unless he goes to the trouble of setting up a full DNS server etc. at which point it would probably be worth setting up some other means of remotely browsing the server filessystem securely.

edy · « **Reply #25 on:** November 08, 2018, 02:23:06 pm »

Quote from: Ian.M on November 07, 2018, 04:00:51 pm

Edy is running the replace on the body.innerHTML of *EVERY* web page he visits using Chrome (with Tampermonkey extension enabled).

Ok, so removing the IP address entirely from the page does NOT work, the links to either <A HREF> or <IMG> are not able to get files relative to the main page itself, probably because everything is being generated "on-the-fly" by the hard-drive software. I will explain...

The images/videos/music are not actually getting directly referenced to the folder structure on the drive by the software. What happens is the software "sorts" all the content into various types of content and generates some proprietary hierarchy (although user customizable but not necessarily directly parallel to the folder structure) and even renames the files (not on the drive but in it's own "lookup table") to a proprietary name in some strange unknown scheme. You are able to browse BY DATE, BY RATING, BY ALBUM... and there are links to all of these on the "web-page" that the drive presents to the user.

That means that for whatever you decide to click on, the resulting page has been generated "on-the-fly" by the software and contains it's own mapping of files according to whatever sorting scheme you have decided to browse the files by. The only thing that works is turning on Tampermonkey to basically translate/replace all hard-coded internal LAN address links (in the format usually 198.162.x.x, the local LAN IP) to the outward internet-IP the drive is on.

Using Tampermonkey (activated *only* when I am browsing the drive and no other time) solves the problem with the older generation of drives that was doing this. I don't normally use Tampermonkey otherwise, it would be off and therefore shouldn't affect any other browsing (unless you think I should remove the Extension also, but when it is off I assume it is not using any CPU cycles).

SECURITY:

Yes, from a security issue this is a problem, it is actually a known problem with many media hard-drives. On top of the fact that external-browsing should be turned off if you don't plan on accessing the drive from outside your local LAN (usually 192.168.x.x), it poses a risk since it is easy to port-scan random IP's on the internet looking for open responses since certain drives will advertise themselves as existing. In addition, some drives are ALSO known to still respond to external connections even when the "external browsing" feature has been turned off or requires a password.

Newer iterations will map everything to LOCALHOST (127.0.0.1) and require a user inside the LAN to run some software on their machine (probably the software acts as an extra layer of security or simply does the appropriate IP translation or verification). The hard drive web page introduces some Javascript AFTER the page loads that generates the links, it is no longer hard-coded in the page. But when you hover over all the content, the links are all "127.0.0.1/whateverfolderstructure/image1.jpg", etc. That means Tampermonkey CANNOT simply do a lookup/replace of the 127.0.0.1 IP with the internet IP, since the web-page actually loaded has no references to the IP address at all (it must be done by Javascript after).

Nevertheless, you can still access your media from the internet by *manually* replacing the localhost IP with the internet IP of the drive. Content still loads, you just don't see a page full of thumbnails and you can't just easily click on things to browse, you have to do them one at a time.

In this case, if it is possible to "map" or reroute requests to 127.0.0.1 to the internet IP of the drive, the browser should actually fetch the content properly.

Bottom line.... The implementation of the hard-drive software is BAD and BUGGY and is a SECURITY MESS. Either it should work both externally and internally, if I want it to be on and working fine both externally and internally (without needing to do all this IP replacement stuff). However, if I turn off external access to the internet, it shouldn't even let me access the drive PERIOD from the internet. Unless they screwed up the entire implementation and really just obfuscating things for external access because they never intended external browsing (which really isn't stopping anything anyways because swapping IP's still works anyways, whether manually or automatic).

sokoloff · « **Reply #26 on:** November 08, 2018, 02:31:42 pm »

Quote from: edy on November 08, 2018, 02:23:06 pm

Ok, so removing the IP address entirely from the page does NOT work, the links to either <A HREF> or <IMG> are not able to get files relative to the main page itself, probably because everything is being generated "on-the-fly" by the hard-drive software. I will explain...

You might be at the point where the problem is solved for you and you aren't interested in spending more time on it. If so, that's cool (and totally understandable).

If you want to learn a little bit more and diagnose *why* that didn't work, I'm still very curious and would love to help you figure that out.

If (and only if) you're interested, could you post a snippet of HTML post-Tampermonkey that does work and another snippet that doesn't work?

dadh · « **Reply #27 on:** November 08, 2018, 03:10:38 pm »

edy,

Given the bad implementation done by the hard-drive manufacturer, may I suggest you do NOT allow direct access from the internet to this drive. If you must have it accessible from the outside world at a minimum consider putting a reverse proxy (NGINX or APACHE) between it and the internet.

edy · « **Reply #28 on:** November 08, 2018, 03:15:13 pm »

I will try it again, I think I made an error in the Tampermonkey script. I think it is because I need to remove the *entire* "http://192.168.x.x/image1.jpg" (not just the IP) and replace it with nothing. My previous script would have removed the IP and replace it with a "" (nothing), but then the resulting URL would end up being "http:///image1.jpg" (not "/image1.jpg") which would not work.

You are saying that "http://192.168.x.x/image1.jpg" should be the same as "/image1.jpg" as the browser should know the BASE-IP of the page it is linked on (for example, say 10.20.40.80) and therefore does not need to be explicitly hard-coded to work.

I will let you know if that works out, and then maybe you can help me resolve the next problem... Figuring out what to do with the Javascript-based version of pages that has NO IP explicitly written on the pages at all (so nothing for Tampermonkey to easily replace), yet links everything to localhost (127.0.0.1) which can easily be bypassed just by substituting 127.0.0.1 with 10.20.40.80 (as before) but manually.

[EDIT: YES It worked when I replaced "http://192.168.1.100/" with "/"... it was my fault because the previous Tampermonkey code had only replaced the 192.168.1.100 so it was trying "http:///"]

edy · « **Reply #29 on:** November 08, 2018, 03:25:41 pm »

Quote from: dadh on November 08, 2018, 03:10:38 pm

edy,

Given the bad implementation done by the hard-drive manufacturer, may I suggest you do NOT allow direct access from the internet to this drive. If you must have it accessible from the outside world at a minimum consider putting a reverse proxy (NGINX or APACHE) between it and the internet.

Yes I agree, this whole thing is a security nightmare and it would be easier to access the drive from inside the network and disconnect it from the outside entirely. For example, if I get into my local network via a VPN tunnel and then reach it from inside it should treat me as if I am a local user on the local LAN (I assume a VPN router should do the trick and let me branch on to the local intranet IP so that the branched remote network also appears as 192.168.x.x).

On the other hand, I am curious what is going on and will mess around with it a little more just to learn how badly the implementation really is, but not going to spend too much time with it.

cdev · « **Reply #30 on:** November 16, 2018, 08:46:54 pm »

I have a question for networking pros here, what in your opinion are the best value in cheap multi-NIC-containing Linux-friendly PC hardware suitable for flexible use in IP routing (as a soft-switch, firewall, etc.)

Not proprietary router hardware, generic PC hardware with at least two fast built in NICs?


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: IP routing in Linux (Read 3640 times)

Share me