Portál AbcLinuxu, 4. května 2025 23:08
Řešení dotazu:
tun200 mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 192.168.200.1/24 scope global tun200 valid_lft forever preferred_lft forever
route 10.10.10.0/24 via 192.168.200.2 dev tun1
tcpdump 192.168.200.1 > 10.10.10.1: ICMP echo request, id 45638, seq 400, length 64Na straně MIkrotiku nevidím žádnou příchozí komunikaci od serveru. Na OpenVPN serveru má samozřejmě zapnutou volbu "client-to-client". Jen ještě upřesním, že používám proto tcp4, dev tun a mode server.
tak se nedostaneš do sítě, která je za připojením klientem, protože OpenVPN neví kam má poslat packet, aby to fungovalo korektněProto přece právě přidáváš ty routy. Na klientovi musí být zapnutý ip_forward. Klient bude posílat do místní sítě pakety se zdrojovou IP serveru (ověř si tcpdumpem), a zařízení v místní síti nebudou vědět, kam poslat odpověď, budou ji posílat přes výchozí bránu, což může (pak je to v pohodě) i nemusí (pak to nefunguje) být ten openvpn klient. Jedna možnost je nastavit na zařízeních nebo na bráně, aby IP serveru ve VPN routovali přes toho vpn klienta (vyžaduje to nastavit na zařízeních, ke kterým potenciálně nemáš přístup nebo takovou věc neumí), druhá možnost je na openvpn klientovi dělat maškarádu (
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
) čímž se adresa přepíše, nevýhoda pro změnu je že se tím originální adresa skryje a může to dělat bordel pokud používáš nějakou věc která s maškarádou nepočítá (třeba FTP předpokládám).
prostě nic nedělá ani v logu na serveru nic není zaznamenánoV konfiguráku klienta se dá nějak zvýšit verbosity.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.