SS5 SOCKS Proxy: Difference between revisions

Line 11:

By default SS5 listens on port 1080. Since my environment uses OpenVPN VPNs and SS5 is not exposed publicly, there wasn't any additional configuration to do or stuff to worry about.

As noted above the software is more than half a decade old. In my case it meant it wasn't build for the CentOS 7 systemctl "Unit" world, but it worked with a ~~modification~~. The permission on the /etc/init.d/ss5 file had to be changed: chmod 755 /etc/init.d/ss5 and then systemctl enable ss5 worked correctly as did systemctl start ss5.

As noted above the software is more than half a decade old. In my case it meant it wasn't build for the CentOS 7 systemctl "Unit" world, but it worked with a couple of modifications. The SS5 software did not automatically create a directory for its PID file, so added the /var/run/ss5 directory and it was able to add the PID file. The permission on the /etc/init.d/ss5 file had to be changed: chmod 755 /etc/init.d/ss5 and then systemctl enable ss5 worked correctly as did systemctl start ss5.

From there I checked it with my "client software" (which has SOCKS Proxy client capability built in) and verified that it worked. After that it was a matter of making sure the software only connected through the SOCKS Proxy which meant checking off every "Use..." and "Disable..." box under the Connection Section. Tested again by turning the SS5 SOCKS Proxy off which resulted in nothing happening from my client, then turning SS5 back on and everything worked. That meant all traffic for that client was routed through the SS5 SOCKS Proxy. And I verified it with this command (and saw a bazillion connections related to SS5): netstat -anp | grep ss5.

From there I checked it with my "client software" (which has SOCKS Proxy client capability built in) and verified that it worked. After that it was a matter of making sure the software only connected through the SOCKS Proxy which meant checking off every "Use..." and "Disable..." box under the Connection Section. Tested again by turning the SS5 SOCKS Proxy off which resulted in nothing happening from my client, then turning SS5 back on and everything worked. That meant all traffic for that client was routed through the SS5 SOCKS Proxy. And I verified it with this command (and saw a bazillion connections related to SS5): netstat -anp | grep ss5. Double verified it by noticing there was almost zero traffic through the host computer's default gateway router and a lot of bandwidth through a separate VPN router.

My client software is a bandwidth hog, so all the other traffic flowing through the VPN tunnel was very slow. Oh, well.

@@ Line 11: / Line 11: @@
 By default SS5 listens on port 1080.  Since my environment uses OpenVPN VPNs and SS5 is not exposed publicly, there wasn't any additional configuration to do or stuff to worry about.
-As noted above the software is more than half a decade old.  In my case it meant it wasn't build for the CentOS 7 systemctl "Unit" world, but it worked with a modification.  The permission on the /etc/init.d/ss5 file had to be changed: chmod 755 /etc/init.d/ss5 and then systemctl enable ss5 worked correctly as did systemctl start ss5.
+As noted above the software is more than half a decade old.  In my case it meant it wasn't build for the CentOS 7 systemctl "Unit" world, but it worked with a couple of modifications.  The SS5 software did not automatically create a directory for its PID file, so added the /var/run/ss5 directory and it was able to add the PID file.  The permission on the /etc/init.d/ss5 file had to be changed: chmod 755 /etc/init.d/ss5 and then systemctl enable ss5 worked correctly as did systemctl start ss5.
-From there I checked it with my "client software" (which has SOCKS Proxy client capability built in) and verified that it worked.  After that it was a matter of making sure the software only connected through the SOCKS Proxy which meant checking off every "Use..." and "Disable..." box under the Connection Section.  Tested again by turning the SS5 SOCKS Proxy off which resulted in nothing happening from my client, then turning SS5 back on and everything worked.  That meant all traffic for that client was routed through the SS5 SOCKS Proxy.  And I verified it with this command (and saw a bazillion connections related to SS5): netstat -anp | grep ss5.
+From there I checked it with my "client software" (which has SOCKS Proxy client capability built in) and verified that it worked.  After that it was a matter of making sure the software only connected through the SOCKS Proxy which meant checking off every "Use..." and "Disable..." box under the Connection Section.  Tested again by turning the SS5 SOCKS Proxy off which resulted in nothing happening from my client, then turning SS5 back on and everything worked.  That meant all traffic for that client was routed through the SS5 SOCKS Proxy.  And I verified it with this command (and saw a bazillion connections related to SS5): netstat -anp | grep ss5.  Double verified it by noticing there was almost zero traffic through the host computer's default gateway router and a lot of bandwidth through a separate VPN router.
 My client software is a bandwidth hog, so all the other traffic flowing through the VPN tunnel was very slow.  Oh, well.