Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom fails to connect to Shadowsocks #131

Open
NB-2022 opened this issue Feb 2, 2022 · 3 comments
Open

Custom fails to connect to Shadowsocks #131

NB-2022 opened this issue Feb 2, 2022 · 3 comments

Comments

@NB-2022
Copy link

NB-2022 commented Feb 2, 2022

Hello,

I have Shadowsocks configured to run a socks5 proxy on port 1080 (127.0.0.1:1080). When directly using the .ovpn file to connect with the OpenVPN application (Linux) it works correctly (socks-proxy and route set).

When I try to use the same configuration for vopono, it fails to connect.

"Attempting to establish TCP connection with [AF_INET]127.0.0.1:1080 [nonblock]\n1643794211.874470 1000021 TCP: connect to [AF_INET]127.0.0.1:1080 failed: Connection refused\n1643794211.874514 1 SIGUSR1[connection failed(soft),init_instance] received, process restarting\n1643794211.874526 21000003"

@jamesmcm
Copy link
Owner

jamesmcm commented Feb 3, 2022

Thanks, I replicated with Mullvad (and I also noticed they changed their Shadowsocks credentials too).

The interesting thing is that after correcting the credentials, it does work for Mullvad built-in, but not when treated as a custom config file.

And yet the logs look identical wrt. the firewall rules, etc.

 2022-02-03T21:35:53.527Z DEBUG vopono::netns             > ip netns exec vopono_mv_albania ip addr add 127.0.0.1/8 dev lo
 2022-02-03T21:35:53.530Z DEBUG vopono::netns             > ip netns exec vopono_mv_albania ip link set lo up
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
connected  full          enabled  enabled  enabled  enabled
 2022-02-03T21:35:53.543Z DEBUG vopono::veth_pair         > Detected NetworkManager running
 2022-02-03T21:35:53.543Z DEBUG vopono::veth_pair         > NetworkManager detected, adding mv_albania_d to unmanaged devices
 2022-02-03T21:35:53.543Z DEBUG vopono::veth_pair         > Appending to existing NetworkManager config file: /etc/NetworkManager/conf.d/unmanaged.conf
 2022-02-03T21:35:53.543Z DEBUG vopono::util              > nmcli connection reload
not running
 2022-02-03T21:35:53.668Z DEBUG vopono::veth_pair         > firewalld not detected running
 2022-02-03T21:35:53.668Z DEBUG vopono::util              > ip link add mv_albania_d type veth peer name mv_albania_s
 2022-02-03T21:35:53.670Z DEBUG vopono::util              > ip link set mv_albania_d up
 2022-02-03T21:35:53.672Z DEBUG vopono::util              > ip link set mv_albania_s netns vopono_mv_albania up
 2022-02-03T21:35:53.685Z DEBUG vopono::util              > ip addr add 10.200.2.1/24 dev mv_albania_d
 2022-02-03T21:35:53.687Z DEBUG vopono::netns             > ip netns exec vopono_mv_albania ip addr add 10.200.2.2/24 dev mv_albania_s
 2022-02-03T21:35:53.688Z DEBUG vopono::netns             > ip netns exec vopono_mv_albania ip route add default via 10.200.2.1 dev mv_albania_s
 2022-02-03T21:35:53.690Z INFO  vopono::netns             > IP address of namespace as seen from host: 10.200.2.2
 2022-02-03T21:35:53.690Z INFO  vopono::netns             > IP address of host as seen from namespace: 10.200.2.1
 2022-02-03T21:35:53.690Z DEBUG vopono::util              > nft add table inet vopono_nat
 2022-02-03T21:35:53.692Z DEBUG vopono::util              > nft add chain inet vopono_nat postrouting { type nat hook postrouting priority 100 ; }
 2022-02-03T21:35:53.698Z DEBUG vopono::util              > nft add rule inet vopono_nat postrouting oifname wlp1s0 ip saddr 10.200.2.0/24 counter masquerade
 2022-02-03T21:35:53.705Z DEBUG vopono::util              > nft add table inet vopono_bridge
 2022-02-03T21:35:53.708Z DEBUG vopono::util              > nft add chain inet vopono_bridge forward { type filter hook forward priority -10 ; }
 2022-02-03T21:35:53.710Z DEBUG vopono::util              > nft add rule inet vopono_bridge forward iifname mv_albania_d oifname wlp1s0 counter accept
 2022-02-03T21:35:53.712Z DEBUG vopono::util              > nft add rule inet vopono_bridge forward oifname mv_albania_d iifname wlp1s0 counter accept
 2022-02-03T21:40:29.926Z DEBUG vopono::netns             > ip netns exec vopono_c_SB15qSaez7U ip addr add 127.0.0.1/8 dev lo
 2022-02-03T21:40:29.928Z DEBUG vopono::netns             > ip netns exec vopono_c_SB15qSaez7U ip link set lo up
STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
connected  full          enabled  enabled  enabled  enabled
 2022-02-03T21:40:29.940Z DEBUG vopono::veth_pair         > Detected NetworkManager running
 2022-02-03T21:40:29.940Z DEBUG vopono::veth_pair         > NetworkManager detected, adding c_SB15qSaez7U_d to unmanaged devices
 2022-02-03T21:40:29.940Z DEBUG vopono::veth_pair         > Appending to existing NetworkManager config file: /etc/NetworkManager/conf.d/unmanaged.conf
 2022-02-03T21:40:29.940Z DEBUG vopono::util              > nmcli connection reload
not running
 2022-02-03T21:40:30.061Z DEBUG vopono::veth_pair         > firewalld not detected running
 2022-02-03T21:40:30.061Z DEBUG vopono::util              > ip link add c_SB15qSaez7U_d type veth peer name c_SB15qSaez7U_s
 2022-02-03T21:40:30.064Z DEBUG vopono::util              > ip link set c_SB15qSaez7U_d up
 2022-02-03T21:40:30.066Z DEBUG vopono::util              > ip link set c_SB15qSaez7U_s netns vopono_c_SB15qSaez7U up
 2022-02-03T21:40:30.083Z DEBUG vopono::util              > ip addr add 10.200.1.1/24 dev c_SB15qSaez7U_d
 2022-02-03T21:40:30.084Z DEBUG vopono::netns             > ip netns exec vopono_c_SB15qSaez7U ip addr add 10.200.1.2/24 dev c_SB15qSaez7U_s
 2022-02-03T21:40:30.086Z DEBUG vopono::netns             > ip netns exec vopono_c_SB15qSaez7U ip route add default via 10.200.1.1 dev c_SB15qSaez7U_s
 2022-02-03T21:40:30.089Z INFO  vopono::netns             > IP address of namespace as seen from host: 10.200.1.2
 2022-02-03T21:40:30.089Z INFO  vopono::netns             > IP address of host as seen from namespace: 10.200.1.1
 2022-02-03T21:40:30.089Z DEBUG vopono::util              > nft add table inet vopono_nat
 2022-02-03T21:40:30.090Z DEBUG vopono::util              > nft add chain inet vopono_nat postrouting { type nat hook postrouting priority 100 ; }
 2022-02-03T21:40:30.092Z DEBUG vopono::util              > nft add rule inet vopono_nat postrouting oifname wlp1s0 ip saddr 10.200.1.0/24 counter masquerade
 2022-02-03T21:40:30.094Z DEBUG vopono::util              > nft add table inet vopono_bridge
 2022-02-03T21:40:30.096Z DEBUG vopono::util              > nft add chain inet vopono_bridge forward { type filter hook forward priority -10 ; }
 2022-02-03T21:40:30.098Z DEBUG vopono::util              > nft add rule inet vopono_bridge forward iifname c_SB15qSaez7U_d oifname wlp1s0 counter accept
 2022-02-03T21:40:30.099Z DEBUG vopono::util              > nft add rule inet vopono_bridge forward oifname c_SB15qSaez7U_d iifname wlp1s0 counter accept
 2022-02-03T21:40:30.100Z DEBUG vopono::util              > sysctl -q net.ipv4.ip_forward=1
 2022-02-03T21:40:30.101Z DEBUG vopono::dns_config        > Setting namespace vopono_c_SB15qSaez7U DNS server to 8.8.8.8
 2022-02-03T21:40:30.101Z DEBUG vopono::shadowsocks       > socks-proxy detected, will launch Shadowsocks server
 2022-02-03T21:40:30.101Z WARN  vopono::exec              > Custom provider specifies socks-proxy, if this is local you must run it yourself (e.g. shadowsocks)

@jamesmcm
Copy link
Owner

jamesmcm commented Feb 5, 2022

A workaround is to immediately run the shadowsocks server inside the generated network namespace:

$ vopono -v exec -o 1080 --custom ~/.config/vopono/mv/openvpn/albania-al.ovpn --protocol openvpn --no-killswitch firefox-developer-edition

# Immediately after in another terminal (get the namespace name from the log):

$ sudo ip netns exec vopono_c_4phFPBNz ss-local -s 43.245.163.18 -p 443 -l 1080 -k mullvad -m aes-256-gcm

It will fail to connect at first, but it waits and then connects okay.

It's not ideal, but the issue we have no way of knowing what the configuration and password, etc. for the shadowsocks server should be for custom providers, so we can't run it automatically as we create the network namespace.

@NB-2022
Copy link
Author

NB-2022 commented Jun 10, 2022

Hello,

I can confirm that works. Two things would improve this.

  1. Allow a semi-killswitch (should be possible with a deny and allow on the ip tables) that only allows connections on that namespace to a sperified IP when not connected (maybe add an option for passing IPs to bypass the killswitch).

  2. Allow custom namespace names, so someone could automate connecting to the OpenVPN server and Shadowsocks.

@jamesmcm jamesmcm mentioned this issue Jul 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants