Dotaz: Problém s routováním

[blondak]

Ahoj, mám problém s routerem, jedná se o router s RTL8186 a wive-ng firmwarem. Můj problém spočívá v tom, že mi nefunguje jako router (s NAT funguje)

    +------------+     +-----------+       +------------+     +-----------+
    |            |     |           |       | 10.0.1.31  |     |           |
    | 10.0.1.254 | === | 10.0.1.29 | ~air~ |  wive-ng   | =+= | 10.1.0.62 |
    |            |     |           |       | 10.1.0.252 |  |  |           |
    +------------+     +-----------+       +------------+  |  +-----------+
                                                           |
                                                           |  +-----------+
                                                           |  |           |
                                                           += | 10.1.0.65 |
                                                              |           |
                                                              +-----------+

Když zkusím pingnout z 10.1.0.65 na 10.0.1.254 (nebo zpět) tak to jde, ale například ping z/na 10.1.0.62, nejde, když se kouknu přes tcpdump na 10.0.1.254, tak vidím, že ICMP paket přijde a počítač odpoví.

[root@router root]# tcpdump -i eth2 icmp -n -c 4 -vv
tcpdump: listening on eth2
09:41:59.879945 10.1.0.62 > 10.0.1.254: icmp: echo request (DF) (ttl 63, id 0, len 84)
09:41:59.880287 10.0.1.254 > 10.1.0.62: icmp: echo reply (ttl 64, id 5307, len 84)
09:42:00.816393 10.0.1.254 > 10.0.1.31: icmp: echo request (DF) (ttl 64, id 0, len 84)
09:42:00.822241 10.0.1.31 > 10.0.1.254: icmp: echo reply (ttl 64, id 42074, len 84)

na 10.1.0.62

[root@fujitsu ~]# tcpdump -i eth0 icmp -n -vv -c 4
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:38:25.193017 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.1.0.62 > 10.0.1.254: ICMP echo request, id 20546, seq 259, length 64
09:38:26.195148 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.1.0.62 > 10.0.1.254: ICMP echo request, id 20546, seq 260, length 64
09:38:27.195413 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.1.0.62 > 10.0.1.254: ICMP echo request, id 20546, seq 261, length 64
09:38:28.194579 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.1.0.62 > 10.0.1.254: ICMP echo request, id 20546, seq 262, length 64
4 packets captured
4 packets received by filter
0 packets dropped by kernel

nastavení rout: na 10.1.0.0/24 mají nastavenou pouze default routu na 10.1.0.252 a 10.0.1.254 má nastaveno

    10.0.1.0/24 dev eth2  scope link
    10.1.0.0/24 via 10.0.1.31 dev eth2
    default via 62.240.xxx.xxx dev eth0

nastavení iptables na 10.0.1.31(10.1.0.252)

    [Wive-NG@/mnt/rw_fs/root]# iptables -t nat -L -n
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination         
    DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:8888 to:10.1.0.62:22

    Chain POSTROUTING (policy ACCEPT)
    target     prot opt source               destination         

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         

    [Wive-NG@/mnt/rw_fs/root]# iptables -t filter -L -n
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     47   --  0.0.0.0/0            0.0.0.0/0         
    ACCEPT     udp  --  0.0.0.0/0            255.255.255.255    udp dpts:67:68
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination       

    [Wive-NG@/mnt/rw_fs/root]# sysctl -a | grep "\.forwarding"
    net.ipv4.conf.br0.forwarding = 1
    net.ipv4.conf.wlan0.forwarding = 1
    net.ipv4.conf.lo.forwarding = 1
    net.ipv4.conf.default.forwarding = 1
    net.ipv4.conf.all.forwarding = 1

jediné co vidím na tom routeru je následující v /proc/net/ip_conntrack

[Wive-NG@/mnt/rw_fs/root]# cat /proc/net/ip_conntrack  | grep icmp
icmp     1 29 src=10.1.0.62 dst=10.0.1.254 type=8 code=0 id=20546 [UNREPLIED] src=10.0.1.254 dst=10.1.0.62 type=0 code=0 id=20546 use=2

