WLAN Router hinter debian Router ansprechen

Anfänger

26.03.2008, 10:12

Hallo, ich muss vorwegnehmen, dass ich von debian, bzw. Linux generell sehr wenig Ahnung habe und mir das meiste über google zusammenkleistere.

Mein Problem ist folgendes:
Wir haben ein Firmennetz 192.168.0.0 /24 in dem alle unsere Server usw. stehen.
Da wir immer wieder Probleme hatten, wenn fremde Rechner bei uns ins Netz gehen und diese noch ihre LAN IPs drin haben und dadurch doppelte IP Vergabe auftrat, haben wir einen debian Router aufgesetzt, der ein eigenes Netz nur für Kundenrechner darstellt. (172.16.0.0 /27)
Aus diesem Netz wird in das bestehende Firmennetz geroutet.

Jetzt haben wir einen WLAN Router aufgestellt, bei dem aber lediglich die LAN & WLAN Funktionen genutzt werden.
Dieser WLAN Router ist im 172er Netz, soll aber auch aus dem 192er Netz angesprochen werden können.

Ich habe das Gerät soweit vorkonfiguriert (172.16.0.29) und kann es auch vom bestehenden Router aus anpingen.
Das genutzt Routing Tool ist iptables und ich habe auch schonmal ein paar Befehle reingehauen, allerdings ohne gewünschten Erfolg.
Hier einmal iptables -L , evtl. hilft das weiter. (Das ist denk ich auch schon gut zugemüllt)

Quellcode

iptables -A PREROUTING -t nat -i eth1 -p tcp --dport 80 -j DNAT --to 172.16.0.29:80
iptables -A INPUT -p tcp -m state --state NEW --dport 80 -i eth0 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp -i eth1 --dport 80 -j DNAT --to 172.16.0.29:80 

iptables -A FORWARD -p tcp -i eth1 -d 172.16.0.29 --dport 80 -j ACCEPT






iptables -A FORWARD -i eth1 -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -i eth1 --dport 80 -j DNAT --to 172.16.0.29


iptables -A FORWARD -i eth0 -o eth1 -d 172.16.0.29 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.16.0.29

iptables -A FORWARD -i $EXTIF -o $INTIF -d 172.16.0.29 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i $EXTIF -d $EXTIP -p tcp --dport 80 -j DNAT --to 172.16.0.29

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
LOG        all  --  127.0.0.0/8          anywhere            LOG level warning
DROP       all  --  127.0.0.0/8          anywhere
ACCEPT     all  --  anywhere             255.255.255.255
ACCEPT     all  --  172.16.0.0/27        anywhere
ACCEPT    !tcp  --  anywhere             BASE-ADDRESS.MCAST.NET/4
LOG        all  --  172.16.0.0/27        anywhere            LOG level warning
DROP       all  --  172.16.0.0/27        anywhere
ACCEPT     all  --  anywhere             255.255.255.255
ACCEPT     all  --  anywhere             192.168.0.79
ACCEPT     all  --  anywhere             192.168.0.255
LOG        all  --  anywhere             anywhere            LOG level warning
DROP       all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:www
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:www
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:www

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  172.16.0.0/27        anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
LOG        all  --  anywhere             172.16.0.0/27       LOG level warning
DROP       all  --  anywhere             172.16.0.0/27
LOG        all  --  anywhere             anywhere            LOG level warning
DROP       all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             172.16.0.29         tcp dpt:www
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:www
ACCEPT     tcp  --  anywhere             172.16.0.29         tcp dpt:www
ACCEPT     tcp  --  anywhere             172.16.0.29         tcp dpt:www
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             255.255.255.255
ACCEPT     all  --  anywhere             172.16.0.0/27
ACCEPT    !tcp  --  anywhere             BASE-ADDRESS.MCAST.NET/4
LOG        all  --  anywhere             172.16.0.0/27       LOG level warning
DROP       all  --  anywhere             172.16.0.0/27
ACCEPT     all  --  anywhere             255.255.255.255
ACCEPT     all  --  192.168.0.79         anywhere
ACCEPT     all  --  192.168.0.255        anywhere
LOG        all  --  anywhere             anywhere            LOG level warning
DROP       all  --  anywhere             anywhere

