I started to use ngrok to create a tunnel to get http 80 access to some local files.
It was working great till tonight.
When I run ngrok http 80 I get the usual startup screen for about 30 seconds then a black screen comes up and i am unable to get my external link.
This will load then the terminal window goes blank
ngrok (Ctrl+C to quit)
Session Status connecting
Version 3.1.0
Latency -
Web Interface http://127.0.0.1:4040
Connections ttl opn rt1 rt5 p50 p90
0 0 0.00 0.00 0.00 0.00
# ngrok http 80 --log stdout
INFO[11-05|09:28:17] no configuration paths supplied
INFO[11-05|09:28:17] using configuration at default config path path=/root/.config/ngrok/ngrok.yml
INFO[11-05|09:28:17] open config file path=/root/.config/ngrok/ngrok.yml err=nil
t=2022-11-05T09:28:17-0400 lvl=info msg="starting web service" obj=web addr=127.0.0.1:4040
t=2022-11-05T09:28:22-0400 lvl=warn msg="failed to check for update" obj=updater err="Post \"https://update.equinox.io/check\": context deadline exceeded"
panic: send on closed channel
goroutine 48 [running]:
go.ngrok.com/lib/tlsx.CRLVerifyConfig.verifyIssuer.func1()
go.ngrok.com/lib/tlsx/crl.go:104 +0xf5
go.ngrok.com/lib/nsync.(*Group).Go.func1()
go.ngrok.com/lib/nsync/group.go:69 +0x44
created by go.ngrok.com/lib/nsync.(*Group).Go
go.ngrok.com/lib/nsync/group.go:68 +0x128
i did not make any changes to the ngrok config
I spoke with ngrok support and they verified that looks like my isp was blocking something.
They advised to edit the ngroc.yml file and to add
crl_noverify: true
To the the file.
After that the command "ngrok http 80" works as normal.
Related
I am trying to run this docker file https://gitlab.com/snippets/1713665
consoles
I have running iroha container as you can see in right console on 50051 port, but on running the above docker file for web GRPC then you can see in left console it is unable to make connection. as i have also tried with enabling and disabling the firewalls and also with opening the 50051 withudo ufw allow 50051 sudo ufw allow 50051 ...But in the end i have the same results
"Err: connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused". Reconnecting... system=system"
I have also posted this issue month ago but no once gave me any response, Thats why i am reposting with further elaboration
Try running the grpc web proxy, with the backend address as localhost, instead of whatever is default in the gitlab post.
ex. ./grpcwebproxy-v0.13.0-osx-x86_64 --backend_addr=localhost:50051 --run_tls_server=false
From the console logs, it looks like it is trying to connect to dev.localdomain:50051
From previous versions of the question, there is this: Browse website with ip address rather than localhost, which outlines pretty much what I've done so far...I've got the local IP working. Then I found ngrok, and apparently I don't need to connect via the IP.
What I am trying to do is expose my website running on localhost to the internet. I found a tool that will do this: ngrok.
Running the website in visual studio, the website starts up on localhost/port#. I run the command "ngrok http port#" in the command line. Everything seems to start up fine. I generate a couple of URLs, and the ngrok inspection url (localhost:4040) works.
The only problem is that when I go to the generated URLs, I get an HTTP error 400: bad request invalid hostname. This is a different error than when I run "ngrok http wrongport#", which is a host not found error...so I think something good is happening. I just can't tell what...
Is there a step I am missing in exposing my site to the internet via the tunneling service? If there is, I can't find it in the ngrok documentation.
Troubleshot this issue with ngrok. In the words of inconshrevable, some applications get angry when they see a different host header than expected.
Running the following command should fix the problem:
ngrok http [port] --host-header="localhost:[port]"
Depending on the version, you may also want to try:
ngrok http [port] --host-header="localhost:[port]"
Following command will fix the issue
ngrok http -host-header=localhost 8080
This didn't work for me.
you could do the following:
For IIS Express
In VS 2015:
Go to the .vs\config\applicationhost.config folder in your project
In VS 2013 and earlier:
Go to %USERPROFILE%\My Documents\IISExpress\config\applicationhost.config
Find the binding that says:
<binding protocol="http" bindingInformation="*:5219:localhost" />
For me it was a project running on port 5219
change it to
<binding protocol="http" bindingInformation="*:5219:" />
IIS Express will now accept all incoming connections on that port.
Disadvantage: you need to run IIS Express as admin.
or you could rewrite the host header in Ngrok:
ngrok.exe http -host-header=rewrite localhost:5219
For https this works:
ngrok http https://localhost:<PORT> --host-header="localhost:<PORT>"
UPDATED COMMAND FOR LATEST VERSION
Tested with: (Windows) (ngrok v3.0.5)
Use -- instead of -
ngrok http --host-header=localhost 8080
The simplest thing for me was using iisexpress-proxy + ngrok.
First I install iisexpress-proxy globally with npm
npm install -g iisexpress-proxy
Then I proxy my localhost with it. Say for instance my site is running on 3003.
iisexpress-proxy 3003 to 12345 where 12345 is the new http port I want to proxy to.
Then I can run ngrok on it.
./ngrok.exe http 12345
It just works! 😃
But I think it works only with http. Right now I don't use https to test, but even if it works, usually it's a lot of work as always.
For https this works:
ngrok http https://localhost:<PORT> --host-header="localhost:<PORT>"
Try with different locations from the Global infrastructure > Locations
ngrok http -region eu 8080
You can make a request and view any traffic passing through your tunnel using the ngrok traffic inspector at http://localhost:4040.
OR in command line
ngrok http -region eu 8080 --log=stdout
If one region fails then try with another.
ngrok runs tunnel servers in datacenters around the world. The location of the datacenter within a given region may change without notice (e.g. the European servers may move from Frankfurt to London).
us - United States (Ohio)
eu - Europe (Frankfurt)
ap - Asia/Pacific (Singapore)
au - Australia (Sydney)
sa - South America (Sao Paulo)
jp - Japan (Tokyo)
in - India (Mumbai)
First open ngrok configuration YAML file, run from terminal:
ngrok config edit
Example of yaml for localhost setup (client & server):
version: "2"
authtoken: {YOUR_AUTH_TOKEN_FROM_NGROK_WEBSITE}
tunnels:
client:
addr: 3000
proto: http
host_header: localhost
server:
addr: 4000
proto: http
host_header: localhost
Save the config file based on your client and server ports and run the following command:
ngrok start --all
This will make ngrok open a tunnel for all the configurations declared in the yaml file
Had IIS Express .net web API, had installed NGROK in docker (windows as a host)
Had "Bad Request" error, the next command worked for me:
docker run -it -e NGROK_AUTHTOKEN=<token> ngrok/ngrok --host-header=localhost:21852 http host.docker.internal:21852
As I understood later, --host-header needed because IIS Express refuses all requests from outside (must be "localhost:port
"), host.docker.internal I've used instead of localhost, because NGROK was running inside docker, while IIS Express was running on a windows host.
I had the same issue and used the following solution:
Make sure your application binding in your IIS is set to All Unassigned IP address
Run ngrok HTTP 127.0.0.1:173 --region=eu --hostname=yourcustomdomain.eu.ngrok.io
That's it. Works perfectly. This solution is also for paid pro accounts
Steps.
Run command on your console from ngrok.exe directory . ngrok http
port i.e ngrok http 80 https://www.screencast.com/t/oyuEPlR6Z Set
Ngrok url to your app .
It will create a tunnel to your application.
Thanks .
Okay, for some reason this morning, I am unable to connect to the Wordpress SVN repository and execute basic svn commands (e.g. checkout, update).
Here's an example of what's happening:
$ svn co http://svn.automattic.com/wordpress/tags/3.3/
# Adds a bunch of files...
svn: warning: Error handling externals definition for '3.3/wp-content/plugins/akismet':
svn: warning: PROPFIND of '/!svn/vcc/default': could not connect to server (http://plugins.svn.wordpress.org)
Checked out revision 19597.
$ cd 3.3
$ svn update
svn: OPTIONS of 'http://svn.automattic.com/wordpress/tags/3.3': could not connect to server (http://svn.automattic.com)
Yet, when I perform these same commands on a development server I have (a Linode VPS) it works fine.
I've google around about this quite a bit, and found pages like these:
http://vsingleton.blogspot.com/2008/04/svn-propfind-request-failed-on.html
http://wordpress.org/support/topic/cant-connect-to-the-pluginssvnwordpress-server
A lot of these articles say something to effect of, it's your proxy server. Well, I'm not behind a proxy server:
http://whatismyipaddress.com/proxy-check
Proxy server not detected.
IP 24.21.xxxx.xxx
rDNS FALSE
WIMIA Test FALSE
TOR Test FALSE
Loc Test FALSE
Header Test FALSE
DNSBL Test FALSE
Just a regular old Comcast home internet connection.
Also, I can browse the wordpress SVN repository just fine via my browser.
Anyhow, I'm sort of at a dead end here, and I guess I'm wondering if anyone has any suggestions as to how to either solve the issue or work around it? I tried setting up an forward proxy server on the Apache installation I have running on that dev server and then updating my ~/.subversion/server file, but that didn't work or I configured something wrong.
Well, if anyone has any brilliant ideas or explanations, I'd love to hear them...
Update
I had a co-worker test this out on his home connection -- he uses Comcast as well. He got the same error as I did. So it appears to be some Comcast-related issue specific to the Wordpress svn repository. I was able to checkout other public repositories via http (e.g. from Google Code) just fine.
I ran a series of tests and I could not find any hidden proxies or cache servers between me and the repository.
I did run traceroute per Lazy Badgers suggestion, and here's what I got:
$ traceroute svn.automattic.com
traceroute to svn.automattic.com (72.233.56.196), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.659 ms 0.292 ms 0.185 ms
2 * * *
3 te-5-7-ur01.hollywood.or.bverton.comcast.net (68.85.150.225) 8.792 ms 8.309 ms 9.054 ms
4 xe-3-1-0-0-ar03.beaverton.or.bverton.comcast.net (68.87.216.33) 14.354 ms 24.859 ms 8.753 ms
5 pos-3-8-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.117) 21.869 ms
pos-3-1-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.113) 21.791 ms
pos-3-0-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.95.109) 22.983 ms
6 pos-0-7-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.85.46) 23.682 ms 25.043 ms 24.675 ms
7 xe-10-3-0.edge1.sanjose1.level3.net (4.71.118.5) 61.048 ms 23.986 ms 24.221 ms
8 vlan80.csw3.sanjose1.level3.net (4.69.152.190) 25.257 ms 25.648 ms
vlan90.csw4.sanjose1.level3.net (4.69.152.254) 24.310 ms
9 ae-82-82.ebr2.sanjose1.level3.net (4.69.153.25) 24.870 ms
ae-92-92.ebr2.sanjose1.level3.net (4.69.153.29) 25.371 ms
ae-91-91.ebr1.sanjose1.level3.net (4.69.153.13) 24.744 ms
10 ae-34-34.ebr4.sanjose1.level3.net (4.69.153.34) 36.011 ms 25.975 ms 36.053 ms
11 ae-5-5.ebr2.sanjose5.level3.net (4.69.148.141) 25.236 ms 25.307 ms 25.305 ms
12 ae-6-6.ebr2.losangeles1.level3.net (4.69.148.201) 31.299 ms 34.076 ms 33.401 ms
13 ae-3-3.ebr3.dallas1.level3.net (4.69.132.78) 59.012 ms 58.604 ms 60.576 ms
14 ae-83-83.csw3.dallas1.level3.net (4.69.151.157) 59.708 ms 65.724 ms
ae-73-73.csw2.dallas1.level3.net (4.69.151.145) 60.383 ms
15 ae-42-90.car2.dallas1.level3.net (4.69.145.196) 60.636 ms
ae-22-70.car2.dallas1.level3.net (4.69.145.68) 59.572 ms 59.758 ms
16 databank-ho.car2.dallas1.level3.net (4.71.170.2) 58.711 ms 59.994 ms 60.561 ms
I don't know if that's unusual or anything. I tried the same on my dev sever and the result looked mostly similar, save for line 2 with the * * *.
I successfully configured a forward proxy on my dev server so I've hacked together a solution for now, but I still don't quite understand what is afoot...
Update 2
In response to a question, here's how I configured things to use my dev server as a proxy for the time being.
First, I configured apache on my dev server to run as a proxy. Make sure these directives are somewhere in your Apache configuration file chain (httpd.conf, vhosts.d directory, etc.):
Listen 8080
<VirtualHost _default_:8080>
ProxyRequests On
ProxyVia On
ProxyPreserveHost On
<Proxy *>
Order deny,allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Proxy>
</VirtualHost>
This assumes you have a working Apache set up on a development server somewhere (I would definitely not use this on a production server) with mod_proxy installed. Port 8080 is arbitrary. Basically for an unmatched virtual host (i.e. any request that doesn't match your other hosts you have set up) it will turn proxy on and proxy the request through. Change "xxx.xxx.xxx.xxx" to your own IP address.
Now you have to change the server setting in your subversion config file.
In this file:
~/.subversion/servers
Find this section:
[global]
# http-proxy-exceptions = *.exception.com, www.internal-site.org
# http-proxy-host = proxy1.some-domain-name.com
# http-proxy-port = 80
# http-proxy-username = defaultusername
# http-proxy-password = defaultpassword
# http-compression = no
# http-auth-types = basic;digest;negotiate
# No http-timeout, so just use the builtin default.
# No neon-debug-mask, so neon debugging is disabled.
# ssl-authority-files = /path/to/CAcert.pem;/path/to/CAcert2.pem
Uncomment out http-proxy-host and http-proxy-port. For host use a spare domain name you have mapped to your development server or presumably you could just use your server IP. Then set the port to 8080 or whatever you used.
This should route all subversion http requests via your proxy you just set up. It doesn't affect svn or svn+ssh requests.
This was my quick hack, your mileage may vary, this might be totally insecure or broken, etc.
I have Comcast business both at my home office & the corporate office.
BOTH FAIL TO CONNECT TO THE REPO ON COMCAST.
However, I never have a problem if I go over the Windstream T1 or connect via our live server on multiple backbones.
Comcast appears to be "traffic shaping" and/or monitoring business class traffic and breaking the Internet!
Nice job Comcast!
If you don't have an alternate connection they you may need to use a proxy service and then send Comcast a nasty email about their network filtering.
I have box A and it has a consumer on it that listens on a Rabbit MQ server
I have box B that will publish a message to the listener
So as long as all of this in on box A and I start Rabbit MQ server w/ defaults it works fine.
The defaults are host=127.0.0.1 on port 5672, but
when I telnet box.a.ip.addy 5672 from box B I get:
Trying box.a.ip.addy...
telnet: connect to address box.a.ip.addy: No route to host
telnet: Unable to connect to remote host: No route to host
telnet on port 22 is fine, I can ssh into Box A from Box B
So I assume I need to change the ip that the RabbitMQ server uses
I found this: http://www.rabbitmq.com/configure.html and I now have a config file in the location the documentation said to use, with the name rabbitmq.config and it contains:
[
{rabbit, [{tcp_listeners, {"box.a.ip.addy", 5672}}]}
].
So I stopped the server, and started RabbitMQ server again. It failed. Here are the errors from the error logs. It's a little over my head. (in fact most of this is)
=ERROR REPORT==== 23-Aug-2011::14:49:36 ===
FAILED
Reason: {{case_clause,{{"box.a.ip.addy",5672}}},
[{rabbit_networking,'-boot_tcp/0-lc$^0/1-0-',1},
{rabbit_networking,boot_tcp,0},
{rabbit_networking,boot,0},
{rabbit,'-run_boot_step/1-lc$^1/1-1-',1},
{rabbit,run_boot_step,1},
{rabbit,'-start/2-lc$^0/1-0-',1},
{rabbit,start,2},
{application_master,start_it_old,4}]}
=INFO REPORT==== 23-Aug-2011::14:49:37 ===
application: rabbit
exited: {bad_return,{{rabbit,start,[normal,[]]},
{'EXIT',{rabbit,failure_during_boot}}}}
type: permanent
and here is some more from the start up log:
Erlang has closed
Error: {node_start_failed,normal}
^M
Crash dump was written to: erl_crash.dump^M
Kernel pid terminated (application_controller) ({application_start_failure,rabbit,{bad_return,{{rabbit,start,[normal,[]]},{'EXIT',{rabbit,failure_during_boot}}}}})^M
Please help
did you try adding?
RABBITMQ_NODE_IP_ADDRESS=box.a.ip.addy
to the /etc/rabbitmq/rabbitmq.conf file?
Per http://www.rabbitmq.com/configure.html#customise-general-unix-environment
Also per this documentation it states that the default is to bind to all interfaces. Perhaps there is a configuration setting or environment variable already set in your system to restrict the server to localhost overriding anything else you do.
UPDATE: After reading again I realize that the telnet should have returned "Connection Refused" not "No route to host." I would also check to see if you are having a firewall related issue.
You need to open up the tcp port on your firewall
Using Linux, Find the iptables config file:
eric#dev ~$ find / -name "iptables" 2>/dev/null
/etc/sysconfig/iptables
Edit the file:
sudo vi /etc/sysconfig/iptables
Fix the file by adding a port:
# Generated by iptables-save v1.4.7 on Thu Jan 16 16:43:13 2014
*filter
-A INPUT -p tcp -m tcp --dport 15672 -j ACCEPT
COMMIT
I've got a remote server on eapps.com that I'm using as my "production" server. I have my own computer at home that I'm using as my "development" server. I'm trying to use JNDI over HTTP to do some batch processing. The following works at home, but not on the eapps machine.
I'm connecting to some EJBs (stateless session), and have my jndi.properties set to this:
(this is for the eapps machine)
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.provider.url=http://my.prodhost.com:8080/invoker/JNDIFactory
java.naming.factory.url.pkgs=org.jboss.naming.client:org.jnp.interfaces
# timeout is in milliseconds
jnp.timeout=15000
jnp.sotimeout=15000
jnp.maxRetries=3
(this is for my machine at home)
java.naming.factory.initial=org.jboss.naming.HttpNamingContextFactory
java.naming.provider.url=http://localhost:8080/invoker/JNDIFactory
java.naming.factory.url.pkgs=org.jnp.interfaces
java.naming.factory.url.pkgs=org.jboss.naming.client
# timeout is in milliseconds
jnp.timeout=15000
jnp.sotimeout=15000
jnp.maxRetries=3
As I said, it works at home, but when I try it remotely, I get:
Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://my.prodhost.com:4446//?dataType=invocation&enableTcpNoDelay=true&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&socketTimeout=600000&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller]
...
Caused by: java.net.ConnectException: Connection timed out: connect
Am I doing something wrong here, or is it possibly a firewall issue? To the best of my knowledge, port 4446 is not blocked.
Are the differences in the jndi.properties intentional (at the java.naming.factory.url.pkgs property level)?
Also, can you run a netstat -a | grep 4446 on both machines and update the question with the output?
Update: If the netstat command didn't return anything for port 4446 (JBoss was running, right?), then the JBoss Remoting Connector for the UnifiedInvoker service is very likely not listening on your eApps host, hence the connection timeout. Maybe this service has been disabled by eApps, you should contact the support and discuss this with them.
Just in case, a sample Connector configuration can be found in the jboss-service.xml under the server node's conf directory. Maybe compare the remote one (if you have access to it) with your local file to confirm this (but if it's disable, there must be a reason, discuss it with the support).
And by the way, this is what I get when I run the netstat command with JBoss 4.2.3.GA started on my GNU/Linux machine (default configuration):
$ netstat -a | grep 4446
tcp 0 0 localhost:4446 *:* LISTEN