Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

Routing mit Suse 10.1 funktioniert nicht. Denkfehler oder Bug?

Frage Linux Suse

Mitglied: 15187

15187 (Level 2)

28.12.2006, aktualisiert 20:51 Uhr, 5034 Aufrufe, 6 Kommentare

Ziel: PC mit Fest-IPs soll mit Suse 10.1 als Router fungieren.

Das Problem ist vermutlich ein ganz kleines, auch wenn diese Anfrage sehr lang und ausführlich ist.
Wenn man solange damit beschäftigt ist, schleichen sich vielleicht Denkfehler ein.
Daher bitte ich Euch um Hilfe. Ich glaub nicht, dass es schwer zu lösen ist. Wer weiterhelfen kann, bekommt 5*. Versprochen!

Eigentlich funktioniert fast alles. Feste IPs und Routen sind eingetragen, Firewall2 ist konfiguriert.
Die internen PCs kommen raus, und der eingestellte SSH-Zugang über die externe IP funktioniert auch.

Aber: IPCOP ist per traceroute vom Router aus nicht aufzufinden. Anpingen funktioniert allerdings.

4ca940bf7929191260f7c72283d4ae32-netzwerk-12-2006_kurz - Klicke auf das Bild, um es zu vergrößern

Besonderheit: Damit ich den GW 195.x.y.128 erreiche, muss ich ihn als Host mit der IP 192.168.1.1 eintragen und diesen Host (welcher beim Provider der selbe Router ist) als default-GW eintragen. Tue ich das nicht, erreiche ich nur Rechner oberhalb der .128-er IPs. DNS und Mail-Server liegen darunter. In diese Richtung funktioniert eigentlich alles soweit. Ob es aber fehlerfrei ist, weiß ich nicht.

Der PC, der nun über die interne LAN-Karte erreicht werden soll, ist der IPCOP:

Pinge ich nun den IPCOP an, reagiert er brav auf die 192.168.100.2
Versuche ich, ihm mit traceroute nachzukommen (auch wenn es nur 1 Hop wäre), erhalte ich nur *Sternchen*-Antworten

Das ganze ist eigentlich kein großes Problem, da ich einfach nur von außen meinen IPCOP über den Port 81 (und 445) erreichen will.
Dazu habe ich Portforwardings eingetragen und die Firewall restartet ohne Fehlermeldung, also offenbar sauber.
Dennoch erreiche ich von außen den IPCOP nicht. IPCOP selbst ist aber "von außen", also auf der RED-IP freigeschaltet, und auch auf der Adresse erreichbar, sodass ich ihn ausschließen kann.

Ich habe iptraf auf der Suse-Kiste mitlaufen lassen, demnzufolge werden die Ports nach wenigen kBytes geschlossen (closed) und die Anfrage der Webseite auf die Internet-IP (195...) läuft auf Fehler. Da ich von ganz intern (also von einem Laptop mit 192.168.0.17) per SSH und anderen Programmen auf die Intern-IP der Suse-Kiste komme, weiß ich nun nicht, wieso diese mich beim Zugriff auf Port 81 nicht korrekt wieder "hinein"-forwarded.

Wenns von intern nicht funktioniert, warum auch immer, ist nicht schlimm, auf den IPCOP komm ich auch so. Aber von außen möchte ich ihn erreichbar machen, und das funktioniert eben nicht.
Anfragen von außen auf Port 81 (und 445) werden also nicht auf die RED-IP weitergeleitet.

Warum nicht? Wer kennt sich damit aus und kann mir behilflich sein?

Gruß,
tc
Mitglied: aqui
28.12.2006 um 13:47 Uhr
Die Sache mit der "Besonderheit" ist etwas unklar....und wahrscheinlich falsch ! Die externe Hostadresse deines externen LAN Segments MUSS im Bereich 195.x.y.129 bis .254 liegen sofern du dich im .128er Netz befindest, also der oberen Hälfte des mit einer 25 Bit Maske geteilten Netzes 195.x.y.0.
Mit der 25 Bit Subnet Maske hast du 2 IP Netzsegmente ! Einmal das .0er Netz mit 195.x.y.1 bis .126 (.127 ist Broadcast) und einmal das .128er Netz mit den Adressen 195.x.y.129 bis .254