Für Lösungsvorschläge wäre ich sehr dankbar.

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

2

27.03.2008, 14:17

mal ne bloede frage, weil das nicht ganz ersichtlich ist, das WLAN Teil forwarded die Requests von dem 192.xxx ... Netz oder geht in diese Richtung gar nichts?

Wenn das der Fall ist, muss eurem Firmenrouter noch gesagt werden, dass Anfragen in das 172.16.0.0 Netzwerk an die 192.168.0.XXX Adresse des Wlan Routers (der hat 2 NICs - eine, die als gateway in das 192 netz geht [ich nenne sie mal "extern"] und eine, die den ["internen"] Bereich, sprich das 172.16.XXX.XXX Netzwerk verwaltet.) weitergeleitet werden.

Kleiner Tip, bevor du ALLE Regeln auf einmal erstellst, macht es mehr Sinn, erstmal mit dem Absoluten Minimum zu beginnen (eigene leidvolle Erfahrung)

Also erstmal alles auf dem W-LAN Router verbieten:

	Quellcode
1 2 3	# > /usr/sbin/iptables -P INPUT DROP # > /usr/sbin/iptables -P OUTPUT DROP # > /usr/sbin/iptables -P FORWARD DROP

und dann stueck fuer stueck freigeben.

Quellcode

# > INTERN=eth0
# > EXTERN=eth1
# > /usr/sbin/iptables -A INPUT -i $EXTERN -p icmp -d 172.16.0.0/24 -s 192.168.0.0/24 -j ACCEPT
# > /usr/sbin/iptables -A OUTPUT -o $EXTERN -p icmp -s 172.16.0.0/24 -d 192.168.0.0/24 -j ACCEPT

(zur Verfeinerung habe ich das Interface noch definiert... )

dann noch mal schnell mit /usr/sbin/iptables -L -v -n -x checken, ob das so uebernommen wurde, wenn das gut aussieht, einfach mal nen Ping an eine Maschine im 172.16.0.0 Netz abschicken. wenn der ankommt, weitere Regeln (sprich ACCEPT) hinzufuegen. Falls nicht mal mit nem traceroute pruefen, wo denn das Packet genau verloren geht...

for Windows problems: reboot
for Linux problems: be root

Zum Seitenanfang

giz

Anfänger

Beiträge: 6

3

27.03.2008, 15:09

Der WLAN Router wird nicht für Routingangelegenheiten genutzt, sondern dient nur als Access Point.

Der Access Point (ich nenn ihn ab jetzt mal so, ist anschaulicher) steht im 172.. Netz und soll vom 192.. erreichbar sein.
Der Router der diese beiden Netze verbindet, routet normalerweise nur Anfragen nach draussen, also von 172.. ins 192..
Für meinen speziellen Fall benötige ich das aber nun umgekehrt.

Ich habe nun erst nochmal ein Backup aufgespielt, sodass der Router wieder genutzt werden kann.
Dh. momentan ist alles was Routing etc. angeht so wie es sein soll, letztendlich muss nur noch der Port 80 auf den Access Point geroutet werden, das ist mein Problem !

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

4

27.03.2008, 15:18

Dass der AP nicht ins internet routen soll ist verstaendlich, aber da er zwischen den verschiedenen Netzwerken (wenn ich mich irre, dann berichtige mich bitte, aber 172.16.0.0/27 und 192.168.0.0/24 _SIND_ meiner Ansicht nach verschiedene Netzwerke) vermitteln soll, dann _MUSZ_ er ebenfalls routen.

Genau das ist es ja, was ein Router tut. Er stellt eine Schnittstelle bereit, die verschiedene Netzwerke verbindet und die Addressen fuer das jeweilige andere Netz nutzbar macht (uerbesetzt).

for Windows problems: reboot
for Linux problems: be root

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »BorneBjoern« (27.03.2008, 15:19)

Zum Seitenanfang

oziris

Sith Lord

Beiträge: 835

5

27.03.2008, 20:10

Einer meiner Rechner routet auch und da habe ich /proc/sys/net/ipv4/ip_forward dafür auf 1 gestellt.

(Außerdem habe ich NAT mit iptables nur im POSTROUTING eingebaut und benutze auch nur SNAT und nicht DNAT.)

