Good day. I have a situation: a computer with debian (K) is connected to the router (A), which distributes the network 192.168.1.0/24. There is another router (B) (it has a “white” ip), which distributes the network 172.16.1.0/30, on which the pptp server is running, on which NAT is enabled. The pptp client is installed on the "K", which creates the ppp1 interface with ip 172.16.1.2 (but the mask for some reason / 32 is also on the keenetic ("B") route from / 32 - apparently "to the node"). Connection passes, the ping goes. The problem is the "triangular" route (well, I still think it is). When I connect to "K" (SSH, for example) from network "A", then everything works (eth0 - network "A" - default route). On the router "B" there is nat, forwarding connections from the Internet (to certain ports) to "K". Only in the packages "source" does not change to the one that the router has. However, this would not solve the problem entirely, because "K" has http-proxy, whose task is to send traffic from eth0 to ppp1. In the proxy settings (3proxy) I specified the "input" and "output" ip. Should work, probably, but does not work. The default route to change is not an option, since access to the Internet via eth0 is faster 7 times + another openvpn server is planned on the same computer that will accept connections from ppp1, and create connections via eth0 itself.
Thanks for answers.
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
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
And more: DNS traffic sent by 3proxy goes freely (goes and returns) via ppp1 (watched with tcpdump).