iBank kliens router gép mögött

Linux-haladó

Sziasztok

Windows kliensről fut egy iBank kliensprogram, amellyel utalásokat lehet végezni, számlaegyenleget lekérni, stb. Ezt a gépet egy linuxos gép köti össze a nettel.

A problémám abból áll, hogy amikor közvetlenül kötöm a windows-os gépet az ADSL-netre, az iBank program tökéletesen működik, míg amikor a linuxos gépen keresztül kell ugyanezt a kapcsolatot létrehozni, hibát kapok (a program szerint a hálózat túlterhelt).

Az iptables-sorok így néznek ki:
- prerouting
Kód:
iptables -t nat -A PREROUTING -i ppp0 -s 62.77.229.87 -d $adsl_IP -p tcp --sport 80 -j DNAT --to 192.168.1.2

- forward
Kód:
iptables -A FORWARD -i eth0 -o ppp0 -d 62.77.229.87 -j ACCEPT
iptables -A FORWARD -i ppp0 -o eth0 -s 62.77.229.87 -j ACCEPT

iptables -A FORWARD -i eth0 -s $belso_halo -o ppp0 -d 62.77.229.87 -p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp0 -s 62.77.229.87 -o eth0 -d $belso_halo -p tcp --sport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT

A szabályok működnek, tehát ezzel elvileg nem lenne gond. Ha viszont megnézem az Ethereal segítségével, a következőt látom:
Kód:
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.2 62.77.229.87 TCP 1214 > http [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: 192.168.1.2 (00:c0:f0:57:39:be), Dst: 192.168.1.1 (00:0a:0d:d4:91:9c)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 62.77.229.87 (62.77.229.87)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0xc3e2 (50146)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x5196 [correct]
Source: 192.168.1.2 (192.168.1.2)
Destination: 62.77.229.87 (62.77.229.87)
Transmission Control Protocol, Src Port: 1214 (1214), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0

No. Time Source Destination Protocol Info
2 0.037540 62.77.229.87 192.168.1.2 TCP http > 1214 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 192.168.1.1 (00:0a:0d:d4:91:9c), Dst: 192.168.1.2 (00:c0:f0:57:39:be)
Internet Protocol, Src: 62.77.229.87 (62.77.229.87), Dst: 192.168.1.2 (192.168.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 44
Identification: 0xca1c (51740)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 123
Protocol: TCP (0x06)
Header checksum: 0x5060 [correct]
Source: 62.77.229.87 (62.77.229.87)
Destination: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1214 (1214), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
3 0.038379 192.168.1.2 62.77.229.87 TCP 1214 > http [ACK] Seq=1 Ack=1 Win=17520 Len=0

Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: 192.168.1.2 (00:c0:f0:57:39:be), Dst: 192.168.1.1 (00:0a:0d:d4:91:9c)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 62.77.229.87 (62.77.229.87)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0xc3e3 (50147)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x519d [correct]
Source: 192.168.1.2 (192.168.1.2)
Destination: 62.77.229.87 (62.77.229.87)
Transmission Control Protocol, Src Port: 1214 (1214), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
4 0.105231 192.168.1.2 62.77.229.87 HTTP Continuation or non-HTTP traffic

Frame 4 (849 bytes on wire, 849 bytes captured)
Ethernet II, Src: 192.168.1.2 (00:c0:f0:57:39:be), Dst: 192.168.1.1 (00:0a:0d:d4:91:9c)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 62.77.229.87 (62.77.229.87)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 835
Identification: 0xc3e4 (50148)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0x4e81 [correct]
Source: 192.168.1.2 (192.168.1.2)
Destination: 62.77.229.87 (62.77.229.87)
Transmission Control Protocol, Src Port: 1214 (1214), Dst Port: http (80), Seq: 1, Ack: 1, Len: 795
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
5 0.241642 62.77.229.87 192.168.1.2 HTTP Continuation or non-HTTP traffic

Frame 5 (494 bytes on wire, 494 bytes captured)
Ethernet II, Src: 192.168.1.1 (00:0a:0d:d4:91:9c), Dst: 192.168.1.2 (00:c0:f0:57:39:be)
Internet Protocol, Src: 62.77.229.87 (62.77.229.87), Dst: 192.168.1.2 (192.168.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 480
Identification: 0xdc1c (56348)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 123
Protocol: TCP (0x06)
Header checksum: 0x3cac [correct]
Source: 62.77.229.87 (62.77.229.87)
Destination: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1214 (1214), Seq: 1, Ack: 796, Len: 440
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
6 0.324092 62.77.229.87 192.168.1.2 HTTP [TCP Previous segment lost] Continuation or non-HTTP traffic

Frame 6 (215 bytes on wire, 215 bytes captured)
Ethernet II, Src: 192.168.1.1 (00:0a:0d:d4:91:9c), Dst: 192.168.1.2 (00:c0:f0:57:39:be)
Internet Protocol, Src: 62.77.229.87 (62.77.229.87), Dst: 192.168.1.2 (192.168.1.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 201
Identification: 0xe41c (58396)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 123
Protocol: TCP (0x06)
Header checksum: 0x35c3 [correct]
Source: 62.77.229.87 (62.77.229.87)
Destination: 192.168.1.2 (192.168.1.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1214 (1214), Seq: 1901, Ack: 796, Len: 161
Hypertext Transfer Protocol

Ami furcsa, hogy nem fragmentált csomagokról van szó, tehát ez nem lehet probléma. A másik, hogy minden esetben a fentiekben logolt lépések történnek:
1-2-3. a belső gép létrehozza a kapcsolatot a bank gépével;
4. a belső hálón lógó gép lekér egy csomagot a bank 80-as portjáról;
5. a banki szerver elküldi a csomagot a belső gépnek;
6. kiderül, hogy a banki szerver által küldött csomag elvész.

(Ezután a gépek szépen elbontják a kapcsolatot ahogy kell)

Kérdéseim:
- van-e valaki, aki használja az iBank nevű programot hasonló kiépítettséggel (Windows kliens, linuxos routergépen tűzfallal)?
- lát-e valaki beállítási problémát az iptables-parancsokban?

Köszönöm

  • 2910 megtekintés

( shusaku | 2006. 02. 07., k – 12:44 )

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Kifelé megy, befelé nem jön :-(

Ezért van az iptables-szabályok között egy olyan, amelyik a bank szerverétől a 80-as indulási portról jövő kapcsolatokat forwardolja a belső gép felé (ez a prerouting), s mint ilyen, a gépen átmenő kapcsolat, engedélyezve van a 80-as portról jövő kapcsolat befelé a gép felé (s persze kifelé is).

( styg v | 2006. 02. 07., k – 14:00 )

Csak a pontosság kedvéért: iBanq.exe.

Én qemu-ban futó Windows-zal használom. Amíg kevés volt számára a memória (512 MB), addig produkált ilyet minden 3. kattintásra.
A bővítés óta simán megy.

Persze én közvetlenül a netre vagyok dugva.

Nekem per pillanat mindegy, minek hívjuk :-)
Mint írtam, "rendes" Windows alatt vagyok kénytelen használni, ahol egész jól elvan a 192MB-os géppel, s ha közvetlenül van a gép a netre dugva, akkor tényleg nem csinál ilyen problémákat.

A gond onnan indul, hogy nem raknám az utalós gépet közvetlenül a netre, s nem látom, mit enged/nem enged az iptables. Hiába logolom az összes kapcsolatot az adott szerver felé, nem látok problémát. Csak az Ethereal jelez, s igaza is van, de nem tudom a megoldást, miért veszíti el a visszajövő csomagot.

OK, tudok róla, továbbá kb. 1 éve kerestek is Java-fejlesztőt.
Természetesen a probléma megkerülése is egy megoldás, de
1. más ok miatt viszont éppen őt választotta a cég (és én is);
2. a kérdés marad, hogyan tudnám megtalálni, miért nem ér vissza az adott csomag?

Tovább görgetve a kérdést, valljuk be őszintén legalább önmagunknak, kicsit fura lenne minden probléma esetén áthárítani a felelősséget azért, mert MI nem tudjuk megoldani az adott feladatot. Ugyanis akkor ez nem megoldás, hanem struccpolitika, én meg egyenesen utálom, ha por megy a pofámba :-D

( Polesz v | 2006. 02. 07., k – 14:45 )

iptables -t nat -A PREROUTING -i ppp0 -s 62.77.229.87 -d $adsl_IP -p tcp --sport 80 -j DNAT --to 192.168.1.2

sport helyett dport? mert nem a forrását, hanem a célját akarod meghatározni, bár lehet baromság amit mondok :-)

--
Slackware current mert az nekem jó...

Azt mondom neki, hogy ha bejön az adsl-csatolón egy tcp-csomag a 62.77.229.87-es IP-ről az adsl-hez tartozó IP-re, amelynek kiindulási portja a 80-as port, akkor a kapcsolatot/csomagot a beérkezés előtt "dobja tovább"/forwardolja a 192.168.1.2-es gépre.
Az --sport jó, mert a szerver erre a portra kapja és innen indítja a kapcsolatait, a belső hálón meg oda érkezik, ahova érkezik (1024 és felette bárhová).

Ethernet II, Src: 192.168.1.1 (00:0a:0d:d4:91:9c), Dst: 192.168.1.2 (00:c0:f0:57:39:be)
Internet Protocol, Src: 62.77.229.87 (62.77.229.87), Dst: 192.168.1.2 (192.168.1.2)

Ebből láthatod, a banki szerver tökéletesen elbeszélget a belső hálós géppel, mégis elvész egy csomag :-(
Asszem este netfilter-mozit fogok nézni a dvd-n...

Visszajöttem szabiról és találtam egy olyan megoldást, amely még a csomag útválasztása előtt megjelöli az adott kapcsolatot. Így minden, az adott kapcsolathoz tartozó csomag kap egy jelzést (kb. mint a logban a --log-prefix kinézete), amelyből látható, mikor és melyik szabályon ment át vagy éppen nem ment át az adott csomag.
Holnapra pontosan megkeresem, hátha kellhet még valakinek.

Gondoltam a pathmtu-ra is, de azt hiszem, első körben megpróbálkozom ezzel a MARK-olással. Elvégre ha mégis valamelyik szabályban elakad a csomag, akkor először azt szeretném kiküszöbölni.
A tippet viszont köszönöm.

Sandokan69-nek jó volt az ötlete, csak rossz helyen kerestem a problémát.

A történet ugyanis úgy szól, hogy az ADSL a 1452-es MTU-val működik, amiről viszont a belső hálón lógó Windows-gép nem tud és 1500-as (1492) méretű csomagokat próbál áttolni a linuxos gépen. Naná, hogy nem fog neki sikerülni.

Megoldás: a registry-ben megadni a Windows-os gépen, hogy az MTU-ja jóval kevesebb legyen (én pl. 1452), így könnyedén átmegy a linxuos gép 1452-es ADSL-én (aki tutira akar menni, gondolom leveheti 1412-re is :-))