Ich habe diesen Thread schon früher bemerkt, aber irgendwie verstehe ich den Kern des Problems nicht bzw. was der Sinn der einzelenen iptables-Regeln sein soll.

Die Problembeschreibung ist ja ausführlich, aber ich kann trotzdem nicht erkennen, ob ich helfen kann. Irgendwie fehlen mir Sätze wie, z.B.: "Der AP soll Port 80 Verbindungen mit NAT von 127... nach 192... weiterleiten/durchlassen aber nicht umgekehrt."

Außerdem Frage ich mich, ob die Netze wirklich durch einen Router getrennt sind, oder ob der Uplink-Port vom AP an einem Switch hängt. Apropos, welche Netze gibt es, welche sind auch als WLAN zugänglich und wie sind sie alle verbunden? Da ich das Problem nicht erkannt habe, weiß ich natürlich nicht, ob diese Information auch wichtig für dessen Lösung ist, aber auschließen will ich's auch nicht.

Zum Seitenanfang

giz

Anfänger

Beiträge: 6

6

28.03.2008, 09:34

Habe ich es zu ausführlich beschrieben? :crazy:

Ok ich probiere es nochmal.
Ich beschreibe erstmal die Situation _ohne_ AP.

Firmennetz (192.168.0.0) Rechner in diesem Netz haben Internetzugang
Netz für Kunden PCs (172.16.0.0)

Um mit den Kunden PCs auf Rechner im Firmennetz und auf das Internet zuzugreifen gibt es einen PC, der als Router dient.
Dieser Router hat 2 Netzwerkkarten und ist mit beiden Netzen verbunden.
Hinter dem Router steht ein Switch an den alle Kunden Rechner letztendlich angeschlossen werden.
Die Routingsoftware ist iptables.

Das funktioniert problemlos !

Jetzt kommt der AP ins Spiel.
Wir wollen Kunden PCs auch per WLAN ins unser Kunden Netz einbinden können.
Dafür wird der AP an den Switch hinter dem Router angeschlossen.
Das heißt, dass er nur für Hosts im Kunden Netz erreichbar und konfigurierbar ist.
Genau das möchte ich aber auch über das Firmennetz erreichen.
Dh. ich möchte mit meinem Arbeitsplatz PC, der kabelgebunden im 192.. Netz hängt, auf den AP im 172.. Netz zugreifen.

Und nun kommt mein Kernanliegen.
Der Router hat im Firmennetz die 192.168.0.79
Der AP hat im Kundennetz die 172.16.0.29
Ich möchte nun, wenn ich an meinem Arbeitsplatz im Firmennetz im Browser die 192.168.0.79 eingebe, auf die 172.16.0.29 weitergeleitet werden, sodass ich auf Weboberfläche des APs gelange.

Ich hoffe, dass die Sachlage nun klar ist

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

7

28.03.2008, 09:52

- setze doch einfach eine route in das 172.16.0.0/27 netzwerk auf dem router (das sollte bereits so sein, denn ansonsten koenntest du die Rechner in diesem netz nicht anpingen),
- verbiete mit iptables, dass Anfragen in dieses Netz an die externe NIC gesendet werden (koennte ebenfalls bereits konfiguriert sein)
- und dann rufe ganz normal in dem browser die adddi 172.16.0.29 auf und dann bist du auf dem AP.

Zitat

Ich möchte nun, wenn ich an meinem Arbeitsplatz im Firmennetz im Browser die 192.168.0.79 eingebe, auf die 172.16.0.29 weitergeleitet werden, sodass ich auf Weboberfläche des APs gelange.

So wie du das willst, wirst du immer auf dem Router landen, denn der hat ja die IP 192.168.0.79

Der http Verkehr (Port 80) sollte ja bereits aus dem 172. Netz in das 192. Netz (und natuerlich ich auch vice-versa) erlaubt sein. wenn nicht, einfach nachholen.

for Windows problems: reboot
for Linux problems: be root

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

8

28.03.2008, 09:54

Zitat

Ich möchte nun, wenn ich an meinem Arbeitsplatz im Firmennetz im Browser die 192.168.0.79 eingebe, auf die 172.16.0.29 weitergeleitet werden, sodass ich auf Weboberfläche des APs gelange.