netusíte, někdo, kde by se ty pakety mohly ztrácet, když router párkrát restartuji, tak třeba naskočí, ale např 1 z 20 pokusů.... už mi z toho vážně hrabe... díky za každé nakopmutí.

---

---

Odpovědi

[NN]

Podital bych na 1.254 jen default routu na 1.29. Nicmene kdyz si pingnes z 0.65 na 1.254 pak je routovani v poradku. Spise si to na 0.252 blokujes.

Vyzkousej traceroute, pripadne ping po jednotlivych skocich z obou stran a zjistis na kterem uzlu to vazne.

NN

[tomk]

Nelibi se mi 10.0.1.29 Co je to zac? To je nejake AP v rezimu client, ktere takhle dela bridge mezi ethernetem a WiFi? Nema v tomto rezimu nejaka omezeni?

Tomas

[blondak]

to je AP v režimu AP :) router je v režimu klient, zvláštní je, že že to občas jde. No zkouším zkompilovat tcpdump pro MIPS a zmenšit ho tak, aby se mi vešel do toho routeru :/ ale mohl bych zkusit na 10.0.1.254 zprovoznit pppoe a nahodit z 10.1.0.252 linku přímo na 10.0.1.254

[tomk]

At tak ci naopak, cekal bych ze prave v takovemto pouziti wifi budou problemy s pristupem vice klientu. Jak vypada arp tabulka na 10.0.1.254? Ci MAC adresy se to uci? Chova se to tak, ze kdyz to obcas jde z 10.1.0.65, tak to nejde z 10.1.0.62 a naopak? Co pingat z 10.1.0.62 a tcpdumpem se divat i na 10.1.0.65? Vzhledem k tomu, ze v te topologii je momentalne jen jeden router a vsem tedy staci mit nastaveno default gw na nej, smerovani je trivialni, hledal bych proste problem spis v te wifi siti.

Tomas

[blondak]

ano vypadá to tak, že když jde jeden tak nejde druhý, když koukám na routeru do /proc/net/arp tak jsou tam správné záznamy, divné je, že ping dojde z toho počítače co nejde až na 10.0.1.254 a ten mu odpoví. Bohužel nevím, jak sledovat pakety na tom 10.1.0.252, tcpdump je moooc velký :( ještě zkusím protunelovat spojení přímo z 10.0.1.31 na 10.0.1.254 přes PPTP (vyloučím tím chybu v tom AP 10.0.1.29)

[blondak]

tak to opravdu kur.... ten 10.0.1.29 .... (přes PPTP to jede bez problémů) díky všem

[Filip Jirsák]

Na tom routeru vám chybí nastavit napevno routu na 10.0.1.254 přes 10.0.1.29, podobně na 10.0.1.254 vám chybí routa na 10.0.1.0/24 přes 10.0.1.29. A nebo by se 10.0.1.29 musel chovat jako bridge. Doporučuju třetí řešení – 10.0.1.254 přesunout do jiné (IP) sítě (a přidat příslušný interface k 10.0.1.29), takže 10.0.1.29 by dělal router mezi sítí 10.0.1.0/24 a touto novou sítí. Ušetříte si tím spoustu problémů.

[blondak]

hmm, tak to budu muset do toho 10.0.1.29 hodit jinej firmware :/ protože tenhle je divnej a neumí to. Tak jsem teď zjistil, že když to nejde, tak nejde ani ping z 10.1.0.65 na 10.0.1.31

[NN]

A jses si jisty, ze to spojeni vzduchem je stabilni?

NN

[Filip Jirsák]

A co je to 10.0.1.29 zač? Podle obrázku předpokládám, že to má dvě rozhraní (WiFi a ethernet), tak prostě na každém nastavíte jinou IP adresu.

[blondak]

to je nějaký AP ( zcomax 2204TX, bohužel s výchozím SW značně omezené možnosti) a neměl jsem čas tam ladi nějaký jiný fw. Problém, jak to tak vypadá opravdu způsboval on, po tom co jsem spustil pptp přímo mezi 10.0.1.31 a 10.0.1.254 a nastavil směrování 10.1.0.0/24 přes ten tunel to všechno jede tak jak má.