bschap 10 Geschrieben 8. November 2012 Melden Teilen Geschrieben 8. November 2012 (bearbeitet) Hallo, in meinem Netzwerk tritt neuerdings ein merkwürdiges Problem auf. Ich schildere erstmal kurz die Struktur in meiner Firma. Wir haben zwei Standorte mit unterschiedlichen Subnetzen und zwei unterschiedlichen Domänen / Gesamtstrukturen. Verbunden dauerhaft per VPN. Letzte Woche wurde die Domäne an Standort 2 aufgelöst und die Clients / Server von dort in die Domäne von Standort 1 aufgenommen. Der alte DC wurde zurückgestuft, in die neue Domäne aufgenommen und dann zum 2. DC in der Domäne promoted. Soweit hat auch alles funktioniert. Nun zum Problem: Um Daten von einem Kunden zu holen, wird normalerweiser von Standort 2 eine sftp-Verbindung zum Kunden aufgebaut. Dies funktioniert jetzt nicht mehr. Die Clients sind immer noch im selben Subnetz und haben die selbe IP. telnet von Standort 2 auf die Kunden-IP mit Port 22 schlägt fehl. telnet von Standort 1 auf die Kunden-IP mit Port 22 klappt. telnet von Standort 2 auf irgendeine IP mit offenem Port 22 klappt auch. Laut Kunde wird aber seinerseits nicht geblockt, was aus unserem Netz kommt. Gruppenrichtlinien können es eigentlich auch nicht sein, weil ja die GPOs der neuen Domäne (Standort 1) jetzt gelten und mit ebendieser die Verbindung ja klappt. Das Einzige, dass sich meines Wissens nach geändert hat, sind die FQDN der Rechner. Ich bin momentan ziemlich ratlos und für jede Hilfe dankbar. bearbeitet 8. November 2012 von bschap Schreibfehler Zitieren Link zu diesem Kommentar
wannabee 10 Geschrieben 9. November 2012 Melden Teilen Geschrieben 9. November 2012 Hallo bschap, was sagen denn die Router zwischen Standort 2 und Standort 1? Wenn eine Workstation ins Netz geht, wie sieht der Weg aus? Wird der gesamte Traffic über Standort 1 geleitet? Was sagen eure Firewalls zwischen Standort 1 und Standort 2 - und besonders die Firewall, die für den Internet-Zugang zuständig ist? Hier würde ich zum Suchen anfangen. Zitieren Link zu diesem Kommentar
bschap 10 Geschrieben 9. November 2012 Autor Melden Teilen Geschrieben 9. November 2012 Erst einmal danke für die Denkanstösse. Traffic geht für jeden Standort separat raus. Wir haben an jedem Standort einen Router von der Telekom. Die bauen die VPN-Verbindung zwischen einander auf und dienen als Gateway ins Internet. Konfiguration erfolgt seitens der Telekom. Auf Nachfrage, ob dort irgendwas geblockt sein könnte, wurde gesagt, dass die Firewalls Port 22 nicht blocken. Ich kann leider nicht selbst drauf schauen. tracert auf die Problem-IP funktioniert auch von beiden Standorten (bis zur Firewall des Kunden). Ich schau mir jetzt nochmal genau unsere Firewall an. Bei VPN-Verbindung zwischen zwei Standorten innerhalb einer Domäne greift doch die Domänenfirewall und nicht die öffentliche, oder? Zitieren Link zu diesem Kommentar
bschap 10 Geschrieben 13. November 2012 Autor Melden Teilen Geschrieben 13. November 2012 Update: Liegt wohl wirklich irgendwo an meiner Domäneneinstellung. Ich bekomme von telnet immer Verbindungsfehler wenn ich eine IP mit (offenem) Port 22 angebe. Komischerweise funktioniert aber weiterhin telent auf die Kunden-IP von Standort 1 aus. Zitieren Link zu diesem Kommentar
bschap 10 Geschrieben 27. November 2012 Autor Melden Teilen Geschrieben 27. November 2012 Ich finde es einfach nicht. Fällt jemanden eine GPO ein, die das eventuell verhindert? Oder irgendeine versteckte Einstellung, die so nicht gleich ersichtlich ist? Zitieren Link zu diesem Kommentar
NeMiX 76 Geschrieben 27. November 2012 Melden Teilen Geschrieben 27. November 2012 Mach doch mal einen Gruppenlinienergebnisssatz und schau dir das an. Hast du Windows Firewall Settings in einer GPO konfiguriert? Zitieren Link zu diesem Kommentar
bschap 10 Geschrieben 4. Dezember 2012 Autor Melden Teilen Geschrieben 4. Dezember 2012 Für die Firewall sind keine GPOs eingerichtet. Habe jetzt mal RSOP auf zwei betroffenen Rechnern gemacht und mit RSOP von zwei funktionierenden Rechner (jeweils 1 Server und 1 Workstation) verglichen. Keine Unterschiede. Zitieren Link zu diesem Kommentar
bschap 10 Geschrieben 17. Dezember 2012 Autor Melden Teilen Geschrieben 17. Dezember 2012 Okay es hat sich erledigt. Die Telekom hatte doch den Port 22 in unseren Routern geblockt. Ein Mitarbeiter hatte an Standort 2 Konfigurationsänderungen vorgenommen und dabei den Port 22 "mal rausgenommen" :suspect: Nach mehrmaligem Nachfragen wurde das jetzt doch entdeckt und zugegeben und nun, oh Wunder oh Wunder, funktionieren ssh und damit auch sftp wieder. :) Vielen Dank für die Hilfe. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.