Ich hoffe, dass die Sachlage nun klar ist

und warum willst du das?
es ist doch viel sinnvoller, dass du in deinem browser 172.16.0.29 eingibst und dann auf dem ap bist, wozu soll die umstellung der ip gut sein?

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

oziris

Sith Lord

Beiträge: 835

9

28.03.2008, 10:35

Ich habe mal versucht, das Netz in einem angehängdten Diagramm darzustellen. Möglicherweise muss ich den Post nochmal ändern, weil ich das mit den Anhängen zum ersten Mal mache ^_^"

Ich denke die nötigen Kommandos für das Port-Forwarding sehen ungefähr so aus:

iptables -t nat -A PREROUTING -p tcp -i eth0 -d 192.168.0.79 --dport 80 -j DNAT --to 172.16.0.29:80
iptables -A FORWARD -p tcp -i eth0 -d 172.16.0.29 --dport 80 -j ACCEPT

Natürlich musst Du sie vielleicht noch mit den vorhandenen Regeln in Einklang bringen und möglicherweise eth0 gegen die NIC im 192er-Netz austauschen.

»oziris« hat folgendes Bild angehängt:

Zum Seitenanfang

giz

Anfänger

Beiträge: 6

10

28.03.2008, 11:04

Hey cool danke für das Diagramm!
Bis auf den Tippfehler bei 192.169.. ist das absolut korrekt

Zitat

setze doch einfach eine route in das 172.16.0.0/27 netzwerk auf dem router (das sollte bereits so sein, denn ansonsten koenntest du die Rechner in diesem netz nicht anpingen)

Das ging nicht und soll auch nie gehen.
Einzig der Zugriff auf den AP soll möglich sein.

Zitat

und warum willst du das?
es ist doch viel sinnvoller, dass du in deinem browser 172.16.0.29 eingibst und dann auf dem ap bist, wozu soll die umstellung der ip gut sein?

Ich bin bisher davon ausgegangen, dass wenn ich (als Teilnehmer im 192.. Netz) eine 172.. Adresse aufrufe, mein Rechner gar nicht weiß wo der Host mit dieser Adresse liegen soll.

Vllt. sollte ich noch anmerken, dass dieser Router zwischen beiden Netzen keine weitere Funktion übernimmt, dh. Gateway, DNS usw. für die Firmenrechner wird von anderen Rechnern erledigt.

Zitat

iptables -t nat -A PREROUTING -p tcp -i eth0 -d 192.168.0.79 --dport 80 -j DNAT --to 172.16.0.29:80
iptables -A FORWARD -p tcp -i eth0 -d 172.16.0.29 --dport 80 -j ACCEPT

Genau diese Befehle hatte ich so schonmal reingehauen, das hatte aber nicht funktioniert.

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

11

28.03.2008, 11:05

ich nehme mal an, das http anfragen aus dem 172.xxx netz generell erlaubt sein sollten, damit $Kunde auch ins internet kann...

Daher macht es mehr sinn, bei -d das gesammte netzwerk anzugeben. also

iptables -A FORWARD -p tcp -i eth0 -d 172.16.0.0/27 --dport 80 -j ACCEPT

Oder hab ich gerade einen Denkfehler?

[edit]

Zitat

Ich bin bisher davon ausgegangen, dass wenn ich (als Teilnehmer im 192.. Netz) eine 172.. Adresse aufrufe, mein Rechner gar nicht weiß wo der Host mit dieser Adresse liegen soll.

daher die Route auf dem Router von dem 192 in das 172 Netzwerk.

Ueber iptables kannst du das dann anschlieszend wieder so einschraenken, dass nur die Adresse 172.16.0.29 erreichbar ist.

[/edit]

for Windows problems: reboot
for Linux problems: be root

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BorneBjoern« (28.03.2008, 11:10)

Zum Seitenanfang

oziris

Sith Lord

Beiträge: 835

12

28.03.2008, 12:30

Zitat

Genau diese Befehle hatte ich so schonmal reingehauen, das hatte aber nicht funktioniert.

