Centos7 настроен для локалки как шлюз в интернет.
Нужно подключаться к локалке из интернета с мобильных устройств (Android).
По многочисленным мануалам установил на Centos pptpd, настроил.
Устройства на Android нормально цепляются, но локалка не видна.
Как таки увидеть хосты в локалке?
ifconfig -a (после подключения клиента)
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.207.1 netmask 255.255.255.0 broadcast 192.168.207.255
ether 74:d4:35:ec:7c:ee txqueuelen 1000 (Ethernet)
RX packets 1445420 bytes 243550562 (232.2 MiB)
RX errors 0 dropped 119131 overruns 0 frame 0
TX packets 1842214 bytes 1830983979 (1.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet XXX.XXX.XXX.XXX netmask 255.255.254.0 broadcast XXX.XXX.XXX.XXX
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 1833963 bytes 1831184013 (1.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1227742 bytes 224784430 (214.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp4s1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet YYY.YYY.YYY.YYY netmask 255.255.255.252 broadcast YYY.YYY.YYY.YYY
ether yy:yy:yy:yy:yy:yy txqueuelen 1000 (Ethernet)
RX packets 19096 bytes 10389163 (9.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 210 (210.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
gre0: flags=128<NOARP> mtu 1476
unspec 00-00-00-00-00-00-F0-24-00-00-00-00-00-00-00-00 txqueuelen 1 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
gretap0: flags=4098<BROADCAST,MULTICAST> mtu 1462
ether 00:00:00:00:00:00 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1 (Local Loopback)
RX packets 6 bytes 504 (504.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 504 (504.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1396
inet 192.168.207.6 netmask 255.255.255.255 destination 192.168.207.234
ppp txqueuelen 3 (Point-to-Point Protocol)
RX packets 9 bytes 253 (253.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7 bytes 94 (94.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
pptpd.conf:
option /etc/ppp/options.pptpd
logwtmp
localip 192.168.207.6
remoteip 192.168.207.234-238
options.pptpd:
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 192.168.207.2
ms-dns 8.8.8.8
proxyarp
debug
lock
nobsdcomp
novj
novjccomp
nologfd
В iptables добавлял:
iptables -A INPUT -p gre -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
iptables -A FORWARD -i enp2s0 -o ppp+ -j ACCEPT
iptables -A FORWARD -i ppp+ -o enp2s0 -j ACCEPT
iptables -t nat -A POSTROUTING -o enp2s0 -j MASQUERADE
iptables -A OUTPUT -p gre -j ACCEPT
Для эксперимента вообще очищал iptables полностью и все политики ставил в ACCEPT - тот же результат.
В sysctl.conf
net.ipv4.ip_forward = 1
Модули
modprobe ip_gre
modprobe ip_nat_pptp
modprobe ip_conntrack_pptp
подключены.
route (после соединения с клиентом):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default XXXxXXXxXXXxXXX. 0.0.0.0 UG 100 0 0 enp4s0
default gateway 0.0.0.0 UG 101 0 0 enp4s1
YYY.YYY.YYY.YYY 0.0.0.0 255.255.254.0 U 100 0 0 enp4s0
192.168.1.234 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.207.0 0.0.0.0 255.255.255.0 U 100 0 0 enp2s0
YYY.YYY.YYY.GW 0.0.0.0 255.255.255.252 U 100 0 0 enp4s1
Если соединиться клиентом, на сервере запустить tcpdump -i ppp0 и на клиенте нажать «обзор сети», то tcpdump выкидывает:
11:58:05.920255 IP 192.168.207.234.55639 > 192.168.1.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921366 IP 192.168.207.234.55639 > 192.168.1.2.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921402 IP 192.168.207.234.55639 > 192.168.1.3.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921420 IP 192.168.207.234.55639 > 192.168.1.4.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921433 IP 192.168.207.234.55639 > 192.168.1.5.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921517 IP 192.168.207.234.55639 > 192.168.1.8.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921737 IP 192.168.207.234.55639 > 192.168.1.7.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921755 IP 192.168.207.234.55639 > 192.168.1.10.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921772 IP 192.168.207.234.55639 > 192.168.1.9.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921783 IP 192.168.207.234.55639 > 192.168.1.11.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
11:58:05.921795 IP 192.168.207.234.55639 > 192.168.1.13.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
(это фрагмент)
т.е. он с выданного клиенту локального адреса 192.168.207.234 почему-то ломится в подсеть 192.168.1.0, а не в 192.168.207.0
Подсеть 192.168.1.0 - это подсеть за удалённым роутером, в которой работает Android-устройство.
Думаю, что что-то с маршрутами. Но где что поправить не соображу.