Mogę pokazać jak to wygląda na urządzeniach Openwrt. Będzie dłuuuugo, ale po kolei pokażę co jak leci 
Schemat wygląda następująco:
Klient VPN 10.8.0.2(polaczenie zdalne) --->Router (192.168.2.1 + OpenVPN 10.8.0.1) <- klient LAN po DHCP 192.168.2.178
Na kliencie LAN mamy na początek coś takiego:
# ip a | grep br-lan
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
inet 192.168.2.178/24 brd 192.168.2.255 scope global br-lan
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 br-lan
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
puszczamy ping ze zdalnego klienta Openvpn 10.8.0.2 na adres tego klienta w sieci LAN za serwerem OpenVPN i słuchamy co odbierze ten klient:
# tcpdump -i br-lan icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
22:55:20.549554 IP 10.8.0.2 > 192.168.2.178: ICMP echo request, id 7589, seq 0, length 64
22:55:20.549648 IP 192.168.2.178 > 10.8.0.2: ICMP echo reply, id 7589, seq 0, length 64
Dostał pinga z adresem źródłowym 10.8.0.2
Ponieważ odpowiedzi na adres 10.8.0.2 wg domyślnej trasy routingu ma pchać przez bramę 192.168.2.1 a więc to robi i umie odpowiedzieć, bo wie gdzie a dalej to już brama czyli router pcha odpowiedź w tunel.
symulacja, gdy skasujemy trasę domyślną na tym kliencie w sieci LAN:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
puszczamy ping ze zdalnego klienta Openvpn 10.8.0.2 na adres tego klienta i słuchamy:
# tcpdump -i br-lan icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
22:57:38.096541 IP 10.8.0.2 > 192.168.2.178: ICMP echo request, id 7865, seq 0, length 64
Dostał pinga z adresem źródłowym 10.8.0.2.
Nie umie odpowiedzieć na adres 10.8.0.2, bo nie wie gdzie odesłać odpowiedź.
U Ciebie może być to samo.
Klima być może nie umie dopisać sobie trasy domyślnej mimo ustawionego gateway-a lub jakiś wewnętrzny firewall odrzuca inne adresy, niż ten co jest ustawiony na wewnętrznej karcie.
Router z serwerem Openvpn:
# ip a | grep -e tun0 -e br-lan
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
inet 192.168.2.1/24 brd 192.168.2.255 scope global br-lan
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 500
inet 10.8.0.1/24 scope global tun0
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.4.2 0.0.0.0 UG 0 0 0 eth2
10.0.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan
dodaję regułę na routerze - serwerze OpenVPN:
# iptables -t nat -I POSTROUTING -s 10.8.0.2 -d 192.168.2.178 -j SNAT --to-source 192.168.2.1
objaśnienie: We wszystkim co leci od zdalnego klienta VPN z adresem źródłowym 10.8.0.2, do klienta sieci LAN o adresie 192.168.2.178 ma zostać zamieniony adres źródłowy, na IP routera 192.168.2.1.
Wracamy do klienta sieci LAN 192.168.2.178
puszczamy ping ze zdalnego klienta Openvpn 10.8.0.2 na adres LAN tego klienta i słuchamy....
# tcpdump -i br-lan icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
23:20:50.200739 IP 192.168.2.1 > 192.168.2.178: ICMP echo request, id 10946, seq 0, length 64
23:20:50.200816 IP 192.168.2.178 > 192.168.2.1: ICMP echo reply, id 10946, seq 0, length 64
Ping był wysłany z adresu 10.8.0.2 a nie z routera!
Klient LAN odebrał pinga, jakby jego własna brama chciała się dowiedzieć czy on jeszcze żyje.
Ponieważ zna swoją bramę (2.1) to jej odpowiedział, a dalej brama przekazała odpowiedź ponieważ miała zapis w tablicy połączeń.
A co widzi zdalny klient OpenVPN:
# tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:29:50.812678 IP 10.8.0.2 > 192.168.2.178: ICMP echo request, id 12134, seq 0, length 64
03:29:50.815651 IP 192.168.2.178 > 10.8.0.2: ICMP echo reply, id 12134, seq 0, length 64
Chciałem pokazać analizę ruchu sieciowego oraz mechanizm podmiany adresu źródłowego i jaki z tego może być pożytek przy problematycznych i nietypowych hostach, (pod warunkiem, że ogólny firewall na routerze jest prawidłowy i zezwala na odpowiedni forward)
Maskarada też mogłaby być od biedy, ale wtedy zamieniałaby adresy od wszystkich klientów VPN do wszystkich hostów w LAN.
Skoro inne hosty odpowiadają, to czy naprawdę potrzebujesz takiej armaty skoro musisz celować tylko w jednego "małego króliczka"?
Decyzja należy do Ciebie.
* WNDR 4300v2 * || * Xiaomi Miwifi Mini * || Netgear R6220 *
* DVBT2 - T230C *