Wenn Du Dich auf die Befehle aus Deinem ersten Post beziehst, dann möchte ich darauf hinweisen, dass da gewisse, winzige Unterschiede existieren. Ich weiß ehrlich gesagt nicht, welche Wirkung diese Unterschiede haben oder ob sie überhaupt eine haben. Es ist Deine Entscheidung.

Ich persönlich mache übrigens pro Rechner ein Script, in dem alle iptables-Befehle drinstehen, um die Firewall immer wieder auf einen bestimmten Stand zurückzusetzen. Wenn ich einen guten Zwischenstand habe, mache ich eine Sicherungskopie des Scripts und wenn ich etwas verfeinern will editiere ich das Script und führe es aus, um die Änderungen zu testen. Es gibt zwar auch iptables-save, aber ein Script ist dynamisch und kommentierbar.

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

13

28.03.2008, 12:54

@ oziris:

ich habe mal dein Pictogramm ein wenig bearbeitet, da ich es nicht zu 100% richtig fande... (sorry... aber bei solchen dingen bin ich ...aehm manchmal unsaustehlich)

@ giz:

um die Route ins 172 Netz wirst du aber mit keinem Filter herumkommen.

»BorneBjoern« hat folgendes Bild angehängt:

for Windows problems: reboot
for Linux problems: be root

Zum Seitenanfang

giz

Anfänger

Beiträge: 6

14

31.03.2008, 08:27

Danke Björn, ich wollte nicht so pingelig sein

aber dein Pictogramm stimmt nun zu 100%. :+++:

Da wir aktuell einen Praktikanten mit Linux Erfahrung haben, habe ich ihn mal darauf angesetzt...leider ohne Erfolg.
So wie ich es verstanden habe, hat er erstmal grundsätzlich jede Anfrage auf den Rechner erlaubt und dann nochmal explizit eine Route für Port 80 auf den AP gesetzt.
Ich poste euch mal die aktuellen Regeln, vllt. könnt ihr mir sagen wo der Fehler liegt.

Quellcode

Chain PREROUTING (policy ACCEPT 126K packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
    3   144 DNAT       tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 to:172.16.0.29

Chain POSTROUTING (policy ACCEPT 731 packets, 119K bytes)
 pkts bytes target     prot opt in     out     source               destination
  578 93166 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 1168 packets, 208K bytes)
 pkts bytes target     prot opt in     out     source               destination

Quellcode

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            state NEW icmp echo-request
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www
TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »giz« (31.03.2008, 08:28)

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

15

31.03.2008, 09:02

Gerade bei solchen Dingen bin ich es aber immer... denn wenn die Doku / Piktorgramme net stimmen oder miszverstaendlich sind... nuetzt dir der ganze Hafer nickxs mehr, wenn du spaeter mal deine Schritte nachvollziehen willst/muszt...

mal so ganz nebenbei, mit diesem "accept all anywhere" benoetigt man keine FW mehr.
Denn jetzt wird irgendwie so bissel wie gar nichts mehr gefiltert....
Naja, wem's gefaellt...

Wenn die Anfragen nur aus dem 192. Netzwerk kommen und ihr euch doch ueberlegt, doch ein klein wenig zu filtern, dann sollte man auch nur diesen Traffic erlauben.

also als erste regel fuer den IN / OUTPUT sollte ungefaehr so aussehen (nachdem alle bisher gueltigen Regeln geloescht wurden):

Quellcode

1
2

# > iptables -A INPUT -i {NIC mit dem 172. Netz} -p tcp -dport 80 -d 192.168.0.0/24 -s 172.16.0.29  -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# > iptables -A OUTPUT -i {NIC mit dem 172. Netz} -p tcp -dport 80 -d 172.16.0.29 -s 192.168.0.0/24 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

die policy steht ja noch auf drop...

mit einem tcpdump -i {NIC mit dem 172. Netz} tcp port 80 mal auf dem Router checken, was fuer Packete diese NIC auf dem Port 80 passieren. und dann von einem Rechner im 192. Netz eine Anfrage auf den AP im Browser starten.

Wenn tcpdump nichts anzeigt, ist das Routing noch verkehrt. Aber da waere ein Post der Ausgabe nicht verkehrt...

for Windows problems: reboot
for Linux problems: be root

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BorneBjoern« (31.03.2008, 09:05)

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

16

31.03.2008, 09:25

