Izo_lda

есть сервер один есть сервер два за первым сервером есть компьютера за вторым сервером есть компьютеры за первым сервером компьютеры сидят по технологии NAT и второй сервер их видит через сетевой адрес самого сервера на самом первом сервере правило NAT iptables -t nat -A POSTROUTING -s 192.168.1.0/24 ! -d 10.0.0.0/8 -o eth0 -j SNAT --to-source $REAL_IP при таком варианте не работает поднятие VPN с компьютера за первым сервером на компьютер на котором VPN-server и компьютер находиться за вторым сервером если использовать на первом сервере правило NAT iptables -t nat -A POSTROUTING -s 192.168.1.0/24 ! -d $SERVER2_NETWORK -o eth0 -j SNAT --to-source $REAL_IP и сделать маршрут видимости абонентов второго сервера без NAT то тогда работает поднятие VPN с компьютера за первым сервером на компьютер на котором VPN-server и компьютер находиться за вторым сервером но проблема в том что такой вариант правила NAT мы использовать не можем и пока не нашли способа как сделать правило с исключением NAT для двух подсетей ! -d {$NETWORK1 $NETWORK2} - в таком варианте не работает

добавил и вывод такой же в логах   вот что загружено в системе и поднятие vpn не работает lsmod | grep -P "gre|pptp" nf_nat_pptp 16384 0 nf_nat_proto_gre 16384 1 nf_nat_pptp nf_conntrack_pptp 16384 1 nf_nat_pptp nf_conntrack_proto_gre 16384 1 nf_conntrack_pptp nf_nat 28672 2 nf_nat_pptp,nf_nat_proto_gre nf_conntrack 114688 4 nf_nat_pptp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_nat ip_gre 24576 0 ip_tunnel 28672 1 ip_gre gre 16384 1 ip_gre

root@vixen:/# pon test debug dump logfd 2 updetach using channel 1 Using interface ppp0 Connect: ppp0 <--> /dev/pts/1 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xedd3663a> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xedd3663a> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xedd3663a> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xedd3663a> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xedd3663a> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xedd3663a> <pcomp> <accomp>] ^CTerminating on signal 2 Child process pptp 213.24.75.18 --nolaunchpppd (pid 455) terminated with signal 2 Modem hangup Connection terminated.

под windows просто зависает при попытке подключиться без какой либо ошибки под linux Sep 8 14:02:40 vixen pppd[503]: pppd 2.4.7 started by izolda, uid 0 Sep 8 14:02:40 vixen kernel: [10656.181181] PPP generic driver version 2.4.2 Sep 8 14:02:40 vixen pppd[503]: Using interface ppp0 Sep 8 14:02:40 vixen pppd[503]: Connect: ppp0 <--> /dev/pts/1 Sep 8 14:02:43 vixen pppd[503]: Modem hangup Sep 8 14:02:43 vixen pppd[503]: Connection terminated. Sep 8 14:02:43 vixen pppd[503]: Exit. в фаерволе только это iptables -F iptables -t nat -F iptables -t mangle -F iptables -X iptables -t nat -A POSTROUTING -s 192.168.0.0/24 ! -d 10.0.0.0/8 -o eth0 -j SNAT --to-source 213.24.76.23 при tcpdump proto 47 при подключении повторяющийся в цикле 11:40:54.557068 IP 192.168.0.2 > host-213.24.75.18: GREv1, call 67, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23 ...

Добрый день. Столкнулся с такой проблемой и не получается понять в чем дело. На Debian 7 работало поднятие туннеля VPN (PPTP) через сервер за NAT а уже на Debian 9 не работает. Возможно кто то еще сталкивался с этой проблемой, нашел ее решение и может подсказать что надо сделать что бы устранить эту проблему?

спасибо, попробую такой вариант

использую tc для шейпинга и пытаюсь настроить через хэш таблицы download поток нормально загоняется для каждого адреса в свою таблицу а upload все равно продолжает идти через таблицу по умолчанию 800:: если upload резать через таблицу по умолчанию 800:: при достижении ~ более 500 отдельных сетевых адресов начинаются затыки в сети если upload при большом количестве отдельных сетевых адресов отключить то затыков в сети не наблюдается пример рабочего кода с ограничением при upload через таблицу по умолчанию 800:: rmmod ifb modprobe ifb numifbs=1 tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 9 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000MBit ceil 1000MBit tc class add dev eth0 parent 1:1 classid 1:9 htb rate 1000MBit ceil 1000MBit tc qdisc add dev eth0 parent 1:9 handle 9: sfq perturb 10 ip link set dev ifb0 up tc qdisc del dev ifb0 root tc qdisc del dev ifb0 ingress tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 tc qdisc add dev ifb0 root handle 1: htb default 9 tc class add dev ifb0 parent 1: classid 1:1 htb rate 1000MBit ceil 1000MBit tc class add dev ifb0 parent 1:1 classid 1:9 htb rate 1000MBit ceil 1000MBit tc qdisc add dev ifb0 parent 1:9 handle 9: sfq perturb 10 tc filter add dev eth0 parent 1:0 handle 20: protocol ip u32 divisor 256 tc filter add dev eth0 parent 1:0 protocol ip u32 ht 800:: match ip dst 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 20: tc filter add dev ifb0 parent 1:0 handle 20: protocol ip u32 divisor 256 tc filter add dev ifb0 parent 1:0 protocol ip u32 ht 800:: match ip src 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 20: tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 20:15: match ip dst 192.168.0.21/32 flowid 1:10 tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit tc qdisc add dev ifb0 parent 1:10 handle 10: sfq perturb 10 tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 800:: match ip src 192.168.0.21/32 flowid 1:10 при upload через отдельную таблицу все равно поток идет через таблицу по умолчанию 800:: ... tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 20:15: match ip src 192.168.0.21/32 flowid 1:10 возможно я что то не так формирую в хэш таблицу или оно просто и не должно работать в ifb через хэш таблицы?