☰

3proxy 通过 pptp-linux VPN

tag-icon • tag-icon debian networking routing vpn http-proxy
3proxy 通过 pptp-linux VPN

我有一个情况：

  • 一台装有 debian (K) 的计算机连接到路由器 (A)，该路由器分配网络 192.168.1.0/24。
  • 还有另一个路由器 (B)（它有一个“白色”IP），它分配网络 172.16.1.0/30，在该网络上运行 pptp 服务器，并启用 NAT。
  • pptp 客户端安装在“K”上，它使用 ip 172.16.1.2 创建 ppp1 接口（但由于某种原因，掩码 / 32 也在从 / 32 到显然“到节点”的keenetic（“B”）路由上”）。
  • 连接通过，并且 ping 通。问题是“三角”路线（嗯，我仍然认为是）。
  • 当我从网络“A”连接到“K”（例如 SSH）时，一切正常（eth0 - 网络“A” - 默认路由）。
  • 路由器“B”上有 nat，将来自互联网（到某些端口）的连接转发到“K”。
  • 仅在包中“源”不会更改为路由器具有的源。
  • 然而，这并不能完全解决问题，因为“K”有 http-proxy，其任务是将流量从 eth0 发送到 ppp1。
  • 在代理设置（3proxy）中，我指定了“输入”和“输出”ip。

也许应该有效，但不起作用。更改默认路由不是一个选项，因为通过 eth0 访问互联网速度快了 7 倍 + 计划在同一台计算机上安装另一个 openvpn 服务器，该服务器将接受来自 ppp1 的连接，并通过 eth0 本身创建连接。


如果配置：

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 02:02:20:02:47:8f  txqueuelen 1000  (Ethernet)
        RX packets 5248  bytes 343827 (335.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 512  bytes 54725 (53.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 37

ppp1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1350
        inet 172.16.1.2  netmask 255.255.255.255  destination 172.16.1.1
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 8  bytes 118 (118.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 99 (99.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


/etc/3proxy/3proxy.cfg：

setgid 115
setuid 109

#nserver 192.168.1.1
nserver 172.16.1.1

nscache 65536

timeouts 1 5 30 60 180 1800 15 60

#In theory, from this point on, traffic should go through the ppp1 interface.
external 172.16.1.2 

internal 192.168.1.20

users $/etc/3proxy/.proxyauth

daemon

log /var/log/3proxy/3proxy.log D
logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

auth cache strong

proxy -n -p8080 -a

还有更多：3proxy 发送的 DNS 流量通过 ppp1 自由发送（发送和返回）（使用 tcpdump 监视）。

答案1

这可能是由于代理中缺少正确的模块；负责“natin”pptp 的模块。请尝试以下操作：

lsmod |grep nf_nat_pptp

如果该模块不存在，您必须输入：

modprobe nf_nat_pptp

echo 'net.netfilter.nf_conntrack_helper=1' >> /etc/sysctl.conf

sysctl -p

通过这些更改，pptp 流量应通过代理。

要永久启用该模块以供将来重新启动，您必须通过以下方式将其添加到模块文件中：

echo 'nf_nat_pptp' >> /etc/modules

相关内容