uuups die 15 minuten regel hat wieder zugeschlagen...

Zitat

Wenn tcpdump nichts anzeigt, ist das Routing noch verkehrt. Aber da waere ein Post der Ausgabe nicht verkehrt...

ist natuerlich leicht miszverstaendlich... :crazy:

Was sagt uns das... richtig.... ich tippe immernoch nicht so schnell, wie ich denke...
Daher sollte ich es mir echt wieder angewoehnen danach zu handeln, was mir mein Ausbilder zum Thema "Funken" mehr als einmal erzaehlt hat:
"Denken, Druecken, Sprechen und zwar in dieser Reihenfolge und nicht anders"

denn wenn es nichts anzeigt, kann auch keine neue Info gepostet werden. - Iss klar, ne?

Ich meinte aber wenn bei tcpdump nichts angzeigt wird dann mueszt ihr nochmal ueber das routing schaun. und gegebenen Falls posten.

Wenn aber was angezeigt wird und trotzdem keine Verbindung zu stande kommt, _dann_ kannst du ja mal die Ausgabe von tcpdump posten.

Jetzt habe ich es richtig ausgedrueckt...

for Windows problems: reboot
for Linux problems: be root

Zum Seitenanfang

giz

Anfänger

Beiträge: 6

17

03.04.2008, 11:56

Ich habe dich einwandfrei verstanden

tcpdump musste ich erstmal installieren und bin stolz das geschafft zu haben und sogar seine Anwendung und Nutzen verstanden zu haben :applaus:

Ok hier die Auswertung von tcpdump auf eth1, bei einer Anfrage aus dem 192er Netz

Quellcode

wrouter:~# tcpdump -i eth1 tcp port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:03:58.150968 IP 192.168.0.196.l2f > 172.16.0.29.www: S 3654677241:3654677241(0) win 65535 <mss 1460,nop,nop,sackOK>
14:04:01.128670 IP 192.168.0.196.l2f > 172.16.0.29.www: S 3654677241:3654677241(0) win 65535 <mss 1460,nop,nop,sackOK>
14:04:07.144342 IP 192.168.0.196.l2f > 172.16.0.29.www: S 3654677241:3654677241(0) win 65535 <mss 1460,nop,nop,sackOK>

Ich habe dann mal, um zu schauen ob evtl. noch andere Ports zum Verbinden auf den AP genutzt werden, Lynx installiert und mich mit dem AP verbunden.
Dabei hat tcpdump -i eth1 Folgendes angezeigt:

Quellcode

wrouter:~# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:02:03.880692 IP 172.16.0.30.32779 > 172.16.0.29.www: P 3604736900:3604737154(254) ack 3690663871 win 5840 <nop,nop,timestamp 502574841 146803>
14:02:03.970759 IP 172.16.0.29.www > 172.16.0.30.32779: R 3690663871:3690663871(0) win 0
14:02:08.877908 arp who-has 172.16.0.29 tell 172.16.0.30
14:02:08.878265 arp reply 172.16.0.29 is-at 00:1e:2a:5d:87:50 (oui Unknown)
14:02:27.965146 IP 172.16.0.30.32780 > 172.16.0.29.www: S 3700754944:3700754944(0) win 5840 <mss 1460,sackOK,timestamp 502598931 0,nop,wscale 0>
14:02:27.965870 IP 172.16.0.29.www > 172.16.0.30.32780: S 3714023869:3714023869(0) ack 3700754945 win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 146983 502598931>
14:02:27.965928 IP 172.16.0.30.32780 > 172.16.0.29.www: . ack 1 win 5840 <nop,nop,timestamp 502598931 146983>
14:02:27.970027 IP 172.16.0.30.32780 > 172.16.0.29.www: P 1:255(254) ack 1 win 5840 <nop,nop,timestamp 502598936 146983>
14:02:27.970766 IP 172.16.0.29.www > 172.16.0.30.32780: . ack 255 win 8192 <nop,nop,timestamp 146983 502598936>
14:02:27.972719 IP 172.16.0.29.www > 172.16.0.30.32780: P 1:67(66) ack 255 win 8192 <nop,nop,timestamp 146983 502598936>
14:02:27.972797 IP 172.16.0.30.32780 > 172.16.0.29.www: . ack 67 win 5840 <nop,nop,timestamp 502598938 146983>
14:02:27.973543 IP 172.16.0.29.www > 172.16.0.30.32780: P 67:1067(1000) ack 255 win 8192 <nop,nop,timestamp 146983 502598938>
14:02:27.973588 IP 172.16.0.30.32780 > 172.16.0.29.www: . ack 1067 win 7000 <nop,nop,timestamp 502598939 146983>
14:02:27.974168 IP 172.16.0.29.www > 172.16.0.30.32780: FP 1067:1399(332) ack 255 win 8192 <nop,nop,timestamp 146983 502598938>
14:02:27.983026 IP 172.16.0.30.32780 > 172.16.0.29.www: F 255:255(0) ack 1400 win 9000 <nop,nop,timestamp 502598949 146983>
14:02:27.983567 IP 172.16.0.29.www > 172.16.0.30.32780: . ack 256 win 8192 <nop,nop,timestamp 146983 502598949>

