Kein Subnetz routing möglich SUSE 9.3

[Frankie777]

ich habe es mir im Detail nicht angeschaut.

Wenn ein Rechner ein Paket bekommt und er antwortet nimmt er die Absendeadresse und schickt es zurück.
Dazu nimmt er die routing Tabelle, man kann bei Windows die route auch persistent eintragen.
Wenn Du die Routing Tabelle der Clients nicht pflegen willst muß Dein Linux Rechner eben die source IP des Paketes manipulieren.
z.B. siehe man iptables --snat

 

[ThomasF]

Hmmm,

192.168.0.250 255.255.255.255 192.168.0.125 192.168.0.7 1
192.168.0.255 255.255.255.255 192.168.0.7 192.168.0.7 1

Die 192.168.0.255 ist der Broadcast für das andere Netz (letzte IP des Subnetzes) !!!
Das bedeutet doch das das Gateway für den Broadcast in dieses Netz auch die 192.168.0.125 sein muß , oder sehe ich das falsch ???

EDIT Ist die 192.168.0.250 richtig ? Ich habe vielleicht nicht alles mitbekommen, aber so erreichst Du nur die eine IP (Server) aber nicht die anderen Rechner im anderen Netz.

Hoffe das hilft Dir weiter

So long

ThomasF

 

[leider_admin]

die Skizze mit dem Netzwerk nochmal als Bild.

mit der Korrektur von oben:

Im Server 192.168.0.1 steckt KEINE ISDN Karte,sondern eine uralt Sedlbauer DSL Karte, die wird wie eine ISDN Karte angesprochen und verhält sich im Prinzip auch so. Fragt nicht nach dem Typ.

Zeichenfehler: beim Server 192.168.0.1 gib es keine 192.168.1.1 sondern ist halt wie ISDN !!!!!

Die Anlage rechts im Bild (192.168.0.1) als Server soll ebenfalls noch so umgebaut werden wie links!

Es erfolgt ( soll auch nicht ) kein Routing für WAN über die Standleitung gehen, da hier nur eine begrenzte Bandbreite zur Verfügung steht, und DSL an beiden Standorten günstiger ist als eine schnellere Standleitung

 

[ThomasF]

Nachtrag zum Thema redirect

Also wie schon weiter oben steht können keine Routen außer dem Standardgateway per DHCP übergeben werden.

Dann ist unter gewissen Umständen TCP/IP redirect das Mittel der Wahl ;-)

Ein normales Windows akzeptiert ein redirect ! Läuft bei uns auch so

Es kann aber sein das es in der Registry eine Möglichkeit gibt dies zu unterbinden z.B per Gruppenrichtlinie verteilt oder durch eine Firewall.
Es kann auch sein das es in einer Sicherheitsrichtinie des Unternehmens untersagt ist (Püfen ! )

Außerdem sollte es allen Rechnern des Subnetzes erlaubt sein diese Route zu benutzen (muß sonst wieder durch Firewall eingeschränkt werden )

Es gilt zu beachten das auf jedem Rechnern mit TCP/IP folgendes gilt :
Bei Zugriff auf einen anderen Rechner im Netz wird erst geprüft ob der andere Rechner im gleichen Netz liegt, wenn nicht wird nach einer passenden localen Route gesucht, wenn das alles nix hilft wird das Standardgateway benutzt.

Das Standardgateway ist also der richtige Ort alle benötigten Routen einzutragen, dann braucht man nicht zu allen Clients zu rennen um die Routen einzutragen.

Wenn das Standardgateway ein Linuxrechner muß das redirect wahrscheinlich erst erlaubt werden (siehe oben)
Läuft eine Firewall muß es dort auch erlaubt werden (siehe icmp-redirect)
Wenn Du den fwbuilder nutzt sollte das kein Problem darstellen.
SuSEfirewall nutze und kenne ich nicht !

Im jedem guten Firewall-Buch wirst Du die entsprechenden Regeln z.B für iptables finden.

Was das ursprüngliche Problem betrifft hat Martin glaube ich irgendwo hier in der Ecke eine gute Einführung in TCP/IP geschrieben.
Für mich war es aber z.B auch hilfreich gerade beim Subneting die Maske binär aufzuschreiben und dann beispielsweise zu sehen das immer die erste Adresse eines Subnetzes nur aus Nullen besteht (netz) und die letzte nur aus Einsen (broadcast)

