Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: ota karek 08. 10. 2023, 00:00:14

Název: OpenVPN a směrování provozu mezi tun0 a eth0
Přispěvatel: ota karek 08. 10. 2023, 00:00:14: Mám RPi s raspbianem s připojeneným USB WiFi, které mi zajišťuje konektivitu do inetu (wlan0). Dále mám v RPi OpenVPN klienta (tun0), který se připojuje na server do světa. Síťové nástroje i internetový prohlížeč v RPi ukazují stav, jaký potřebuji (tj. VPN připojená, sítově je vše OK). Na eth0 mám v dnsmasq.conf :
Kód: [Vybrat]
interface=eth0 dhcp-range=192.168.2.2,192.168.2.100,12ha v /etc/dhcpcd.conf
Kód: [Vybrat]
interface eth0 static ip_address=192.168.2.2/24
net.ipv4.ip_forward=1 mám též nastavené. Pokud k eth0 připojím NTB, načte si IP a má přístup (ping, ssh atd...) k bráně (tj. 192.168.2.2). Co potřebuji, je NATovat/přemostit/přeměrovat eth0 na tun0 (nebo naopak?). Dnes jsem celý den googloval, trápil se s iptable, ale nerozchodil jsem prostup. Prosím o radu, jak dotáhnout konfiguraci tak, aby připojený NTB k eth0 měl přístup do netu pomocí tun0 (tj. VPNky). Zde je ip a:
Kód: [Vybrat]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:e2:d4:a6 brd ff:ff:ff:ff:ff:ff inet 192.168.2.2/24 brd 192.168.2.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever inet6 fe80::67f7:221c:ac6f:6bc8/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:25:22:40:7a:37 brd ff:ff:ff:ff:ff:ff inet 192.168.8.107/24 brd 192.168.8.255 scope global dynamic noprefixroute wlan0 valid_lft 83956sec preferred_lft 73156sec inet6 fe80::e252:3e1:3380:a4e9/64 scope link valid_lft forever preferred_lft forever 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 10.8.0.2/24 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::b59:6928:7431:561e/64 scope link stable-privacy valid_lft forever preferred_lft foreverDěkuji za radu/nasměrování.
Název: Re:Raspberry PI, openvpn - problémy s natem tun0 a eth0
Přispěvatel: _Jenda 08. 10. 2023, 02:25:05: Podívej se tcpdumpem (tcpdump -ni ROZHRANÍ případně tcpdump -ni ROZHRANÍ icmp pokud by tam byl moc velký provoz - tohle zobrazí jen icmp - druhý počítač nechat pingat třeba na 8.8.8.8 a mělo by tam být vidět to) na příchozí pakety na rozhraní eth0 a na odchozí na tun0. Nejspíš zjistíš, že z tun0 odesíláš pakety se zdrojovou adresou z toho privátního subnetu 192.168.2.0/24, tj. nepřepsanou, a protistrana pak samozřejmě netuší kam poslat odpověď protože tento subnet nezná. Proto uděláš
Kód: [Vybrat]
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEa mohlo by to začít fungovat, případně se znovu podívej, jak vypadají odchozí pakety, příchozí pakety na VPN server, a odchozí/příchozí pakety z VPN serveru.
Název: Re:Raspberry PI, openvpn - problémy s natem tun0 a eth0
Přispěvatel: ota karek 08. 10. 2023, 10:23:42: Díky za pomoc! Bylo to přesně, jak jsi psal. Tj. můj stav před iptable:
Kód: [Vybrat]
Pinging 8.8.8.8 with 32 bytes of data: Request timed out. Request timed out. Request timed out. listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes 09:03:49.452891 IP 192.168.2.45 > 8.8.8.8: ICMP echo request, id 1, seq 338, length 40 09:03:54.352483 IP 192.168.2.45 > 8.8.8.8: ICMP echo request, id 1, seq 339, length 40 09:03:59.333621 IP 192.168.2.45 > 8.8.8.8: ICMP echo request, id 1, seq 340, length 40 09:04:04.340578 IP 192.168.2.45 > 8.8.8.8: ICMP echo request, id 1, seq 341, length 40
Po: "iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE" už to začalo dělat to, co mělo.

Kód: [Vybrat]
Reply from 8.8.8.8: bytes=32 time=54ms TTL=118 Reply from 8.8.8.8: bytes=32 time=44ms TTL=118 Reply from 8.8.8.8: bytes=32 time=74ms TTL=118 Reply from 8.8.8.8: bytes=32 time=49ms TTL=118 listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes 09:12:45.845368 IP 10.8.0.2 > 8.8.8.8: ICMP echo request, id 1, seq 342, length 40 09:12:45.898482 IP 8.8.8.8 > 10.8.0.2: ICMP echo reply, id 1, seq 342, length 40 09:12:46.855030 IP 10.8.0.2 > 8.8.8.8: ICMP echo request, id 1, seq 343, length 40 09:12:46.897867 IP 8.8.8.8 > 10.8.0.2: ICMP echo reply, id 1, seq 343, length 40 09:12:47.863619 IP 10.8.0.2 > 8.8.8.8: ICMP echo request, id 1, seq 344, length 40 09:12:47.936537 IP 8.8.8.8 > 10.8.0.2: ICMP echo reply, id 1, seq 344, length 40 09:12:48.867722 IP 10.8.0.2 > 8.8.8.8: ICMP echo request, id 1, seq 345, length 40 09:12:48.916388 IP 8.8.8.8 > 10.8.0.2: ICMP echo reply, id 1, seq 345, length 40
Poslední problém byl/je ten, že někde v dhcpcd.conf nebo dnsmasq.conf mi chybí konfigurace pro DNS (pro eth0). To jsem ale vyřešil ručním přídáním DNS v NTB, takže teď mi vše funguje tak jak má. Kdyby ještě někdo věděl jak to doladit k dokonalosti, budu rád (přidání dhcpcd.conf "static domain_name_servers=8.8.8.8" nepomohlo a cokoliv v "static routers" rozbilo fungování netu v RPi). Díky za radu a trpělivost.