Eltűnő csomagok a routingban

Linux-haladó

Eltűnő csomagok a routingban

  • 768 megtekintés

( nla | 2005. 11. 28., h – 10:37 )

A routing dontes es az INPUT tabla nem fugg ossze.

Ha a gépnek címzett csomag jön, akkor tudtommal a sorrend: PREROUTING -> routing döntés -> INPUT
Ilyen módon összefügg a dolog.
A forrás egyébként egy külső cím magas (40000 feletti) portról. Célcím (dsl router port forwardja után) 192.168.15.2 port pl. 22, de 80 sem megy.
Tűzfal ip címei: 192.168.1.1, 192.168.2.1, 192.168.4.2, 192.168.15.2
Iptables konfig a következő:
[code:1:4623697592]Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
957 109K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 icmpk icmp -- * * 0.0.0.0/0 0.0.0.0/0
12593 4358K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tproxy
15742 3763K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 40 DROPINVALID all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 DROPINVALID tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02
4 216 LOinter all -- eth1 * 0.0.0.0/0 0.0.0.0/0
0 0 LOinter all -- eth2 * 0.0.0.0/0 0.0.0.0/0
91 16795 LOintra all -- eth0 * 192.168.2.0/24 0.0.0.0/0
16 1070 LOdmz all -- eth0 * 192.168.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tap+ * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `INPUT DROP: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 10.0.0.0/8
2766 323K ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tap+ * 0.0.0.0/0 0.0.0.0/0
3143 1830K ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * tap+ 0.0.0.0/0 0.0.0.0/0
1 76 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FORWARD DROP: '
1 76 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 29999 packets, 10M bytes)
pkts bytes target prot opt in out source destination

Chain DROPINVALID (2 references)
pkts bytes target prot opt in out source destination
1 40 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `INVALID packet: '
1 40 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain LOdmz (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 192.168.1.0/24 192.168.1.1 tcp spts:1024:65535 dpt:25
0 0 ACCEPT udp -- * * 192.168.1.0/24 192.168.1.1 udp spts:1024:65535 dpt:123
0 0 ACCEPT udp -- * * 192.168.1.0/24 192.168.1.1 udp spt:123 dpt:123
16 1070 ACCEPT udp -- * * 192.168.1.0/24 192.168.1.1 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 192.168.1.0/24 192.168.1.1 tcp spts:1024:65535 dpt:514
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `LOdmz DROP: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain LOinter (2 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:22
4 216 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:25
0 0 ACCEPT udp -- * * 148.6.0.1 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `LOinter DROP: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain LOintra (1 references)
pkts bytes target prot opt in out source destination
1 60 ACCEPT tcp -- * * 192.168.2.200 0.0.0.0/0 tcp spts:1024:65535 dpt:25
0 0 ACCEPT tcp -- * * 192.168.2.201 0.0.0.0/0 tcp spts:1024:65535 dpt:25
4 284 ACCEPT udp -- * * 192.168.2.200 0.0.0.0/0 udp spt:53 dpt:53
0 0 ACCEPT udp -- * * 192.168.2.201 0.0.0.0/0 udp spt:53 dpt:53
0 0 ACCEPT udp -- * * 192.168.2.200 0.0.0.0/0 udp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 192.168.2.201 0.0.0.0/0 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 192.168.2.200 0.0.0.0/0 tcp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 192.168.2.201 0.0.0.0/0 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 192.168.2.200 0.0.0.0/0 udp spts:1024:65535 dpt:123
0 0 ACCEPT udp -- * * 192.168.2.201 0.0.0.0/0 udp spts:1024:65535 dpt:123
2 152 ACCEPT udp -- * * 192.168.2.200 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT udp -- * * 192.168.2.201 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT tcp -- * * 192.168.2.0/24 0.0.0.0/0 tcp dpt:22
84 16299 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `LOintra DROP: '
84 16299 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain LOvpn (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `LOvpn DROP: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain icmpk (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 12
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 4
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `Icmpk DROP: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain tproxy (0 references)
pkts bytes target prot opt in out source destination[/code:1:4623697592]

( nla | 2005. 11. 29., k – 10:16 )

Ha be van kapcsolva az rp_filter, ha nincs, akkor is ugyanaz a helyzet, mint amit korábban felvázoltam.

( nla | 2005. 11. 25., p – 10:13 )

Adva van egy tűzfal a "távolban" a következő interface-ekkel:

eth0: Belső hálózat
eth1: Kapcsolat "T" ADSL szolgáltató felé (lassabb)
eth2: Kapcsolat "P" ADSL szolgáltató felé (gyorsabb)

A külső kapcsolatok előtt van egy-egy ADSL router ami a szükséges portokat (80, 443, 1194, ...) továbbítja a tűzfal felé.
Az eth1-en van jelenleg egy vpn (openvpn) kapcsolat hozzánk amit szerettünk volna átrakni eth2-re. A gondok ezután jöttek.
Megfelelő konfigurálás után sem ment semmi. Hosszas kutakodás után a következő információim vannak:
- A két ADSL router megfelelően működik, portokat továbbítja befelé.
- Ha a két interface-ben meg van cserélve a kábel és át van konfigurálva, akkor is az eth2 nem megy, tehát tudjuk használni "P"-t az eth1-en, de az eth2-n a másikat nem.
- Az eth2 ezelőtt működött DMZ-ként.
- kernel: 2.4.24-zorpos

Most jön az érdekesebbje!
- Az iptables-ben mindkét interface-re ugyanazon szabályok vonatkoznak és azok természetesen értelmezhetőek mindkettőre.
- Az eth2-n log alapján megjelenik a tűzfalnak szánt csomag a PREROUTING-ban, végig is megy rajta, de az INPUT-ban már nem jelenik meg. Ebből következik, hogy válasz sem generálódik rá.
- Eldobva nincs a csomag, az logolásra kerülne.

Úgy tűnik, mintha a routingban tűnne el a csomag, de a routing tábla jó bejegyzéseket tartalmaz.

Ha valaki találkozott már hasonlóval vagy van valami ötlete akkor legyen szíves ossza meg!

Köszi!

( Névtelen (nem ellenőrzött) | 2005. 11. 25., p – 11:16 )

[quote:818c14a5bd="nla"]
- Az eth2-n log alapján megjelenik a tűzfalnak szánt csomag a PREROUTING-ban, végig is megy rajta, de az INPUT-ban már nem jelenik meg. Ebből következik, hogy válasz sem generálódik rá.
- Eldobva nincs a csomag, az logolásra kerülne.
Úgy tűnik, mintha a routingban tűnne el a csomag, de a routing tábla jó bejegyzéseket tartalmaz.

A prerouting-ból a forward láncra is kerülhet a csomag nem csak az inputra.
Egy nat szabály is bekavarhat (ha van), mert az is "megelőzi" az input és a forward
láncot..
Ismered: http://iptables-tutorial.frozentux.net/iptables-tutorial.html?
Fri

( wildy | 2005. 11. 28., h – 15:57 )

Tovabbi megnezendo: az rp_filter be van-e kapcsolva? Zorp eseten celszeru kikapcsolni. Ha mar az INPUT-ig sem jut el a csomag, akkor erre gyanakszom.

( nla | 2005. 11. 25., p – 12:00 )

[quote:de6214dcf8="Frimen"]
A prerouting-ból a forward láncra is kerülhet a csomag nem csak az inputra.
Egy nat szabály is bekavarhat (ha van), mert az is "megelőzi" az input és a forward
láncot..

A FORWARD láncba nem kerül be (ezt is logolom egyébként), mert a tűzfal a címzett. Ekkor az INPUT-ban kellene megjelennie.
A nat nem kavarhat be mivel így néz ki:
[code:1:de6214dcf8]
*nat
:PREROUTING ACCEPT [23986:2511199]
:POSTROUTING ACCEPT [36316:2266300]
:OUTPUT ACCEPT [0:0]
COMMIT
[/code:1:de6214dcf8]
[quote:de6214dcf8="Frimen"]
Ismered: http://iptables-tutorial.frozentux.net/iptables-tutorial.html?
Fri

Ismerem, nagyon jó és hasznos doksi.

Amúgy szerintem valami kernel szinten nem OK, de ami konfigot eddig megnéztem az egyezett a működőkkel.

( wildy | 2005. 11. 29., k – 14:44 )

Kikapcsolt rp_filter eseteben mindenkeppen el kellene jutni a csomagnak vagy az INPUT vagy a FORWARD lancra (hacsak a nat tabla PREROUTING-jaban nincs pl. DNAT-olva). Nem nagyon van mas tippem, probalj kernelt (es foleg tproxy-t) frissiteni, ha teheted.

( nla | 2005. 11. 29., k – 14:50 )

Ez lesz a következő, de a tűzfal több mint 200 km-re van és a közeljövőben nem tudom mikor leszek a közelében. A fejleményekről majd beszámolok.

( wildy | 2005. 11. 25., p – 13:21 )

Zorpos kernel? Nezd meg a tproxy tablat is, hatha ott tortenik valami a csomagokkal. Egyebkent roppant keves informaciot adtal meg, igy nem nagyon lehet segiteni.

( nla | 2005. 11. 25., p – 13:35 )

[quote:fe05c083b9="wildy"]Zorpos kernel? Nezd meg a tproxy tablat is, hatha ott tortenik valami a csomagokkal.

A tproxy táblán sikeresen túljut a csomag, annak is a PREROUTING láncán. Ezzel nincs gond. Ezután jön a routing döntés és ez alapján be kellene kerülnie az INPUT láncba. Ez utóbbi már nem történik meg.
[quote:fe05c083b9="wildy"]Egyebkent roppant keves informaciot adtal meg, igy nem nagyon lehet segiteni.

Mond, hogy mire van sükség és beírom!

( wildy | 2005. 11. 25., p – 15:28 )

A tproxy táblán sikeresen túljut a csomag, annak is a PREROUTING láncán. Ezzel nincs gond. Ezután jön a routing döntés és ez alapján be kellene kerülnie az INPUT láncba. Ez utóbbi már nem történik meg.

A routing dontes es az INPUT tabla nem fugg ossze. Akkor kerul az INPUT-ra, ha a gep vmelyik IP-cimere erkezik a csomag. Jol jonne olyan info, hogy:
1. forras IP-cim, port
2. cel IP-cim, port
3. iptables konfig (-t tproxy, -t nat, -t filter), ertelemszeruen anonimizalva, azaz a publikus IP-cimek spoof-olva, -v parameter legyen az iptables-nek megadva
4. a tuzfal IP-cimei (hatha a FORWARD-on kot ki)