Aber ich bin echt gespannt ob es wirklich "nur" an der Broadcast in der Route lag ;-) (siehe oben)

So long

ThomasF

 

[leider_admin]

Das mit den 0/1 ist mir schon klar so heißt ja z.B. das 192.168.0.0/25 eine Netzwerkmaske hat, bei der die ersten 25 Stellen von links ( 3 x 8 = 255.255.255 alle 1 , sowie die nächste Stelle = .128 == 1000 000 ) die MASKE ergeben. Diese Maske wird verwendet, um den relevaten Teil der Adresse zu extrahieren , wobei die jeweils erste Adresse = alles Nullen die Netzwerkadresse ist, und die höchste = alles Einsen (doofes Wort) die Broadcast.
Heißt aber auch: 255.255.255.128 ist gleichbedeutend mit nnnn/25

Weiß aber der Henker warum es bis Samstag noch funktioniert hat.
Die Rahmenbedingungen waren gleich, nur halt ein "altes" Suse 7.1 auch mit Samba 2.?? (müßte nachschauen) DHCP, alle Rechner (die Windosen) über feste MAC's an DHCP gebunden, nur ein Gateway auf jeder Windose == der Linux Server im eigenen SUB :roll:

Auch der etwa 2 Wochen dauernde paaralel Betrieb "alter" und "neuer" Server lief ohne nenneswerte Probleme.

Alle sonst laufenden Dienste sprich Datenbank etc. funktionieren auch ohne Probleme, nur der doofe Admin (root ? ) kann jetzt keine Fernsteuerung bei Userproblemen mehr von irgendeiner Kiste aus SUB a nach b machen, und die Windosen können nicht mehr auf dem "falschen" Server drucken ( und auf die angeschlossenen Drucker) [ gibts hier kein ICON für "Haare ausreiß" ]

Mit der Fernsteuerung könnte ich ja noch leben, aber die Drucker !!

Nur noch zur Info: sind momentan ca. 60 Windosen :roll:

Hab ja heute Mittag auch schon geschrieben, mit "route add" geht es im Prinzip, aber der Befehl funktioniert halt nur als "admin" und die USER sind nicht "admin"

 

[ThomasF]

Hi, sorry wegen dem Hinweis auf TCP/IP und Subneting aber selbst Informatiker haben da manchmal kleine Probleme ;-)

Noch mal von vorne ...

Also, die Struktur Eures Netzes ist mir klar und ist auch gar nicht so selten in der weiten Welt zu finden ;-)

Jeder Standort hat seinen eigenen WAN Zugang und seinen eigenen Server. Jedes Netz für sich macht also keine Probleme, oder ?

Weiter im Takt, die Win Rechner in Standort 2 sollen auf den Server in Standort 1 zugreifen können, und umgekehrt auch ?

Der Server in Standort 1 ist jetzt ausgetauscht worden ?
Und dort hast Du jetzt Probleme von Standort 1 drauf zugreifen zu können ?

Hast Du dem neuen Server beim Tausch die IP des alten Servers gegeben ?

Wenn ja, schau Dir mal den ARP Cache an !

Alle sonst laufenden Dienste sprich Datenbank etc. funktionieren auch ohne Probleme, nur der doofe Admin (root ? ) kann jetzt keine Fernsteuerung bei Userproblemen mehr von irgendeiner Kiste aus SUB a nach b machen

Fernsteuerung ?
Von einem Win Client in A (Standort 1) auf einen Win Client in B (Standort 2) ?

Drucken von Standort 2 auf (neuen) Server in Standort 1 ?

Wenn vorher alles funktioniert hat kann das Problem mit der Fernsteuerung nichts mit dem Server zu tun haben, denke ich.

Das Drucken allerdings schon, *grübel*

So, hast Du Dir bei den Routen jetzt mal den Weg für das Broadcast angeschaut (siehe mein erstes Posting hier zu dem Thema)
Wenn der Broadcast für das jeweils andere Netz nicht auch über das Gateway läuft kann das durchaus manche Probleme erzeugen

Mit dieser Route z.B

192.168.0.250 255.255.255.255 192.168.0.125 192.168.0.7 1
192.168.0.255 255.255.255.255 192.168.0.7 192.168.0.7 1

