classic.ISPforum.cz

Prosím o pomoc
mám následující konfiguraci: zbytek sítě - RB450G (router) - rocket M5 (AP) - nanobridge 5(klient) - asus WL500 (uživatel)
Rocket M5 je v režimu bridge, AP. IP adresu získává z dhcp z RB450G, stejně jako klient a uživatel - včetně default gw.
Z RB450G se dá pingnout na rocket M5.
Nemůžu ale pingnout ani se dostat přes web rozhraní na rocket M5 odnikud ze zbytku sítě. rocket ale funguje, provoz přes něj jede, dostanu se do něj sshčkem z RB450g.
Nevím, jestli to může mít spojitost, ale do rocketu se dalo dostat dokud jsem nepřipojil uživatele. poté už se mi to nepovedlo.
Na nanobridge 5 a wl500 se dostanu bez problémů. FV5.5.2 na rocketu i nanobridge
Jedná se o první nasazený ubnt, určitě něco přehlížím, prosím o nasměrování. díky

- máš tam špatně nastavenou bránu,
- Subnet té rockety nemáš dobře naroutován
....

upřesním to:
rb450g je pro ten subnet dhcp serverem. Adresu z tohoto(stejného) dhcp serveru dostává rocket, nanobridge i uživatel. Na nanobridge a uživatele se dostanu, na rocket ne.
Napadá mě, že toho rocketa resetnu do továru a zkusím znovu nastavit - nepomohlo to.

Nemáš tu IP té rockety někde znova třeba zapomenutou na stole z nějakých testů nebo konfigurací? Když na ní vlezeš, tak se mimo ten její subnet dopingáš? Třeba z tools nebo s konzole.

Na rocketa lezu tak, že si udělám mezi mikrotiky EoIP tunel až do lanky a nahodím si na lokále IP adresu z rozsahu toho patřičného subnetu (172.17.20.0/26)
Z rocketa 172.17.20.2 se nedopingám nikam dál, než na ten první router (RB450G).
Chápu, že by to mělo být nenastavenou default gatewaí, ale ta tam nastavená je (172.17.20.1).
Dnes už jsem to byl zkusit natvrdo vypnout a zapnout - nepomohlo.
Včera jsem z AP - Bridge udělal na chvíli AP - router. LAN si ip z dhcp serveru převzala, ale nedalo se na ni opět dostat.
nejvíc mě zaráží, že se tam po instalaci dalo na dálku dostat, dokonce jsem jednou sáhl na regulaci výkonu a od té doby se na rocketa nemůžu dostat.
Nepomohlo ani reset do továru a znovu nastavení AP - Bridge.

ještě mě napadá,
zkus na ten subnet nastavit masku /24 Už nevím u čeho to bylo, ale nějaké zařízení s tím mělo problém když, jsem po něm chtěl menší síť nežli C rozsah.

Ani u jednoho UBNT nemám /24, vždy menší. /26 u sektorů, /29 nebo /30 u nanobridgů.

lvacek píše:ještě mě napadá,
zkus na ten subnet nastavit masku /24 Už nevím u čeho to bylo, ale nějaké zařízení s tím mělo problém když, jsem po něm chtěl menší síť nežli C rozsah.

Obecně mi tvůj problém zní jako někde zapomenuté pravidlo ve firewallu.
Ale asi neublížíš, když na toho rocketa vlezeš sshčkem a dáš sem výpis příkazů "ip addr" a "ip ro". A pro jistotu i "iptables -vL"

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP q
len 1000
link/ether 00:27:22:81:22:95 brd ff:ff:ff:ff:ff:ff
inet6 fe80::227:22ff:fe81:2295/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 02:27:22:81:22:95 brd ff:ff:ff:ff:ff:ff
4: wifi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2286 qdisc ath_wme state UNKNOWN qlen 2000
link/ether 00:27:22:80:22:95 brd ff:ff:ff:ff:ff:ff
5: ath0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:27:22:80:22:95 brd ff:ff:ff:ff:ff:ff
inet6 fe80::227:22ff:fe80:2295/64 scope link
valid_lft forever preferred_lft forever
6: br0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 00:27:22:80:22:95 brd ff:ff:ff:ff:ff:ff
inet 172.17.20.2/26 brd 172.17.20.63 scope global br0

XM.v5.5.2# ip ro
172.17.20.0/26 dev br0 proto kernel scope link src 172.17.20.2
default via 172.17.20.1 dev br0

XM.v5.5.2# iptables -vL
iptables v1.4.0: can't initialize iptables table `filter': iptables who? (do you need to insmod?
)

Perhaps iptables or your kernel needs to be upgraded.

Fajn.

Takže ze "zbytek sítě" nejde ping na Rocket, ale na Klient ano?

Zkus ještě něco, na rocketu "tcpdump -i br0 icmp" A sleduj výpis, když pingáš na toho klienta. A pak když na rocketa ... Pro všechny případy se podívej ještě na "brctl show" (musí tam být všechny interfacy) a klidně i "tcpdump -i eth0 icmp".
Vsadím boty, že ten ping na rocketa nepřijde ... že ho sežere routerboard.