Dein Gatewayeintrag dort kann eigentlich niemals die 195.x.y.128 sein bei einer 25 Bit Maske, denn die .128 bezeichnet das IP Segment selber ist also folglich die Netzwerkadresse (Alle Hostbits auf 0) !! So eine Adresse kann niemals eine Endgeräteadresse sein also z.B. die eines Routers !!! Hier ist also schon mal ein Fehler. Wahrscheinlich beruhen alle Folgefehler auf dieser falschen IP Adressvergabe.
Das der Providerrouter 2 IP Netze hat ist auch nicht normal ! Oder hat er noch ein 3tes Segment auf dem das 192.186.1.0er Segment vergeben ist ?? 2 IP Adressen auf einer Infrastruktur zu fahren ist nicht IP konform und wird ausschliesslich zu Migrationszwecken temporär gemacht. Schon gar nicht sollte man RFC 1918 Adressen mit öffentlichen Adressen mischen, das macht eigentlich kein Provider und ist bei denen ein Tabu !
Bitte warten ..
Mitglied: 15187
28.12.2006 um 14:28 Uhr
Hallo aqui,

Du bist schnell und fleißig, das seh ich in vielen Threads ;)
Danke, dass Du mir hilfst!!

Meine externe IP-Adresse ist größer als 128, ja.

Der GW 195.x.y.128 ist defacto richtig. Auch wenn er möglicherweise das IP-Segment selbst bezeichnet, wie Du sagst.
Mein Provider gibt als Grund für die beiden IP-Adressen an, dass es unterschiedliche Router gibt, die unterschiedliche GW's akzeptieren. Die Fritzbox akzeptiert z.B. die 192.168.1.1 nicht, da sie nicht im 195-er Bereich liegt. Mein ehemaliger Router, ein Linksys wrt54gc, akzeptierte beides, und mit dem Gerät funktionierte das Reinrouten auch super. Ein 3. Segment kommt meines Wissens nicht vor. Genau weiß ich das aber nicht.

Du sprichst von Folgefehlern. Wenn ich nun vom Laptop auf http://die_externe_IP:81 zugreife, muss ich doch eigentlich nicht aus meinem Netzwerk raus. Meinst Du, die "spezielle" Konfiguration kann der Grund dafür sein? Aber wieso nur der Port? Greife ich per SSH auf die Suse-Kiste (also auf die externe IP) zu, funktioniert das. Von innen und von außen.

Es ist natürlich grundsätzlich die Frage, wohin leitet das System was weiter, wenn als default-gw 192.168.1.1 eingetragen ist.

Gruß,
tc
Bitte warten ..
Mitglied: aqui
28.12.2006 um 15:48 Uhr
Hallo TC

Das kann nicht sein was dein Provider da sagt oder einer hat etwas falsch verstanden. Nach gängigen IP Adresskonventionen darf die .128 einfach gar nicht vergeben werden. Ist sie trotzdem vergeben ist das ein böser Fehler denn die meisten aller IP Stacks würden auf so eine Adresse als Endgeräteadrresse schlicht nicht reagieren weil sie falsch ist. Schon aus dem Grunde um unterschiedliches verhalten nicht zu provozieren wäre die Vergabe dieser Adresse einfach falsch.
Es kann auch nicht sein das man ein 195er Adresse nict auf der Fritzbox konfigurierbar ist. Anhand deiner Ausführungen ist zu vermuten, das auf dem Routersegment zwischen deinem SuSE Rechner und dem Router 2 aktive IP Netze konfiguriert sind. Das ist IP technisch falsch da wie gesagt eigentlich in einem sauberen Design nicht supportet. Deshalb ist es auch klar das du nicht z.B. eine Seite mit 195.x.y.z konfigurieren kannst und die andere mit 192.168.x.y. Das ist IP technisch unmöglich !! Für die beiden Endgeräte sind das unterschiedliche IP Netze die sie nicht sehen auch wenn sie auf ein und derselben Physik stecken.
Meist können das höherwertige Router mit sog. "secondary" IP Adressen lösen aber das Problem ist das z.B. schlicht nicht definiert ist welche der unterschiedlichen IP Netze nun ICMP Dienstpackete (zu denen auch Traceroute gehört..) versendet. Das ist nicht im IP Standard vorgesehen und deshalb auch von vielen nicht supportet oder sollte wie gesagt wenn, dann nur temporär für Adressmigrationen eingesetzt werden.
Erschwerend kommt bei dir dazu das die 195er Adresse öffentlich ist die 192.168.1.x aber nicht. Höchst bedenklich auf einem Segment und würde dann wenigstens einen NAT Prozess für dies IP Netz im Router erfordern.
An diesem Router ist de facto generell was falsch mit der IP Adressierung. Die .128 darf definitiv NICHT als Geräteadresse vergeben werden, das ist ein Fehler. Auch ist die Verwendung von 2 Netzen zumindest bedenklich und kann zu weiteren Fehlern führen. Keine übliche Praxis bei Providern....