sollte es zwar möglich sein auf den Rechner 192.168.0.250 zuzugreifen (wenn dieser auch die Rückroute gesetzt hat ) aber es wäre nicht möglich aber auf keinen anderen Rechner in diesem Netz zumindest nicht von dem Rechner wo diese Route gesetzt ist !
Und außerdem wäre selbst der Rechner 192.168.0.250 nicht mit einem Windows Client im Netzwerk zu sehen da das Broadcast im eigenen Netz bleibt und nicht geroutet wird, soweit klar ?
Eine direkte Verbidung mit einem bestimmten TCP Port würde aber funktionieren.

Schau dir bitte noch einmal konkret für 2 Rechner die Probleme haben die Routingtabelle an ... und damit es keine Mißverständnisse gibt bitte mit -n als Option damit die Namen nicht aufgelöst werden, also unter Linux : /sbin/route -n und unter Windows route print -n (oder so )

Vor allem der neue Server ist da interessant ...

Wenn es nicht der ARP Cache und nicht die Route ist dann kann es immer noch ein Firewall Problem sein ?!

Die beiden Gateways zwischen den Standorten sind doch Linux Kisten, oder nicht, läuft dort eine Firewall (iptables / ipchains ) ?

Wenn ja schau doch mal in die Logs dort ...
Wenn nein versuch doch eine Loging Regel einzubauen und schau welche Pakete geblockt bzw. durchgelassen werden.

Du kannst aber auch zuerst z.B mit iptraf schauen ob überhaupt eine Verbindung aufgemacht wird.

Und schau auch noch mal auf den jeweiligen Standardgateways nach ob da auch die Routen ins andere Netz gesetzt sind ;-)

So long

ThomasF

 

[ThomasF]

Guten Morgen,

Dein Problem packt mich jetzt aber wirklich beim Ehrgeiz ;-) ich habe mir mal das komplette Posting ausgedruckt und Punkt für Punkt durchgesehen.

Fakt ist das Ihr bisher mit TCP redirect gearbeitet habt, das kann auch so bleiben, Du brauchst oder solltest auf den Windows Clients keine Änderungen in der Routing Tabelle machen !
Der Client "weiß" durch seine eigene IP in welchem Netz er sich befindet und braucht ansonsten nur sein Satndardgateway !

Standort 1 (192.168.0.128 / 25 ):

192.168.0.128 -> Netz
192.168.0.255 -> Broacast
x.x.x.129 bis x.x.x.254 nutzbare IPs

Gateway 192.168.0.250
Router 192.168.0.253

Die Cients in diesem Netz versuchen um zum anderen Standort zu kommen dies über das Gateway zu erreichen und bekommen vom Gateway ein redirect zum Router.

Routing von x.x.x.250 -> ist OK

Das Routing eines Win Clients ist durch das Redirect auch OK

================================================

Standort 2 (192.168.0.0 / 25 ):

192.168.0.0 -> Netz
192.168.0.127 -> Broacast
x.x.x.1 bis x.x.x.126 nutzbare IPs

Gateway 192.168.0.1
Router 192.168.0.125

Die Clients in diesem Netz versuchen um zum anderen Standort zu kommen dies über das Gateway zu erreichen und bekommen vom Gateway ein redirect zum Router.

Routing von x.x.x.1 -> ist durch die Umsetzung in Namen nicht wirklich zu erkennen ... bitte mit route -n ausgeben lassen.

Auf jeden Fall ist dies problematisch :

Destination Gateway Genmask Flags Metric Ref Use Iface
ntd * 255.255.255.128 U 0 0 0 eth0
ntd egf-route.ntd 255.255.255.128 UG 0 0 0 eth0

Du hast dort eine wiedersprüchliche Route selbst wenn das Netz ntd heißt bleibt es für den ersten Eintrag local und beim zweiten soll es geroutet werden ???

Das Routing eines Win Clients in diesem Netz (siehe oben von 192.168.0.7 ) ist nicht korrekt.

Sollte sein:

Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.7     1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1     1
      192.168.0.0  255.255.255.128      192.168.0.7     192.168.0.7     1
      192.168.0.7  255.255.255.255        127.0.0.1       127.0.0.1     1
    192.168.0.0  255.255.255.255    192.168.0.125     192.168.0.7     1
    192.168.0.127  255.255.255.255      192.168.0.7     192.168.0.7     1
        224.0.0.0        224.0.0.0      192.168.0.7     192.168.0.7     1
  255.255.255.255  255.255.255.255      192.168.0.7     192.168.0.7     1