pro zajímavost - pingy z rocketa do jiné sítě projdou, pokud je to rozhraní na tom nejbližším RB450G

XM.v5.5.2# ping 172.17.20.249
PING 172.17.20.249 (172.17.20.249): 56 data bytes
64 bytes from 172.17.20.249: seq=0 ttl=64 time=1.324 ms
64 bytes from 172.17.20.249: seq=1 ttl=64 time=0.308 ms
64 bytes from 172.17.20.249: seq=2 ttl=64 time=0.436 ms
^C
--- 172.17.20.249 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.308/0.689/1.324 ms
XM.v5.5.2# ping 172.17.20.250
PING 172.17.20.250 (172.17.20.250): 56 data bytes
^C
--- 172.17.20.250 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
XM.v5.5.2# ping 172.17.20.251
PING 172.17.20.251 (172.17.20.251): 56 data bytes
^C
--- 172.17.20.251 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
XM.v5.5.2# ping 172.17.20.252
PING 172.17.20.252 (172.17.20.252): 56 data bytes
^C
--- 172.17.20.252 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
XM.v5.5.

172.17.20.249 je ten RB450g, ke kterému je rocket připojen (jiné jeho eth rozhraní)
------------
XM.v5.5.2# brctl show
bridge name bridge id STP enabled interfaces
br0 ffff.002722802295 no eth0
ath0
XM.v5.5.2#
---------------

XM.v5.5.2# tcpdump -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
^C07:29:14.901136 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20149, seq 1, length 64

1 packets captured
66 packets received by filter
25 packets dropped by kernel
XM.v5.5.2#


tady jsem poslal "ze zbytku sítě" (ze svého pc) 22 pingů na klienta.
--- 172.17.20.58 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21032ms
rtt min/avg/max/mdev = 3.208/4.087/6.823/0.990 ms
poté co na rocketu jsem dal ctrlC, trvalo ještě asi minutu, než se příkaz tcpdump ukončil

a toto je výstup, když jsem pingal na rocketa (172.17.20.2):
ping 172.17.20.2
PING 172.17.20.2 (172.17.20.2) 56(84) bytes of data.
^C
--- 172.17.20.2 ping statistics ---
49 packets transmitted, 0 received, 100% packet loss, time 47996ms

# tcpdump -i br0 icmp -vv
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
^C07:36:07.509978 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto ICMP (1), length 38) ipa2.
gw.kohra.cz > 172.17.20.58: ICMP echo request, id 17924, seq 1, length 18

1 packets captured
22 packets received by filter
0 packets dropped by kernel
XM.v5.5.2#
ipa2.gw.kohra.cz je monitoring

-------
pro porovnání - takto se na tcpdump chová klient 172.17.20.58:
--- 172.17.20.58 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 3.553/4.116/4.652/0.389 ms

XM.v5.5.2# tcpdump -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
19:03:35.184467 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20773, seq 1, length 64
19:03:35.341126 IP 172.17.20.58 > 172.17.10.70: ICMP echo reply, id 20773, seq 1, length 64
19:03:36.185143 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20773, seq 2, length 64
19:03:36.185461 IP 172.17.20.58 > 172.17.10.70: ICMP echo reply, id 20773, seq 2, length 64
19:03:37.187063 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20773, seq 3, length 64
19:03:37.187211 IP 172.17.20.58 > 172.17.10.70: ICMP echo reply, id 20773, seq 3, length 64
19:03:38.187824 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20773, seq 4, length 64
19:03:38.188108 IP 172.17.20.58 > 172.17.10.70: ICMP echo reply, id 20773, seq 4, length 64
19:03:39.189187 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20773, seq 5, length 64
19:03:39.189336 IP 172.17.20.58 > 172.17.10.70: ICMP echo reply, id 20773, seq 5, length 64
19:03:40.190891 IP 172.17.10.70 > 172.17.20.58: ICMP echo request, id 20773, seq 6, length 64
19:03:40.191040 IP 172.17.20.58 > 172.17.10.70: ICMP echo reply, id 20773, seq 6, length 64
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel

na ctrlC reaguje okamžitě
nechápu

To není zajímavost. Stále se motáme v kruhu - na RB450 je nějak zablokovaný forward IP adresy toho rocketu. Tahle "zajímavost" je pro něj totiž INPUT.

radekpv píše:pro zajímavost - pingy z rocketa do jiné sítě projdou, pokud je to rozhraní na tom nejbližším RB450G

Z rocketa pingáš na nanobridge a uživatele?

ludvik píše:To není zajímavost. Stále se motáme v kruhu - na RB450 je nějak zablokovaný forward IP adresy toho rocketu. Tahle "zajímavost" je pro něj totiž INPUT.

Omlouvám se všem, jsem ....... (doplňte si prosím sami) a sypu si popel na hlavu - ispadmin nasypal pravidla do firewalu RBčka po připojení prvního člověka a rocket tam nebyl povolený:-( Ještě jednou se omlouvám a děkuji za pomoc.