OpenVPN a směrování provozu mezi tun0 a eth0

[ota karek]

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,12h
a 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 forever
Děkuji za radu/nasměrování.

[Reklama]

[_Jenda]

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.

[ota karek]

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.