How to use the tcpip stack in gvisor to implement tun2socks?
gvisor.dev/gvisor/pkg/tcpip/stack (https://github.com/google/netstack)
https://github.com/xjasonlyu/tun2socks is a tun2socks implementation built on top of gVisor's netstack which may serve as a good reference, or directly meet your needs.
Related
The Valhalla maps server docs assume that the server is always running on "http://[hostname]:8002"
(see https://github.com/valhalla/valhalla)
How can the server be configured to listen via SSL/https instead?
Is there any detailed documentation on how to do this?
Thnx.
To answer my own question:
After much reading & research I came to the conclusion that a practical way to achieve this is simply to hide the Valhalla port (port 8002) behind my Linux firewall and to expose port 443 (SSL) instead and have Nginx running on that port. Nginx then port-forwards the Valhalla request obj to the internal port 8002 and proxies the response back to the caller for the return journey on the encrypted channel.
Setting up Nginx to achieve this is fairly straightforward and the procedure is documented on many websites.
I was looking for an answer on my question on google and also here, but a didn't find a proper answer.
So here is the context:
I have a software running on some server (without firewall) in one subnet.
There is another software running on some PC in a different subnet.
Both subnets are connected to a gateway server. All computers are running CentOS or RHEL.
On the gateway server, there is a firewall, preventing multicast traffic from leaving the one subnet and allow clients from outside to connect to computers inside this subnet. Therefore xinetd is used. The computer from outside needs to send a packet to a specific port, the computer on the inside answers to another specific port depending on the sender. So there is no need for the gateway to keep track of sender-receiver relations. It just needs to forward UDP on specific ports to specific computers from one subnet to another.
So I added one service in /etc/services (for one direction):
udp-gateway 6000/udp
And created the according configuration file in /etc/xinetd.d/gateway like:
service udp-gateway
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
}
Now the problem is, that the server doesn't open an UDP-port to listen on ('netstat -nulp' says). When I change the protocol to TCP and the socket_type to stream, it works. But I need this for UDP.
Is it possible that this is not possible for UDP? Or is netstat just not showing the ports? Or is my xinetd-configuration missing something?
Thanks in advance, every hint is appreciated.
Benny
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
from the man page of xinetd:
redirect
Allows a tcp service to be redirected to another host.
This means usage of redirect for udp is not possible. And I don't see any other way to do this with xinetd.
I am looking for a program to reroute windows domain resolution lookup through a socks proxy capable with many internet browsers and internet proxies.
So far in Control Panel, Local Area Connection 1, TCP/IP Properties, I use the following DNS server addresses, preferred DNS Server, I put 127.0.0.1 and use the default in-built port request 53.
I am reading that it is possible to forward this. I can not find a program to forward it through socks 4/5. I think this is possible because Socks supports UDP.
Has anyone come up with the answer to a solution about a UDP-to-socks forwarding program capable and adapted for socks and windows DNS.
It's really quite easy to configure.
You could write your own server and set the server to listen to incoming calls to port 53 or use this program
http://dns2socks.sourceforge.net
here my sample configuration for a socks server running on 1050 and TCP / IP settings on 127.0.0.1
DNS2SOCKS.exe /la:socks.log 127.0.0.1:1050 8.8.8.8:53 127.0.0.1:53
For such a program you can have a look at dnsadblock. Their free daemon/cli app opens up a proxy server that can be configured to use a proxy/socks to communicate with the upstream server. It works since the remote endpoint listens on https which makes DOH (dns over https) possible. Config options/install instructions: https://knowledgebase.dnsadblock.com/how-to-install-and-configure-our-software/
In the redis.conf the normal setting is
bind 127.0.0.1
I want redis to listen to another ip too (say my local development address)
I tried
bind 127.0.0.1, 123.33.xx.xx
but this does not work. I cannot find any relevant in the document or by googling. Hope someone can help.
Binding to multiple IPs is indeed possible since Redis 2.8. Just separate each IP by whitespace (not commas).
bind 127.0.0.1 123.33.xx.xx
Source: Official default config
This answer is not outdated and will work for both older and newer versions
The problem in understanding is that Redis binding doesn't show the client machine's address, but shows the interface through which connection should be established. In your example, if your local development (client) address is 123.33.xx.xx, it doesn't mean that you have to put exactly the same address as a binding, otherwise Redis service will not start.
So if ifconfig on your Redis server machine shows that you have some network interface similar to this:
eth0 Link encap:Ethernet HWaddr 00:0c:...
inet addr:192.168.1.110 Bcast:192.168.1.255 Mask:255.255.255.0
you can put the interface's address 192.168.1.110 as a binding and every request to Redis, which pass through this interface, should succeed.
Since:
--[ Redis 2.8 Release Candidate 1 (2.7.101) ] Release date: 18 Jul 2013
you can:
[NEW] Ability to bind multiple IP addresses.
Cheers!!
Edit: it seems that the correct way is, still, only one line and one or more IPs separated by space
This way:
bind 127.0.0.1 10.150.220.121
EDIT: This is an outdated answer. Please check newer answers for solution.
You cannot set redis to listen on specific multiple interfaces. If multiple interfaces are required just remove the bind line.
As #taro pointed out use firewall to restrict access.
I tried finding that answer too, as it stands, it's not possible to do this, I found this while searching for the answer on multiple (but not all interfaces). This is what turned up http://code.google.com/p/redis/issues/detail?id=497 stating it will not be supported by redis itself.
In conjunction with haproxy that makes it impossible to put it in front of redis in one go. You need to use a different port, or the other or choose to bind on 1 IP.
The only way this worked for me, was by adding separate lines:
bind 111.222.33.44
bind 127.0.0.1 ::1
bind 127.0.0.1 192.168.152.2
Note, I have to put the 127.0.0.1 first otherwise the 192.x will not be bound at system boot. However another systemctl restart redis will suffice -- might be a bug? (Debian 10 and Redis 5.0.3)
For macOS Homebrew installation, make sure you are editing /usr/local/etc/redis.conf instead of the template file: /usr/local/Cellar/redis/6.2.6/.bottle/etc/redis.conf
My question may be a little confusing, but anyway. My school is going to open up WiFi DMZ on separate IP for students, but they said port 80 will be the only port open.
What do I want? Well I want to tunnel my traffic thru my home server, which is running Apache2 on 80 and SSH on 21. It's just a regular setup. As it is a production machine and I want clients to be able to connect on port 80, but I want to connect to port 80 to make a tunnel. The question is: How to do that?
The possible sollution: Abandon possibility of connecting to websites running on the server from the school IP and use IPTABLES. If source ip == $school_ip && port == 80: Redirect to port 21. Done. But I think there must another, elegant sollution... Isn't it possible to actually use the HTTP transfer for SSH transit? I mean create a host named for example ssh.mydomain.tld and use some apache module to do a server-side redirection to port 21 but only on that particular hostname? What can I do?
Box is running Debian GNU/Linux
Thanks for any help...
Off topic: They think they will block any sort of illegal operation. In fact HTTP is probably the second most-vulnerable protocol after BitTorrent. Why don't lock it down too? It'll be absolutely safe if there's no open ports, wouldn't it? I don't personally think blocking ports for POP, IMAP, Jabber, etc is any good. I think they'll probably seriously piss someone off if they even can't open mail teacher sent them. Oh, there's a webmail? No no no! SSL/TLS goes on port 443, remember? I don't think blocking all the traffic will be any good. IMO they should block unencrypted BitTorrent and apply low-priority QoS for unclassified transfers.
You could try the instructions found here:
http://dag.wieers.com/howto/ssh-http-tunneling/
proxytunnel is available in the stable repo:
http://packages.debian.org/search?keywords=proxytunnel&searchon=names&suite=stable§ion=all
A simple and working solution is sslh.
It is exactly the tool to solve that problem.
BTW ssh is usually set on port 22.