![]() ![]() ![]() Funnily enough, even with this, the websocket connection could not be established. ![]() Now, the packet should truly appear to be originating from localhost. So I tried using iptables to DNAT all requests on ports 80 on the external ip to the internal ipġ sudo iptables -t nat -A INPUT -d 127.0.0.1/32 -m conntrack -ctstate DNAT -j SNAT -to-source 127.0.0.1ĭoing both DNAT and SNAT on the packets this way impacts throughput, but this isn’t an issue for just the couple of connections I expected to have. In the latter case, access to ws://127.0.0.1:9330 works well. The reason is that upon page load, some javascript try to access ws://192.168.3.1:9330 in the former case, but the websocket connection gets closed immediately. However, accessing it via 127.0.0.1:8000 does work. As mentioned above, firing up a webserver on port 8000 and accessing it via 192.168.3.1:8000 does not work. The LAN facing static ip address of the router is 192.168.3.1. Well, we should be able to work around this with some iptables magic, right? Iptables magic However, after some testing, it became clear that while the service binds to port 9330 on all interfaces, it only responds to requests from localhost i.e. On that computer, lsof -i :9330 indeed shows that Speedify is listening on port 9330. The Javascript console shows that the page is unable to access a websocket on port 9330 on the computer running Speedify. An interface does come up, but all it shows is a blue button, clicking which achieves nothing. Bingo! Unfortunately, typing eth_ip_addr:8000 in a web browser from another computer on the network does not work. Typing localhost:8000 in a web browser on the same machine shows the Speedify GUI. The above command starts a webserver listening on all interfaces at port 8000. So I went to that directory and started a local webserver ![]() However, in the /usr/share/speedifyui/files folder, I noticed files that looked suspiciously like those that would be served by a web server. Unlike on the Macbook, there was no process listening on localhost:9331 when the full Speedify client is started on Linux. Speedify’s GUI in a browser on Linuxīy chance, I was running the full Speedify client on a computer with a Linux Desktop. Unfortunately, it is not that straightforward. So maybe, if Speedify CLI is running on a device, the GUI can be accessed by accessing device_ip_addr:9331 in a browser from another computer? Seemed worth a shot. So it seems that the Speedify GUI is essentially a locally served web page and the Speedify client (at least for Mac) is just a thin application window around the web page. Curious, I typed that into a web browser and hey presto! saw Speedify’s GUI in the browser. On starting the client, Activity Monitor showed a process listening on localhost:9331. It all started when I was running the Speedify client on my MacbookPro. This endeavor wouldn’t have succeeded without some serendipity and dogged tinkering. or is it? I figured out a way to access Speedify’s UI while running the CLI client on a headless server with no GUI desktop installed □ Understanding how Speedify’s GUI works The lack of a graphical interface means that Speedify’s nice and useful UI is not available. Speedify’s command line client executes on a Linux router that runs Ubuntu Server 20.04 without a graphical interface. , I described using a service named Speedify to simultaneously utilize two different Internet connections. The last section of this post also describes an alternative solutionĬontributed by a reader of this blog. , or read through the background and tinkering that preceded the actual solution. You can jump straight to the actual solution The pattern: How to remotely access a service that is bound to localhost and refuses to respond to requests not originating from localhost? The instance: If using Speedify CLI on a linux-based router with no GUI stack, how to nevertheless view the Speedify GUI in a web browser, from another device on the same network? This post documents some non-conventional hacks needed to get a working solution. ![]()
0 Comments
Leave a Reply. |