In Ubuntu with the apt package manger, I am able to set up a SOCKS 5 proxy and use apt through it. All that is needed is to edit /etc/apt/apt.conf.d/proxy.conf as follows:
### Using reverse port forwarding to a SOCKS 5 proxy
Acquire::http::Proxy "socks5h://127.0.0.1:7890/";
Then I can run apt update/upgrade/install commands and apt will use that SOCKS 5 proxy (which in my case is a reverse port forward to a SOCKS 5 proxy set up with ssh -D ).
Is there a way to get zypper to behave in a similar way, where it will use a SOCKS 5 proxy?
My scenario is:
Server A (internet access but limited ability to install other packages)
Server B (openSUSE, no internet access, need to install other packages)
I would like to do the following:
serverA: ssh -D 7777 -Nf myself@localhost # opens a SOCKS 5 proxy listening on port 7777
serverA: ssh -R 7890:127.0.0.1:7777 user@serverB # sets up reverse port forwarding to the SOCKS 5 proxy
serverB: # configure zypper to use socks://127.0.0.1:7890
serverB: zypper update
Is this possible? I would prefer to not install squid or other utilities on serverA if possible.
No,
None of those YaST proxy options will work.
But I wouldn’t say you shouldn’t just try Arvidjaar’s suggestion just to see if it works (I’d put that into the HTTP input field)
I don’t know that zypper has ever supported SOCKS5.
IMO easiest solution is if you have control over your proxy, you could open up an http proxy specifically for your openSUSE box.
How are web browsers accessing the Internet on your network, I’m sure those are connecting as web proxy clients and not as SOCKS clients (which is more typical of heavy apps like email clients, database clients, etc)… However web browsers are working, zypper and YaST can be configured to connect in a similar way.
When I look at the following list of socksifiers, I seem to remember a very long time ago I did a little experimenting with the Dante socksifier, but I can’t remember exactly what I did and results.
Guess what? I actually did test it before writing. Of course, for someone who begins every reply with “I have no idea what you are talking about” it is very unusual idea.
If it works, that would be surprising.
As the @OP asked, which field did you enter that string?
And, since you are pointing the proxy client to localhost, what proxy are you running on your local machine?
I’ve tried a couple of ways with the yast2 proxy settings and haven’t been able to get zypper to work through the socks proxy. I tried setting “Enable proxy,” “Use same proxy for all protocols,” and setting the HTTP proxy URL to “socks://127.0.0.1:7890.”
I found that the DNS configurations had not been set in my openSUSE server, and after setting it I was able to resolve the FQDNs for the repositories and run zypper. However, that is actually more of a setback than a step forward, because in my final deployment the server will not have internet access. It’ll be behind a firewall and the only way in will be with ssh, which is why I’m wanting to set up a reverse port forward to allow zypper to update/install packages.
Therefore, to test the proxy setting, I configured the proxy as mentioned above, then tore down my SOCKS 5 proxy on “serverA,” and zypper was still able to install new packages, indicating it is not using the SOCKS 5 proxy.
Per tsu2’s posts, I’ve also tried proxychains-ng (aka proxychains4). I can get telnet to use the SOCKS 5 proxy server on “serverA” by using proxychains4, but I can’t get zypper to work. It seems to just ignore proxychains altogether (maybe it’s not dynamically linked?).
OK,
Then you should already have all your pieces installed since you have proxychains-ng!
No need to find some other socksifying app…
I’d imagine it should work as follows…
Inspect your repository URLs to see if any are configured to use any other protocol besides https which should be pretty standard.
Configure your YaST proxy to re-direct all(or specific protocols depending on above step) to localhost (don’t specify socks, socks5 or anything else, simply redirect all traffic to your proxychains-ng app). Specify the port as may or may not be needed.
Configure “Proxylist” in your /etc/proxychains.conf as necessary, see the commented examples at the end of the file, you’ll probably want to configure at least the sock5 entry with any credentials as needed.
I’m guessing a bit, but then you should be able to run any zypper command by simply prepending “proxychains” before the zypper command, eg
proxychains4 zypper up
As I described should be easiest way to make this work, everything else supports making custom modifications like alternative configuration files, testing for DNS resolution (if that is the error that is returned)
There should not be any need to configure the YaST proxy… so leave out those steps.
Simply do the other steps which is to configure the proxychains-ng config file and then invoke by prepending proxychains4 before the command as I described.
Still no luck, even with proxychains4. I’ve tried with the system proxy enabled and disabled, but I can’t get zypper to use the SOCKS proxy no matter what.
Post your proxychains config file
The proxy server application that’s being used (just the name for now)
and
The proxychains zypper command with its result.
I find it hard to believe that there should be an issue… seems like a pretty simple proxy forwarding, it’s either a configuration problem or a proxychains problem and if a proxychains problem then you should determine if it’s the application itself or how it’s communicating with your proxy server…
Maybe try running another app through proxychains… do you have anything that might be a suitable socks5 candiate like a locally installed email client (like Thunderbird), ssh, tor(I haven’t tried)
The following Wikipedia list of bittorrent clients provides details like SOCKS support
I saw that proxychains doesn’t work with some categories of applications depending on their use of dynamic libraries. So I’m wondering if zypper is one that can’t be proxied through proxychains.
Also, I was able to get a different application to work through proxychains, so I know proxychains is working.
Here is my configuration file. The only change I made to the default one is the last line.
~> cat /etc/proxychains.conf
# proxychains.conf VER 4.x
#
# HTTP, SOCKS4a, SOCKS5 tunneling proxifier with DNS.
# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
#dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
#round_robin_chain
#
# Round Robin - Each connection will be done via chained proxies
# of chain_len length
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped).
# the start of the current proxy chain is the proxy after the last
# proxy in the previously invoked proxy chain.
# if the end of the proxy chain is reached while looking for proxies
# start at the beginning again.
# otherwise EINTR is returned to the app
# These semantics are not guaranteed in a multithreaded environment.
#
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see chain_len) from the list.
# this option is good to test your IDS :)
# Make sense only if random_chain or round_robin_chain
#chain_len = 2
# Quiet mode (no output from library)
#quiet_mode
# Proxy DNS requests - no leak for DNS data
proxy_dns
# set the class A subnet number to use for the internal remote DNS mapping
# we use the reserved 224.x.x.x range by default,
# if the proxified app does a DNS request, we will return an IP from that range.
# on further accesses to this ip we will send the saved DNS name to the proxy.
# in case some control-freak app checks the returned ip, and denies to
# connect, you can use another subnet, e.g. 10.x.x.x or 127.x.x.x.
# of course you should make sure that the proxified app does not need
# *real* access to this subnet.
# i.e. dont use the same subnet then in the localnet section
#remote_dns_subnet 127
#remote_dns_subnet 10
remote_dns_subnet 224
# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000
### Examples for localnet exclusion
## localnet ranges will *not* use a proxy to connect.
## Exclude connections to 192.168.1.0/24 with port 80
# localnet 192.168.1.0:80/255.255.255.0
## Exclude connections to 192.168.100.0/24
# localnet 192.168.100.0/255.255.255.0
## Exclude connections to ANYwhere with port 80
# localnet 0.0.0.0:80/0.0.0.0
## RFC5735 Loopback address range
## if you enable this, you have to make sure remote_dns_subnet is not 127
## you'll need to enable it if you want to use an application that
## connects to localhost.
# localnet 127.0.0.0/255.0.0.0
## RFC1918 Private Address Ranges
# localnet 10.0.0.0/255.0.0.0
# localnet 172.16.0.0/255.240.0.0
# localnet 192.168.0.0/255.255.0.0
# ProxyList format
# type ip port [user pass]
# (values separated by 'tab' or 'blank')
#
# only numeric ipv4 addresses are valid
#
#
# Examples:
#
# socks5 192.168.67.78 1080 lamer secret
# http 192.168.89.3 8080 justu hidden
# socks4 192.168.1.49 1080
# http 192.168.39.93 8080
#
#
# proxy types: http, socks4, socks5
# ( auth types supported: "basic"-http "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks5 127.0.0.1 7890
You didn’t answer my question what proxy you’re using.
That last line is the default configuration if you have tor installed on your machine and you want to direct your application through tor… and unless you changed the tor SOCKS port or installed another proxy locally on your machine, you should not have changed that line at all.
So again… because it’s important…
What proxy are you trying to cross or use?
An example is if your network has a proxy firewall running on your Internet gateway…
In that case you would comment out the existing line pointing to a tor gateway, and add a line that includes the protocol (eg socks5), the IP address (unless you have lAN name resolution in which case you might use the hostname of your gateway), the port number and any credentials as may be needed.
The proxy is a SOCKS 5 proxy running on a server (serverA) that has internet access and ssh access to openSUSE (serverB). I’m opening remote port forwarding when I ssh from serverA to serverB that points back to the SOCKS 5 proxy running on serverA.
serverA: ssh -D 7777 -Nf serverA-user@localhost # opens a SOCKS 5 proxy listening on port 7777
serverA: ssh -R 7890:127.0.0.1:7777 serverB-user@serverB # sets up reverse port forwarding to the SOCKS 5 proxy
After running those two commands, I expect openSUSE (serverB) to be able to reach the SOCKS 5 proxy via 127.0.0.1:7890. Thus if zypper can utilize the SOCKS 5 proxy via 127.0.0.1:7890, it should be able to reach the internet.
Also, I was assuming that the last line in the configuration file does not rely on tor in any way, but only that it sets up the default type (socks4) and port that tor uses. Since I changed it to socks5 and my port (7890), I think the file’s comment about tor is irrelevant.
You don’t provide an IP address for your rpoxy server, so I’ll just use your given “ServarA” as the hostname…substitute ServerA’s IP address if you don’t have LAN name resolution working so your client can find the machine…
In your proxychains config file, comment out that last line with “127.0.0.1” in it… The number of spaces appears not to be important, the text string appears to be space delimited.
Insert the following line in the proxylist, ie the line immediately after the line you just commented out…
socks5 ServerA 7890 username password
The above line configures the proxy chain (relay) to connect to a socks5 proxy at network address ServerA and listening on port 7890, with proxy connection credentials username and password.
For zypper to use proxychains to connect to the above configured SOCKS5 proxy server, you would run the following
proxychains4 zypper up
If the above doesn’t work, I’d suggest trying
proxychains4 "zypper up"
Nothing else should be required, this simply wraps the zypper command inside of a proxychains command and connection to your proxy server, which then makes a connection to the remote destination.
Well, serverB cannot reach serverA’s port 7890 due to a firewall between the two servers. This is why I’m using the ssh reverse port forward so that serverB’s local port 7890 redirects to serverA’s port 7777 (which is the SOCKS proxy) via the ssh tunnel (which is permitted through the firewall). I’m still of the opinion that zypper cannot be used through proxychains4 due to some details of its implementation. I can get other applications to work through proxychains4, but not zypper.
OK,
I’ll try to find some time (can’t guarantee) to set up a proxy and test using proxychains and zypper…
Backing up though,
In the beginning I asked whether you have any kind of control over your proxy server…
It’s common for a proxy server on the edge of your network to support http/https proxying(ie Web Proxy server which is different functionality than a SOCKS5 Proxy Server)…
If your web browsers can browse the Internet, then you likely have that configured. and should be the simplest way to connect… If your web proxy doesn’t require credentials or credentials are automatically passed (eg by LDAP or AD), then it should be the simplest solution… the https connection should work and there should not be a need to use SOCKS.
Else,
I really don’t understand your need to configure a ServerB if I understand your topology… If you choose to do that with SSH for some reason I don’t see how that should affect zypper or any other app.
Any LAN side interfaces on your proxy server should be exposed directly to your LAN and shouldn’t need to be forwarded through something else except perhaps to “socksify”(or modify for some other protocol) the connection. And, although it’s more common for a Proxy server to be multi-homed (separate NICs and network interfaces for your different zones), configuration tricks can be done to deploy on a single NIC. Even in the case of a “LAN behind a LAN” with different authentication, the “behind LAN” should still be able to connect directly with the “forward LAN” proxy server.
Or, are you for some reason connecting from the WAN side?
BTW -
I’ll ask one last time,
Don’t know if you’re overlooking or deliberately avoiding an answer…
What is your proxy server application?