Standardgateway:       192.168.0.1

Selbst wenn Windows den Broadcast nicht richtig setzt solltest Du beim redirect nicht richtig setzt solltest Du das ganze Netz routen und nicht nur die x.x.x.250 ... siehe auch -> http://de.wikipedia.org/wiki/Broadcast

Wenn Du auf den Windows Clients keinen permanenten Routen gesetzt hast sollte ein Reboot alle fehlerhaften Routen beseitigen wenn Du die Routen auf Deinem Gateway in diesem Netz geändert hast .

Kleiner Tip: Die Namensauflösung ist nicht eindeutig und vor allem in beiden Netzen unterschiedlich.

Den ganzen Ärger hättest Du Dir wahrscheinlich sparen können wenn Du für die Netze 192.168.0.x und 192.168.1.x /24 genommen hättest ;-)

So long

ThomasF

 

[leider_admin]

Nur zur Erklärung:
Der alte Server in Standort "1" hatte die IP 192.168.0.129 = die erste freie IP in diesem SUB, der hatte auch einen anderen Namen = WV_PDC (schön selbsterklärend oder ), IP und Name des neuen Rechners sind alleine schon deshalb anders, damit ich (nachts) die Nutzdaten von einer Mühle auf die andere kopieren konnte.
Samba war auf der neuen Kiste solange zum BDC degradiert.

Dann dein Post von gestern Abend:

Also, die Struktur Eures Netzes ist mir klar und ist auch gar nicht so selten in der weiten Welt zu finden
ThomasF

Und ich wollte das schon zum PATENT anmelden

EDIT
Dann die Ausgabe vom 192.168.0.1 mit route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.128 U     0      0        0 eth0
192.168.0.128   192.168.0.125   255.255.255.128 UG    0      0        0 eth0
82.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 ippp0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         82.207.159.1    0.0.0.0         UG    0      0        0 ippp0

EDIT
Der vollständigkeit halber die Ausgabe vom 192.168.0.250 mit route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     192.168.0.253   255.255.255.128 UG    0      0        0 eth0
192.168.0.128   0.0.0.0         255.255.255.128 U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.2     0.0.0.0         UG    0      0        0 eth1

Ich kann da nicht wirklich einen Unterschied feststellen [im relevanten Teil], oder übersehe ich etwas ??

Vielleicht sollte ich am Wochende erst mal tauchen gehen, unter DRUCK arbeitet das Gehirn (sofern vorhanden) ja bekanntlich besser ( oder habe ich da schon wieder was falsch verstanden :roll: ) [siehe mein Profil zur Erklärung ]

 

[leider_admin]

Das Problem mit dem Drucken habe ich mittlerweile gelösst

[wer lesen kann ist klar im Vorteil ] == zeigen die Windosen ja im Klartext in der Druckereinstellung an

Man sollte auf den Kisten an Standort "2" natürlich auch den "neuen" Server als Printserver verwenden !!!!!!
Ich habe schlichtweg vergessen den Logon script für die Windosen auf Standort "2" auch zu ändern.

 

[ThomasF]

Ummmpf,

naja, wie sagt man so schön : "Viel Rauch um nichts" ... ;-)

Bleibt aber immer noch die Fehlermeldung vom Anfang mit dem ... ignore redirect ... oder hat sich das auch schon erledigt ???

Vollständigkeitshalber kannst Du ja noch die Routingtabelle von den beiden Routern posten ..

So long

ThomasF

 

[leider_admin]

Wieso erledigt???????????????????
Bleibt immer noch das Problem, kann aus Standort "1" nicht audf die Windosen Standort "2" und andersrum zugreifen.
Das mit den Druckern regelt ja Samba in Form von PDC >< BDC

Dann die Routingtabellen der Router:
von 192.168.0.253

inx Dest(*rw)         IfIndex(rw)       Metric1(rw)       Metric2(rw)
    Metric3(rw)       Metric4(rw)       NextHop(rw)       Type(-rw)
    Proto(ro)         Age(rw)           Mask(rw)          Metric5(rw)
    Info(ro)

 00 192.168.0.128     1000              0                 -1
    -1                0                 192.168.0.253     direct
    local             9512266           255.255.255.128   469762048
    .0.0

 01 192.168.0.0       3000              1                 -1
    -1                1                 0.0.0.0           indirect
    local             9512266           255.255.255.128   469762048
    .0.0

 02 192.168.0.0       10001             1                 -1
    -1                1                 192.168.0.253     indirect
    local             9512266           255.255.255.128   469762048
    .0.0