Mit deinem lokalen Zugriff auf Port 81 der externen Adresse sollte klappen wenn SSH oder ping klappt und alle Routen im IPCop soweit stimmen, was anzunehmen ist, wenn SSH auf die externe Adresse problemlos klappt.
Vermutlich wird dann Port 81 irgendwo geblockt. Auch wäre ich vorsichtig, denn TCP/UDP 81 ist ein reservierter Port den man nicht so ohne weiteres verwenden sollte. Wenn du damit eine HTTP Verbindung aufbauen willst solltest du besser 8080 oder 8088 nehmen !
Im Zweifelsfall musst du mit tcpdump oder einem Wireshark an den Interfaces mal nachsehen wer dir diese Packete "klaut". Es kann eigentlich nur irgendwo ein Port Filter sein denn wenn generell was falsch ist dürfte Ping und SSH auch nicht klappen....
Bitte warten ..
Mitglied: 15187
28.12.2006 um 16:18 Uhr
hm, nun, Du bist wahrlich nicht der erste, der mir zu bedenken gibt, dass die Netzwerkstruktur meines ISP falsch ist. So stehe ich nun im Mittelpunkt und darf erstmal selbst Gateway spielen. Auf der einen Seite die, die sagen, es sei falsch, auf der anderen Seite mein ISP, der sagt, das sei ok. Da ist guter Rat teuer. Was soll ich ihm sagen? Bitte, lieber ISP, konfigurier Dein Netz nach den Regeln der RFC...!?
Ok, trennen wir erst mal das Problem in zwei Teile.
Teil 1: der interne Part ab meinem Suse-Gateway
Teil 2: der externe mit dem ISP. Und den lass ich mal außen vor.

Nur mal angenommen, mein Richtfunk-Internetanschluss fällt aus, weil jemand den Funkverkehr abschneidet. Nun greife ich auf die öffentliche IP zu.
Laptop öffnet den Empfangsport (z.B.12001), wartet auf Antwort von IPCOP, weil der die Anfrage weiterschickt.
IPCOP öffnet den Empfangsport (z.B.19380), wartet auf Antwort von suse, weil für ihn die Anfrage bestimmt ist.
Suse soll also Port81 abrufen und erkennt dabei, dass dieser an IPCOP geforwarded werden soll. Also öffnet suse einen Empfangsport (z.B. 17491) und meldet sich beim IPCOP auf Port81.
Ab dann wird alles rückwärts zu den wartenden Ports zurückgeleitet und letztlich erhält Laptop den Inhalt von IPCOP:81
Betrachte ich mir den Verlauf per ethereal (e)/iptraf (i), erkenne ich:
1. (e) Laptop schickt die Anfrage an 192.168.0.1...ok (Port 12001 wartet auf Antwort)
2. (e) IPCOP schickt die Anfrage an 192.168.100.1 weiter...ok (Port 19380 wartet auf Antwort)
3. (i) Suse erhält VON 192.168.100.2 Port 19380 Pakete. Dann wird "geclosed"

Die Firewall ist offen... wieso sollte sie die Pakete verwerfen/blocken/droppen?
Kann ich das noch genauer herausfinden? Was ich noch machen kann: ethereal auf suse nochmal mitschneiden lassen. Bisher wurde ich nicht schlau daraus. Aber das kann sich ja ändern. Ich melde mich dann nochmal.

Bis dann.
Gruß,
tc

PS: ähnliches Problem habe ich mit VNC. Die Verbindung wird aufgebaut, aber sobald der Bildschirm-Inhalt übertragen werden soll, seh ich nur das schwarz/weiße Raster. Das Verhalten kann ich beobachten, seit ich die Remarks aus der SuSEFirewall2-Config gelöscht habe und dabei die Custom-Rules aktiviert hatte (darin waren Einträge für die Weiterleitung von GRE - ich habe das aber wieder Remarked)
Bitte warten ..
Mitglied: aqui
28.12.2006 um 16:45 Uhr
Nochmal was zum Internetanschluss: Wieso "Richtfunk-Internetanschluss fällt aus, weil jemand den Funkverkehr abschneidet. Nun greife ich auf die öffentliche IP zu..." ???
Sowohl Draht als auch RiFu sollten öffentliche Adressen benutzen wenn der Provider das RiFu Netz nicht mit eigenen RFC 1918 Adressen betreibt ! So oder so MUSS er doch dafür sorgen, das sich beim Ausfall einer Strecke für dich als Kunden nichts ändert an der IP Adresse. Er kann doch nicht von dir als Kunden verlangen das du ewig deinen Zugang umkonfigurierst...das hört sich sehr komisch an und verstärkt den Verdacht, das der Provider wirklich nicht weiss was er da macht....

