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

Not work on Debian testing (buster) #122

Open
cuihaoleo opened this issue Mar 13, 2018 · 2 comments
Open

Not work on Debian testing (buster) #122

cuihaoleo opened this issue Mar 13, 2018 · 2 comments

Comments

@cuihaoleo
Copy link

redsocks stopped working after upgrading my Debian to testing. Same redsocks and nftables (yes I use nft instead of iptables) configs worked well on Debian stable (stretch).

Redsocks seem not to redirect packet to my HTTP proxy any more.

redsocks config:

base {
        log_debug = on;
        log_info = on;
        log = "syslog:daemon";
        daemon = on;
        user = redsocks;
        group = redsocks;
        redirector = iptables;
}

redsocks {
        local_ip = 0.0.0.0;
        local_port = 9080;
        ip = 127.0.0.1;
        disclose_src = false;
        port = 8080;
        type = http-relay;
        login = "XXX";
        password = "YYY";
}

redsocks {
        local_ip = 0.0.0.0;
        local_port = 9081;
        ip = 127.0.0.1;
        disclose_src = false;
        port = 8080;
        type = http-connect;
        login = "XXX";
        password = "YYY";
}

Following are some debug info. I start redsocks on my gateway and do curl http://httpbin.org/ip on another workstation (whose packets are supposed to go through redsocks).

strace log:

$ sudo strace -p $(pidof redsocks)
strace: Process 20900 attached
epoll_wait(3, [{EPOLLIN, {u32=7, u64=7}}], 32, -1) = 1
accept(7, {sa_family=AF_INET, sin_port=htons(43152), sin_addr=inet_addr("192.168.90.10")}, [16]) = 9
getsockname(9, {sa_family=AF_INET, sin_port=htons(9080), sin_addr=inet_addr("192.168.90.1")}, [16]) = 0
getsockopt(9, SOL_IP, 0x50 /* IP_??? */, "\2\0\0P2\23\374E\0\0\0\0\0\0\0\0", [16]) = 0
fcntl(9, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(9, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(9, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 9, {EPOLLIN, {u32=9, u64=9}}) = 0
getpid()                                = 20900
sendto(8, "<30>Mar 13 13:04:50 redsocks[209"..., 86, MSG_NOSIGNAL, NULL, 0) = 86
epoll_wait(3, [{EPOLLIN, {u32=9, u64=9}}], 32, -1) = 1
ioctl(9, FIONREAD, [77])                = 0
readv(9, [{iov_base="GET /ip HTTP/1.1\r\nHost: httpbin."..., iov_len=77}], 1) = 77
epoll_wait(3,

Opened connection:

$ sudo ss -teinp  | grep redsocks
ESTAB       0        0                                      192.168.90.1:9080                                              192.168.90.10:54174                   users:(("redsocks",pid=21312,fd=9)) timer:(keepalive,118min,0) uid:111 ino:137209 sk:1c3 <->

syslog after kill -USR1 $(pidof redsocks) :

Mar 13 13:07:04 cvhc-fire systemd[1]: Starting Redsocks transparent SOCKS proxy redirector...
Mar 13 13:07:04 cvhc-fire redsocks[21311]: 1520917624.363520 warning http-relay.c:124 httpr_instance_init(...) You should avoid `http-relay`, e.g. due to CVE-2009-0801
Mar 13 13:07:04 cvhc-fire redsocks[21312]: redsocks started, conn_max=128
Mar 13 13:07:04 cvhc-fire systemd[1]: Started Redsocks transparent SOCKS proxy redirector.
Mar 13 13:07:11 cvhc-fire redsocks[21312]: [192.168.90.10:54174->54.243.164.125:80]: accepted
Mar 13 13:08:45 cvhc-fire redsocks[21312]: Dumping client list for http-connect at 0.0.0.0:9081:
Mar 13 13:08:45 cvhc-fire redsocks[21312]: End of client list. 0 clients.
Mar 13 13:08:45 cvhc-fire redsocks[21312]: Dumping client list for http-relay at 0.0.0.0:9080:
Mar 13 13:08:45 cvhc-fire redsocks[21312]: [192.168.90.10:54174->54.243.164.125:80]: client: buf 9 (R/W) splice 0 (-/-) pipe[-1, -1]=0, relay: buf -1 (NULL) splice 0 (-/-) pipe[-1, -1]=0, age: 94.125477 sec, idle:
Mar 13 13:08:45 cvhc-fire redsocks[21312]: End of client list. 1 clients.

Kernel version 4.14.0-3-amd64
redsocks 0.5-1+b1 from Debian repo

@cuihaoleo
Copy link
Author

Debian testing now has libevent 2.1.8. Maybe dup to #107
Any workaround? Or I have to build redsocks against old libevent?

apoikos added a commit to apoikos/redsocks that referenced this issue Mar 29, 2018
_EVENT_NUMERIC_VERSION was renamed to EVENT__NUMERIC_VERSION in libevent
2.1. As a result, redsocks_evbuffer_readline would end up using
evbuffer_readline(buf), which causes client connections to hang
indefinitely.

Switch the check to using LIBEVENT_VERSION_NUMBER instead.
LIBEVENT_VERSION_NUMBER has been around since libevent 2.0.3 and
redsocks is already using it in other parts of the code.

Fixes darkk#107, darkk#122.
@andronoob
Copy link

#123

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