und von 192.168.0.125

inx Dest(*rw)         IfIndex(rw)       Metric1(rw)       Metric2(rw)
    Metric3(rw)       Metric4(rw)       NextHop(rw)       Type(-rw)
    Proto(ro)         Age(rw)           Mask(rw)          Metric5(rw)
    Info(ro)

 00 192.168.0.0       1000              0                 -1
    -1                0                 192.168.0.125     direct
    local             8226332           255.255.255.128   469762048
    .0.0

 01 192.168.0.128     3000              1                 -1
    -1                1                 0.0.0.0           indirect
    local             8226332           255.255.255.128   469762048
    .0.0

 02 192.168.0.128     10001             1                 -1
    -1                1                 192.168.0.125     indirect
    local             8226332           255.255.255.128   469762048
    .0.0

Ich weiß nicht sehr Aussage kräftig sind BINTEC Router von unserem Provider

EDIT
PS: kann an den Einstellungen der Router nichts verändern, da ersten kein Handbuch und zweitens die Dingen gehören nicht uns = keine Admin Rechte :x

 

[ThomasF]

Ich hatte gefragt, ob es sich erledigt hat !!!
Das war keine Feststellung ...

Da das routing aber jetzt scheinbar funktioniert, oder besser die ganze Zeit funktioniert hat ;-) stellt sich die Frage woran könnte es liegen.

Womit machst Du den die Fernwartung ?
Weißt Du welche Ports dabei genutzt werden ?

Ist es ein Problem mit der Namensauflösung, funktioniert es mit der IP ?
Wie äußert sich der Fehler ? Timeout, Fehlermeldung

Was bekommst wenn Du von einem Rechner ein tracert in das andere Netz machst ?

Kannst Du evt. eine personal Firewall oder Etheral dafür benutzen rauszubekommen was während des Versuches einer Verbindung passiert ???

So long

ThomasF

 

[leider_admin]

Zitat aus dem ersten Beitrag

folgendes Problem:
von den Servern xxx.1 / xxx.250 sind alle Rechner in beiden Subs per Ping zu erreichen.
alle Rechner aus beiden Subs tauchen in der Netzwerkumgebung unter Windoofs auf.
Kein Rechner im anderen Sub läßt sich per Ping bzw. über den Explorer erreichen.
Von den Servern aus geht es ins jeweils andere Netzwerk ohne Probleme.

hab mal einen Teil der /var/log/messages angefügt ( nur die negativ Einträge )


Code:

Jan 9 13:48:13 serp1 kernel: host 192.168.0.133/if3 ignores redirects for 192.168.0.125 to 192.168.0.253.
Jan 9 13:58:12 serp1 kernel: host 192.168.0.133/if3 ignores redirects for 192.168.0.125 to 192.168.0.253.
Jan 9 14:08:11 serp1 kernel: host 192.168.0.133/if3 ignores redirects for 192.168.0.125 to 192.168.0.253.
Jan 9 14:18:10 serp1 kernel: host 192.168.0.133/if3 ignores redirects for 192.168.0.125 to 192.168.0.253.
Jan 9 14:28:09 serp1 kernel: host 192.168.0.133/if3 ignores redirects for 192.168.0.125 to 192.168.0.253.


beim 192.168.0.133 handelt es sich um einen Windows Rechner!

das ist eigendlich immer noch das Problem !