Aber auch hieraus konnte ich leider nichts weiter erkennen, als dass er über Port 80 geht.
Unser Praktikant hat nun das aktuelle Script mal zu Hause bei sich in einer Testumgebung probiert und da hat es funktioniert, deswegen hatte ich in Verdacht, dass noch andere Ports zum kommunizieren zwischen AP und Router verwendet werden.

Ich bin weiterhin ratlos

Zum Seitenanfang

BorneBjoern

Stuemper

Beiträge: 898

Wohnort: Koenigstein

18

03.04.2008, 12:27

hmm okay... wenn ich das jetzt gerade richtig interpretiere, hat wrouter (der Debian Router ?) die IP 172.16.0.30 - Korrekt?

Habt ihr in der Zwischenzeit diese Box neugestartet? denn wenn ja, sind alle iptables Einstellungen und Regeln wieder auf den (Distributions)Standard zurueckgesetzt worden.

Daher macht es sich ganz guenstig, sich ein kleines Script mit den eignen Einstellungen zu schreiben, welches beim Systemstart mitgestartet wird.

nochmal zur Erinnerung: den aktuellen Status der Tables bekommst du mit iptables -L -n -v -x in ausfuerlicher Form.

Denn so, wie es aussieht, wird entweder der eingehende Verkehr auf dem Port 80 von wrouter gedroppt oder wie du bereits vermutet hast, antwortet der AP auf einem anderem Port.

Um das mal zu pruefen, erlaube mal nur ein Echo request.

also zuerst (falls noch nicht geschehen):
- die default policy auf drop,
- alle Regeln wieder loeschen und
- dann nur icmp packages (sowohl einghend, als auch ausgehend) erlauben.

iptables -A INPUT -i eth1 -p tcmp -j ALLOW
iptables -A OUTPUT -o eth1 -p tcmp -j ALLOW

dann wieder dumpen waehrend du einen Ping aus beiden Netzwerken auf den wrouter bzw auf eine IP im anderen Netz abschickst

Wenn alle 4 verschieden Pings funktionieren, funktioniert auch das NAT, Routing UND die Filter. Was als naechster Schritt folgt, waere:
erlaube
- auf der eth1 allen AUSgehenden Traffic auf dem Port 80 ins 172.x Netz und
- auf der eth1 allen eingehenden Traffic von ALLEN Ports aus dem 172. Netzwerk

Anschliszend wieder auflisten und danach dumpen um den Traffic zu checken, der entsteht, wenn du auf den AP zugreifst.

Dann solltest du auf jeden Fall mehr Infos bzw den Port haben, auf welchem der AP antwortet. Damit kannst du dann die Regel verfeinern, die den einkommenden Traffic aus dem 172 Netz beschreibt, um wirklich nur das zu erlauben, was noetig ist.

Ich weisz, das ist ein wenig umstaendlich... aber wenn ihr es sicher haben wollt ist es besser, wirklich schritt fuer schritt vorzugehen.

Sobald die ertse Regel 100% so funktioniert und greift, wie sie soll, ist das restliche Regelwerk ein leichte(re)s Unterfangen sein.

for Windows problems: reboot
for Linux problems: be root

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »BorneBjoern« (03.04.2008, 12:38)

Zum Seitenanfang