I'm trying to determine the mapping behaviour of a NAT using two STUN servers. I need two stun servers with the same IP but different port.
I was wondering if it's possible to set up two coturn stun servers on the same host.
Assuming your host as two or more valid IP addresses. In the examples below, let's assume the host has two public IP addresses: 1.2.3.4 and 1.2.3.5.
stuntman has this option to bind to multiple IP addresses if offered by the same host.
stunserver --mode full --primaryinterface 1.2.3.4 --altinterface 1.2.3.5
And if running in a NAT'd environment with port forwarding (such as AWS), you can specify the IP mappings such that the CHANGED_ADDRESS or (OTHER_ADDRESS) will be correct when it responds to STUN binding requests. Example:
stunserver --mode full --primaryinterface 10.0.0.4 --altinterface 10.0.0.5 --primaryadvertised 1.2.3.4 --altadvertised 1.2.3.5
Where 10.0.0.4 and 10.0.0.5 are the private LAN ip addresses of the host.
coturn appears to have the same option with the -L and -X options
turnserver -L 1.2.3.4 -L 1.2.3.5
With the -X option used to specify the advertised address in a NAT scenario.
Related
I'm trying to run an rsync through a bastion host onto an SSH server that listens on a non-standard port, like this:
Source Host -> Bastion Host -> Destination Host (sshd on non-standard port)
I can get onto the destination host via the Bastion box using this:
ssh -o ProxyCommand="ssh -W %h:%p admin#bastion-host" user#destination-host
But this gets me onto the "default" SSH server, running on port 22, and not the one I want to get to, which, for sake of argument, is running on port 12345.
If I want to rsync using the non-standard port, the examples I can find, like this for example:
https://www.tecmint.com/sync-files-using-rsync-with-non-standard-ssh-port/
Indicate I should use -p, but that wouldn't work since I need port 22 all the way through the tunnel until the end.
How can I rsync to/from this destination server on port 12345, via a tunnel through the bastion server on the standard port 22?
Source Host (22) -> Bastion Host (22) -> Destination Host (12345)
Ah, I think I figured it out. My destination server was only allowing port 22 from the bastion host, and not the non-standard port.
My Redis instance is running at 192.168.1.101.
Redis version is 4.0.1
I want to to be able to connect this Redis instance from 192.168.1.103, but I can't.
I type redis-cli -h 192.168.1.101 -p 6379 -a myredisPasswordisHere while I'm at 192.168.1.103
It returns
Could not connect to Redis at 192.168.1.101:6379: Connection refused
Could not connect to Redis at 192.168.1.101:6379: Connection refused
Here's the related part of the Redis.conf, it's located in /usr/local/etc/redis.conf. I've installed it via Homebrew.
TL;DR
protected-mode yes
bind 192.168.1.100 192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104
requirepass myredisPasswordisHere
What's wrong here?
For the redis service to be available for other remote hosts to query it, You need to bind it publicly to serve using bind 0.0.0.0
As the other comments from #Itamar and #Mark clearly mention, bind isn't the list of IP addresses that can connect but rather the interface on the local machine. Once the service is publicly available and running with 0.0.0.0 for your requirement of only allowing specific hosts, you need some kind of a firewall with a whitelist of IP addresses that can access this host which you can achieve with iptables.
I use this for remote port forwarding over SSH tunnel:
ssh root#X.X.X.X -R 443:127.0.0.1:443
this binds to 0.0.0.0:443 and forwards to 127.0.0.1:443 .
The remote server has multiple IPs. Is it possible to specify the IP I want to bind to, for instance 10.10.10.1:443, instead of binding to all interfaces?
iptables is not available on the remote server.
I managed to solve it.
On the remote server I set in sshd_config:
GatewayPorts clientspecified
Then I changed the arguments on the client like this:
ssh root#X.X.X.X -R 10.10.10.1:443:127.0.0.1:443
Now it works as expected, SSH binds to port 443 on interface 10.10.10.1 and forwards all traffic over the tunnel to localhost:443 .
I can now forward one port 8080 to the remote port 80 by ssh -L 8080:localhost:80 user#host.com, Is it possible to do multiple port forwarding with one ssh connection?
Yes, use -L option for each port to be forwarded.
Example:
ssh -L 8080:localhost:80 -L 7070:localhost:70 user#host.com
That is called dynamic port forwarding and if both the SSH server and SSH client support this, you configure your clients to use the SSH client as a SOCKS proxy and the SSH does the rest. In this case one "SSH connection" (in fact SSH connection carries multiple independent channels "inside") is used to connect to multiple destinations.
I have an Apache webserver running on a local machine through reverse ssh tunnel, i.e.:
ssh -R *:80:local_machine:8080 username#gateway_machine
In other words, all traffic from port 80 on gateway_machine
is sent to port 8080 on local_machine.
For monitoring purposes, I wish to know IP addresses of the remote clients
connected to gateway_machine. However my local Apache server sees
all traffic coming from the IP address of gateway_machine.
My question: Is there any way to setup ssh server running on gateway_machine such that
it sends all traffic to local_machine with actual remote IP addresses ?
The SSH protocol uses a channel type called "direct-tcpip" for forwarding a TCP connection. The protocol message for opening one of these channels includes the address and port of the client whose connection is being forwarded. So the information that you want is available to the ssh client (which in your case is opening the connection to the target of the forward).
The OpenSSH ssh client logs the originator address and port in a debug level message, so you can see it if you run ssh with the -v option:
$ ssh -v -R 2000:localhost:1000 localhost
...
debug1: client_request_forwarded_tcpip: listen localhost port 2000, originator ::1 port 51101
Here the originator address was ::1 (IPv6 localhost) and port 51101. The ssh utility doesn't do anything else with the information.
So, depending on your needs, you have three approaches to collect this information:
Invoke the ssh process which creates these forwards with the -v option, and arrange to collect and parse the relevant debug information.
Make source code changes to ssh to make it do what you want it to do with the information.
Write your own ssh client which does what you want. SSH client libraries are available for most modern programming languages.