Das Thema mit den Druckern ist nur aufgefallen, weil ein User aus Standort "2" eine Datei bei mir drucken wollte und das nicht ging. Hab dann voreilig beides in einen Topf geworfen (ist halt einfacher als sich jedesmal neue Gedanken zu machen .

Die Fernwartung mach ich mit VNC > aber eigendlich geht ja schon ein Ping nicht. Port muß ich gestehen weiß ich nichtmal, da bisher nie benötigt und mich auch nicht wirklich interressiert hat ( war das jetzt ein auting :?: :idea: )
Nur um auch hier Mistverständnisse aus zu räumen, habe momentan bei mir (Standort "1" ) auf der Windose die Route mit route add manuell gesetzt, dann kann ich die Rechner in Standort "2" auch erreichen, aber nur direkt über die IP Adresse.

Schau:

C:\>ping egf_pc6
Ping-Anforderung konnte Host "egf_pc6" nicht finden. Überprüfen Sie den Namen, u
nd versuchen Sie es erneut.

C:\>ping 192.168.0.7

Ping wird ausgeführt für 192.168.0.7 mit 32 Bytes Daten:

Antwort von 192.168.0.7: Bytes=32 Zeit=4ms TTL=125
Antwort von 192.168.0.7: Bytes=32 Zeit=3ms TTL=126
Antwort von 192.168.0.7: Bytes=32 Zeit=3ms TTL=126
Antwort von 192.168.0.7: Bytes=32 Zeit=3ms TTL=126

Ping-Statistik für 192.168.0.7:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 3ms, Maximum = 4ms, Mittelwert = 3ms

Der gleiche Befehl ( ping -c4 egf_pc6 ) auf dem Server Standort "1" (ist das selbe Sub)

PING egf_pc6.ntd (192.168.0.7) 56(84) bytes of data.
64 bytes from egf_pc6.ntd (192.168.0.7): icmp_seq=1 ttl=126 time=4.04 ms
64 bytes from egf_pc6.ntd (192.168.0.7): icmp_seq=2 ttl=126 time=4.01 ms
64 bytes from egf_pc6.ntd (192.168.0.7): icmp_seq=3 ttl=126 time=4.07 ms
64 bytes from egf_pc6.ntd (192.168.0.7): icmp_seq=4 ttl=126 time=4.01 ms

--- egf_pc6.ntd ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 4.011/4.036/4.075/0.026 ms

und füg bitte in die "Smilies" jetzt unbedingt ein "Haare ausreißen" ein.

 

[Anonymous]

hi,
interressiert verfolge ich diesen tread, wobei ich folgendes nachstellen kann :

client1(192.168.0.2/25) <--> (192.168.0.1/25)server(192.168.0.129/25) <--> client2(192.168.0.130/25)

solbald ich masq auf dem Server für 192.168.0.*/25 ausschalte bekomme ich "ignores redirects" in die messages, was ja auch logisch ist da client1(192.168.0.2) zwar auf 192.168.0.1 kommt jedoch diese packete in einen anderem netz(192.168.0.129/25) natürlich nichts verloren haben.
Vom server komme ich aber noch immer in beide netze !

Fazit: bei einer reinen FORWARD chain komme ich egal mit welcher route nicht von client1 auf client2!

Wenn ich masq der packete verwende laeft folgendes korrekt ab:
client1(192.168.0.2/25) kommt auf (192.168.0.1/25) dort werden die packete auf 192.168.0.129 masqueradet und können somit im fremdnetz auf 192.168.0.130!

Fazit: kann es den sein das am alten server masq aktiv war und jetzt am neuen server nicht ?
Könnte man ja eventuell mit `iptables -nL -t nat` pruefen!?

Sollte ich falsch liegen bitte nicht Kopf abreissen

Mƒg ®êïñï

 

[ThomasF]

Hmm,

das erste das mir dazu einfällt ist Namensauflösung -> DNS

Habt Ihr einen DNS bzw. war der alte Server vielleicht der DNS und der neue ist einer, aber der DHCP verteilt die falsche Adresse für den DNS ???

Überprüfe auf den Clients mit ipconfig /all ob auf dem Rechner ein DNS eingetragen ist und wenn ja welcher.
Bei Verteilung über DHCP steht der Eintrag in der dhcp.conf genau wie die Domain.

z.B so :

option domain-name-servers 192.168.0.250;
option domain-name "ntd";

Was Deine Pings angeht probierte bitte "systematisch" welcher geht und welcher nicht z.B nur Hostname, Hostname.Domain, IP

Du hast, oder so sieht es zumindest aus, die Varianten wild gemischt. Für mich sieht es so aus als wenn die reine IP immer funktioniert, genau wie Hostname.Domain und nur der Hostname alleine nicht ?!?

Somit funktioniert der Ping aber Grundsätzlich im Gegensatz zu Deiner Aussage, ohne Probleme.

VNC läuft entweder auf 5800 oder 5900 über UDP
Siehe auch -> http://www.dbo812.de/doks/vnc.html

Falls VNC nicht geht, wobei Du natürlich schauen solltest ob die VNC Server bei Euch auch wirklich auf den Standardport laufen ....

Moment mal ... verwendest Du einen VNC Client oder nimmst Du dafür einen Browser ???
Wenn Du einen Browser nimmst schreibe zum Test den jeweiligen Zielrechner "deffiniv mit IP " in die Proxyausnahmen Deines Browsers !!!

Wenn es das nicht war, teste bei einem Client auf dem Du geprüft hast das der VNC auch läuft und auf welchem Port er läuft ob Du diesen ereichen bzw. verbinden kannst ... sowohl mit dem VNC-Client als auch mit dem Browser mit IPort

Und dann schaun wir mal weiter

So long

ThomasF

 

[ThomasF]

@reini123

Kopf abgerissen wird hier nicht, keine Bange *gg*

Aber wenn ich leider_admin richtig verstanden habe sind die beiden Standorte mit reinen Routern verbunden. (vermutlich 1 zu 1 Direktverbindung und nicht über das Internet )

Ein reiner Router beherrscht bzw. braucht aber kein masq.

Den Paketen ist das egal in welchen Netz sie sich befinden ;-)
Du kannst Deiner Netzwerkkarte ja auch sagen sie soll mit noch einer zweiten IP in einem ganz hängen. Das ist völlig problemlos ...

