You are not logged in.
I set up the network sharing by following https://wiki.archlinux.org/index.php/Internet_sharing
[i@one ~]$ ifconfig
enp3s10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::e2ab:3c37:20bf:691e prefixlen 64 scopeid 0x20<link>
ether 00:19:e0:0a:eb:d8 txqueuelen 1000 (Ethernet)
RX packets 474 bytes 28440 (27.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 119 bytes 19093 (18.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.31.131 netmask 255.255.255.0 broadcast 192.168.31.255
inet6 fe80::1c25:ce9d:2894:5789 prefixlen 64 scopeid 0x20<link>
ether 00:01:6c:50:84:39 txqueuelen 1000 (Ethernet)
RX packets 3897 bytes 463718 (452.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 839 bytes 115313 (112.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 50 bytes 4675 (4.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50 bytes 4675 (4.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[i@one ~]$ sudo ifconfig enp3s10 169.254.31.131 netmask 255.255.255.0 up
[i@one ~]$ ifconfig
enp3s10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.31.131 netmask 255.255.255.0 broadcast 169.254.31.255
ether 00:19:e0:0a:eb:d8 txqueuelen 1000 (Ethernet)
RX packets 497 bytes 29886 (29.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 123 bytes 19596 (19.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.31.131 netmask 255.255.255.0 broadcast 192.168.31.255
inet6 fe80::1c25:ce9d:2894:5789 prefixlen 64 scopeid 0x20<link>
ether 00:01:6c:50:84:39 txqueuelen 1000 (Ethernet)
RX packets 4110 bytes 484958 (473.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 888 bytes 120916 (118.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 52 bytes 4850 (4.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 52 bytes 4850 (4.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[i@one ~]$ iptables -t nat -A POSTROUTING -o ens33 -j MASQUERADE
[i@one ~]$ iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[i@one ~]$ iptables -A FORWARD -i enp3s10 -o ens33 -j ACCEPT
Then the client successfully opened the websites, being able to access the internet of the server.
Then I tried to use a proxy called sshuttle:
[i@one ~]$ iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 96 packets, 5667 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 26 packets, 1481 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
161 9800 MASQUERADE all -- any ens33 anywhere anywhere
[i@one ~]$ sshuttle -r i@$server_ip --dns 0/0 -D
[i@one ~]$ iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 300 packets, 17989 bytes)
pkts bytes target prot opt in out source destination
487 30642 sshuttle-12300 all -- any any anywhere anywhere
Chain INPUT (policy ACCEPT 241 packets, 14387 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2 packets, 172 bytes)
pkts bytes target prot opt in out source destination
33 2296 sshuttle-12300 all -- any any anywhere anywhere
Chain POSTROUTING (policy ACCEPT 2 packets, 126 bytes)
pkts bytes target prot opt in out source destination
61 3774 MASQUERADE all -- any ens33 anywhere anywhere
Chain sshuttle-12300 (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN tcp -- any any anywhere localhost
0 0 REDIRECT tcp -- any any anywhere anywhere TTL match TTL != 42 redir ports 12300
28 1884 REDIRECT udp -- any any anywhere _gateway udp dpt:domain TTL match TTL != 42 redir ports 12299
[i@one ~]$ curl icanhazip.com
IP_CHANGED
As you can see, what is does it to add chains in OUTPUT and PREROUTING. Then REDIRECT them to its own port.
And all my data from enp3s10 has been FORWARDed to ens33. So now the client should be able to access the network of the sshuttle.
But it didn't. When the client trys to access a website, It shows
Can not Access This Website
www.website.com Declined Our Request
...
ERR_CONNECTION_REFUSED
Why did the happen? How can I fix it?
Last edited by 1ndeed (2020-04-04 05:05:49)
Offline
=https://github.com/sshuttle/sshuttle]
Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.
The readme file also indicates this as meant to connect to a vpn network.
Maybe what you get is how sshuttle intends to work.
Are you sure sshuttle is what you need ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
=https://github.com/sshuttle/sshuttle]
Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.The readme file also indicates this as meant to connect to a vpn network.
Maybe what you get is how sshuttle intends to work.
Are you sure sshuttle is what you need ?
It is. Except that I want the client of the network sharing to have the VPN connection, not the server itself.
Now I know that as long as the network data is redirected to port 12300, the client is under VPN. I just need to know how to redirect the network connection of the client of the network sharing to that port.
Offline
Hello,
It is. Except that I want the client of the network sharing to have the VPN connection, not the server itself.
Now I know that as long as the network data is redirected to port 12300, the client is under VPN. I just need to know how to redirect the network connection of the client of the network sharing to that port.
TCP and DNS over UDP traffic (except the one really at destination to localhost) is redirected to sshuttle listening on 127.0.0.1:port in the PREROUTING chain. I'm not sure it is designed to route all traffic that doesn't come from the local machine in the default config.
Did you try using the --listen parameter and select you 192.168.31.xxx address as the listening interface?
Cuz it seems to me it is what you are looking for. It would be only listening for your client (if it is the only one connected to this interface) and it would redirect only your client traffic then.
EDIT: If it does'nt solve your issue, there is also a parameter to have more verbose outputs from sshuttle:
-v, --verbose
Print more information about the session. This option can be used more than once for increased verbosity. By default, sshuttle prints only error messages.
It could be useful to understand what sshuttle is doing. You could capture traffic too.
Last edited by Koatao (2020-04-02 14:20:23)
Offline
Hello,
1ndeed wrote:It is. Except that I want the client of the network sharing to have the VPN connection, not the server itself.
Now I know that as long as the network data is redirected to port 12300, the client is under VPN. I just need to know how to redirect the network connection of the client of the network sharing to that port.TCP and DNS over UDP traffic (except the one really at destination to localhost) is redirected to sshuttle listening on 127.0.0.1:port in the PREROUTING chain. I'm not sure it is designed to route all traffic that doesn't come from the local machine in the default config.
Did you try using the --listen parameter and select you 192.168.31.xxx address as the listening interface?
Cuz it seems to me it is what you are looking for. It would be only listening for your client (if it is the only one connected to this interface) and it would redirect only your client traffic then.
EDIT: If it does'nt solve your issue, there is also a parameter to have more verbose outputs from sshuttle:
-v, --verbose Print more information about the session. This option can be used more than once for increased verbosity. By default, sshuttle prints only error messages.
It could be useful to understand what sshuttle is doing. You could capture traffic too.
Thank you very very much!!! It worked!!!
By checking netstat, I found the sshuttle listens to 127.0.0.1 by default.
I did try the --listen parameter, but I only assigned it to 192.168.*.*, not 169.254.*.*
It took me weeks on this problem... Thank you!!
Last edited by 1ndeed (2020-04-03 06:58:03)
Offline