Nun zu deiner Laptop Kommunikation. Wenn die FW stateful ist terminiert sie die Anfrage das ist rihtig, sie darf aber den Zielport nicht verändern was sie auch nicht macht. Gesetzt den Fall du nimmst SSH (hat nicht so hohe verwirrende Portnummern..) dann eröffnet der Latop eine TCP Connection auf Port 22 zum IPCop der terminiert das und schickt auf dem outgoing Interface aber wiederum eine TCP Connection mit Ziel Port 22 an den Suse. Der Empfangsport ist sicher unterschiedlich zu dem des Laptops.
Kommt nun das Packet mit TCP 22 beim Suse an reicht er es an die Applikation weiter, die sieht aber den von IPCop verwendeten Sourceport und schickt diese Packete mit eben diesem Sourceport für IPCop als Zielport wieder zurück. Da der IPCop stateful ist sieht der in der State Tabelle nach und sieht das incoming 19380 für outgoing 12001 ist und ändert das entsprechend für den Laptop als final Destination.
Wäre der IPCop nicht stateful würden die Ports transparent durchgereicht....
Das Problem ist das die FW immer nur genau diese Ports durchlässt rückwärts die sie auch in ihrer State tabelle hat. Eröffnet die Zielapplikation weitere Ports wie z.B. bei FTP und anderen Protokollen blockt die FW diese Ports da sie dafür keine aktiven Sessions hat. Man muss bei solchen Protokollen also sehr genau sehen was passiert. VNC z.B. erhöht die Portnummer um jeweils 1 bei weiteren zusätzlichen Schirmen.... sowas blockt die FW normalerweise wenn man nicht gleich die Portrange in der FW Range freigibt.
Bitte warten ..
Mitglied: 15187
28.12.2006 um 20:51 Uhr
IPCOP ist ja nicht das Problem. Der hat bis heute alles fehlerfrei hinbekommen.
VNC-Probleme sind - wie gesagt, aber schlecht dargestellt - seit ich die Zeilen mit den Rauten # gelöscht habe (also eigentlich nur die Erklärungen). Eine Zeile, die die custom-rules einbindet, hatte ich "entrautet", also aktiv geschaltet. Danach startete die suse-Firewall nicht richtig, daraufhin hab ich das #-Symbol wieder vor die Zeile gesetzt und die FW wieder neugestartet. Dabei fehlerfrei. Aber seitdem mag VNC nicht mehr. Hab auch schon den Rechner komplett neugestartet - gleiches Verhalten.
Wohlgemerkt VNC-Viewer auf Laptop, VNC-Server auf Suse. Ich muss also durch die FW, die in die ausgehende Richtung komplett offen ist. Da daran nichts geändert wurde, kann ich die Kiste als Fehlerquelle ausschließen.
Aber VNC ist auch nicht das große Problem. Der Router steht nur 3m weiter. Da kann ich auch mal laufen

Ich weiß aber immernoch nicht, warum suse die Anfragen auf Port81 nicht weiterreicht.

Gruß,
tc
Bitte warten ..
Neuester Wissensbeitrag
Humor (lol)

Linkliste für Adventskalender

(3)

Information von nikoatit zum Thema Humor (lol) ...

Ähnliche Inhalte
Windows Netzwerk
Windows 10 routing (21)

Frage von schmit zum Thema Windows Netzwerk ...

Windows 10
gelöst Windows 10 interner vpn client funktioniert nicht (3)

Frage von tobias3355 zum Thema Windows 10 ...

Windows 10
Windows 10 SSD Bug nach Anniversary Update? (1)

Link von Pjordorf zum Thema Windows 10 ...

Heiß diskutierte Inhalte
Router & Routing
gelöst Ipv4 mieten (22)

Frage von homermg zum Thema Router & Routing ...

Exchange Server
gelöst Exchange 2010 Berechtigungen wiederherstellen (20)

Frage von semperf1delis zum Thema Exchange Server ...

Windows Server
DHCP Server switchen (20)

Frage von M.Marz zum Thema Windows Server ...

Hardware
gelöst Negative Erfahrungen LAN-Karten (19)

Frage von MegaGiga zum Thema Hardware ...