Masq brauchst Du haupsächlich beim Übergang von LAN nach WAN wenn Du nur eine "offizielle" IP hast.

So long

ThomasF

 

[leider_admin]

Dann halt nochmal:

auf meinem Rechner (192.168.0.130)
1. Ping hostname > geht nicht
2. Ping hostname.Domain geht nicht
3. Ping IP > geht

wenn ich mit route add das Gateway gesetzt habe.

ohne gesetzte Route
1. Ping hostname > geht nicht
2. Ping hostname.Domain geht nicht
3. Ping IP > geht nicht
aber die Namen (egf_pc6 z.B.) werden in IP aufgelößt.

Auf dem Server (192.168.0.250)
ping hostname > geht
ping hostname.domain > geht
Ping IP > geht

 

[Anonymous]

Hi,
das erleichtert mich natuerlich wenn mir nicht gleich der kopf abgerissen wird
Ich kann das trotzdem nicht ganz nachvollziehen das es den Packeten egal ist in welchen netz sie sich befinden :shock:
Die beiden testclients reden nicht mal miteinander wenn ich sie per2per mit einen gekreuzten kabel verbinde (192.168.0.1/25 <--> 192.168.0.130/25 ) also ohne router! Trotz route anpassen auf das gegenüber !
Jedenfalls bei meinen versuch mit forward zwischen verschiedenen netzen kommt diese ignore redirekts meldung und mit nat geht´s.
Vieleicht ist ja auch mein Aufbau fehlerhaft :roll:
Naja dann hab ich da wohl was falsch verstanden ... macht ja auch nichts

Mƒg ®êïñï

 

[leider_admin]

zu reini123
Ich glaube nicht das du das OHNE Hardware (oder Software ) Router nachvollziehen kanst.

Hatte hier mal eine Windose aus dem "falschen" Sub, erfolg: Der findet nicht mal seinen SAMBA oder sonst was .............
heißt er kriegt niemals einen Connect auch nicht mit PING.

 

[ThomasF]

@leider_admin

Ok, habt Ihr jetzt einen DNS Server oder nicht ?

Und da Du eine Antwort bekommst kennt der Rechner im anderen Netz ja auch den Rückweg ...

Falls Du eine permanente Route eingetragen hast, bitte rausnehmen und dann Deinen Rechner neu booten (x.x.x.130)

Ist es 2000 oder XP ?

Durchsuche die Registry nach EnableICMPRedirect .. ist der Wert 1 ?

Wenn Du neu gebootet hast bitte Ausgabe von ipconfig / all und route -n posten.

Schau Dir bitte auch arp -a an und merk Dir welche Rechner da schon drinstehen.

Dann probiere bitte die verschiedenen Pings und auch tracert.

Wenn nichts funktioniert schau auf dem Gateway in die Logs.

Wieviele Haare hast Du den noch auf dem Kopf ;-)
Lohnt es sich überhaupt noch ein Icon dafür zu erstellen ???

Bis denne

ThomasF