Willkommen im #Neuland
Login wie bei quake.ingame.de zuvor, die Passwörter aus der alten Datenbank wurden aber gelöscht - einmal hier neu anfordern.
Wer seine E-Mail-Adresse nicht mehr hat oder kennt, bitte eine Nachricht mit Infos schicken o. im Discord melden.
PQ Discord Server: #planetquake Spenden? Hier entlang!
Login wie bei quake.ingame.de zuvor, die Passwörter aus der alten Datenbank wurden aber gelöscht - einmal hier neu anfordern.
Wer seine E-Mail-Adresse nicht mehr hat oder kennt, bitte eine Nachricht mit Infos schicken o. im Discord melden.
PQ Discord Server: #planetquake Spenden? Hier entlang!
Strato Server nicht mehr erreichbar nach vergeblicher VPN-Installation
-
- Capture
- Beiträge: 6219
- Registriert: Nov 2006
Strato Server nicht mehr erreichbar nach vergeblicher VPN-Installation
Hey!
Hab heute versucht, auf dem STrato Win 2003 WE Server eine VPN-Verbindung über die Serververwaltung zu installieren, dabei is folgendes passiert:
deaktiv. ras -> aktivieren und konf. ras -> vpn -> Absturz des Servers
Neustart des Servers hat nichts geholfen - man kann den Server nicht mehr über Remotedesktop ansprechen.
Seitdem ist der Server nur noch über SSH erreichbar, anpingen kann man ihn auch nicht, er verhält sich, als ob er nicht mehr im netz ist. (ip wäre: 85.214.140.219)
wichtig ist vor allem die remotedesktopverbindung weil wir darüber auf dem Server arbeiten.
ich habe schon im ssh über PuTTy geguckt und einige Befehle ausprobiert.
über cmd -> ch -> ch -si 1 kann man sich dann auf den server ins windows einloggen, aber bleibt in der shell. befehle wie ipconfig usw sind möglich.
ein deaktivieren und erneutes aktivieren der rdv brachte nix, die ip adressen sind ok, verstehe nicht, wieso man nicht auf den server raufkommt!
backup ist mit diskpart über das beschissenste rescuesystem von strato möglich aber wäre die allerletzte möglichkeit...
helft mir, rund vllt?
Hab heute versucht, auf dem STrato Win 2003 WE Server eine VPN-Verbindung über die Serververwaltung zu installieren, dabei is folgendes passiert:
deaktiv. ras -> aktivieren und konf. ras -> vpn -> Absturz des Servers
Neustart des Servers hat nichts geholfen - man kann den Server nicht mehr über Remotedesktop ansprechen.
Seitdem ist der Server nur noch über SSH erreichbar, anpingen kann man ihn auch nicht, er verhält sich, als ob er nicht mehr im netz ist. (ip wäre: 85.214.140.219)
wichtig ist vor allem die remotedesktopverbindung weil wir darüber auf dem Server arbeiten.
ich habe schon im ssh über PuTTy geguckt und einige Befehle ausprobiert.
über cmd -> ch -> ch -si 1 kann man sich dann auf den server ins windows einloggen, aber bleibt in der shell. befehle wie ipconfig usw sind möglich.
ein deaktivieren und erneutes aktivieren der rdv brachte nix, die ip adressen sind ok, verstehe nicht, wieso man nicht auf den server raufkommt!
backup ist mit diskpart über das beschissenste rescuesystem von strato möglich aber wäre die allerletzte möglichkeit...
helft mir, rund vllt?
Lieber toter Rapper als lebender Singer/Songwriter!
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
Ich komme nicht per SSH drauf....
Hat er denn noch die richtige IP?
Sprich wenn du ipconfig /all eingibst, wird dann noch die 85.214.140.219 angezeigt?
was passiert wenn du einen tracert auf http://www.google.de ausführst, was wenn du die 74.125.39.99 nimmst?
Hat er denn noch die richtige IP?
Sprich wenn du ipconfig /all eingibst, wird dann noch die 85.214.140.219 angezeigt?
was passiert wenn du einen tracert auf http://www.google.de ausführst, was wenn du die 74.125.39.99 nimmst?
-
- Capture
- Beiträge: 6219
- Registriert: Nov 2006
das ist das ergebnis über ssh mit ipconfig /all und tracert. tracert bringt nix, wie du siehst...Knotentyp . . . . . . . . . . . . : Unbekannt
IP-Routing aktiviert . . . . . . : Ja
WINS-Proxy aktiviert . . . . . . : Ja
DNS-Suffixsuchliste . . . . . . . : STRATOSERVER.NET
Ethernet-Adapter Local Area Connection:
Verbindungsspezifisches DNS-Suffix: stratoserver.net
Beschreibung . . . . . . . . . . : Intel(R) PRO/1000 PL Network Connection
Physikalische Adresse . . . . . . : 00-21-85-FA-8F-9A
DHCP aktiviert . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
IP-Adresse. . . . . . . . . . . . : 85.214.140.219
Subnetzmaske . . . . . . . . . . : 255.255.255.255
Standardgateway . . . . . . . . . : 85.214.128.1
DHCP-Server . . . . . . . . . . . : 81.169.163.105
DNS-Server . . . . . . . . . . . : 81.169.163.106
85.214.7.22
81.169.148.34
NetBIOS über TCP/IP . . . . . . . : Deaktiviert
Lease erhalten . . . . . . . . . : Freitag, 10. April 2009 06:07:02
Lease läuft ab . . . . . . . . . : Freitag, 10. April 2009 12:10:22
C:\>tracert http://www.google.de t
Unable to resolve target system name http://www.google.de.
C:\>
C:\>tracert 74.125.39.99
Tracing route to 74.125.39.99 over a maximum of 30 hops
1 Destination host unreachable.
Trace complete.
C:\>
Lieber toter Rapper als lebender Singer/Songwriter!
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
Ja ne ist klar, Subnetzmaske 255.255.255.255...Original geschrieben von sim^^on
das ist das ergebnis über ssh mit ipconfig /all und tracert. tracert bringt nix, wie du siehst...
Ich versteh zwar noch nicht, wie du da auf den Server kommst, aber die Subnetzmaske ist auf jeden Fall schrott. Die Frage ist, welche Daten die richtigen sind. Evtl. hast du irgendwann mal einen Zettel mit Zugangsdaten vom Provider bekommen, auf dem die korrekten Daten stehen, dann musst du die eben wiederherstellen. Falls nicht und dein Provider die IP-Daten komplett über DHCP zuteilt, probier mal einen Refresh der Daten über "ipconfig /renew". Wenn das auch nicht hilft musst du irgendwie ins selbe Subnetz wie dein Default-Gateway kommen, aber dafür gibt es mehrere Möglichkeiten. Wenn ich in RIPE die Ranges für Strato durchsehe finde ich keinen konfigurierbaren Netzbereich (außer dem großen /16-Netz), also kann ich nur raten.
Davon ausgehen, dass der Default-Gateway die erste IP im Netz bekommen hat gibt es folgende mögliche Masken:
85.214.140.219 255.255.240.0
85.214.140.219 255.255.224.0
85.214.140.219 255.255.192.0
85.214.140.219 255.255.128.0
Mit allen müsstest du ins Netz kommen, aber nur bei einer reagierst der Server korrekt auf Broadcast-Anfragen. Welche die richtige ist könntest du daran erkennen, bei welchem Ping dir mehrere Nachbarserver antworten:
ping 85.214.143.255 (255.255.240.0)
ping 85.214.159.255 (255.255.224.0)
ping 85.214.191.255 (255.255.192.0)
ping 85.214.255.255 (255.255.128.0)
Das würde ich dann einfach beginnend mit der kleinsten Maske austesten.
Das Ändern der IP müsste lt. Google über "netsh int ip set address "local area connection" static <IP> <MASK> <DG> <METRIC>" funktionieren, wobei Metric auf 1 bleiben kann.
-
- Capture
- Beiträge: 6219
- Registriert: Nov 2006
also: ipconfig /renew gibt folgenden fehler aus: keine verbindung zum dhcp server.
der wechsel zu allen vier subnetzmasken brachte auch keinen erfolg. weder konnte ich die pings erfolreich ausführen (100% loss) noch funktionierte der RDV-Aufbau.
Die suche im Internet nach der Strato Subnetzmaske ergibt aber wohl auch 255.255.255.255...scheint also korrekt zu sein.
da ich dir in soweit vertraue, kann ich dir aber auch eben die zugangsdaten zum kundenbereich bei strato und somit die daten für ssh geben, du kennst dich scheinbar besser aus.
wenn du zeit hast, könntest du ja mal versuchen, das problem zu beheben??
wie gesagt, hauptaugenmerk ist halt die RDV wieder zum laufen zubekommen...
¤: hier hat jemand das gleiche problem gehabt. wohl bei nem linux betriebssystem, aber der fehler äussert sich gleich.
http://serversupportforum.de/forum/serv ... chbar.html
dumm nur, dass ich kaum was von linux verstehe. kannst du da was rauslesen? ich sehe nur, das 255.255.255.255 wohl die richtige subnetzmaske zu sein scheint...
route PRINT liefert:
¤¤: die umstellung auf dhcp ergibt folgendes
der dhcp server ist aber immer noch nicht erreichbar. ebensowenig kann ich den standart-gw anpingen. auch die dns-server sind nicht erreichbar, lediglich ein lokaler ping ist möglich...
der wechsel zu allen vier subnetzmasken brachte auch keinen erfolg. weder konnte ich die pings erfolreich ausführen (100% loss) noch funktionierte der RDV-Aufbau.
Die suche im Internet nach der Strato Subnetzmaske ergibt aber wohl auch 255.255.255.255...scheint also korrekt zu sein.
da ich dir in soweit vertraue, kann ich dir aber auch eben die zugangsdaten zum kundenbereich bei strato und somit die daten für ssh geben, du kennst dich scheinbar besser aus.
wenn du zeit hast, könntest du ja mal versuchen, das problem zu beheben??
wie gesagt, hauptaugenmerk ist halt die RDV wieder zum laufen zubekommen...
¤: hier hat jemand das gleiche problem gehabt. wohl bei nem linux betriebssystem, aber der fehler äussert sich gleich.
http://serversupportforum.de/forum/serv ... chbar.html
dumm nur, dass ich kaum was von linux verstehe. kannst du da was rauslesen? ich sehe nur, das 255.255.255.255 wohl die richtige subnetzmaske zu sein scheint...
route PRINT liefert:
Code: Alles auswählen
IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 21 85 fa 8f 9a ...... Intel(R) PRO/1000 PL Network Connection
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 85.214.128.1 85.214.140.219 1
85.214.140.0 255.255.255.0 85.214.140.219 85.214.140.219 20
85.214.140.219 255.255.255.255 127.0.0.1 127.0.0.1 20
85.255.255.255 255.255.255.255 85.214.140.219 85.214.140.219 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 85.214.140.219 85.214.140.219 20
255.255.255.255 255.255.255.255 85.214.140.219 85.214.140.219 1
Default Gateway: 85.214.128.1
===========================================================================
Persistent Routes:
None
Code: Alles auswählen
C:\>route print
IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 21 85 fa 8f 9a ...... Intel(R) PRO/1000 PL Network Connection
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 85.214.128.1 85.214.140.219 20
85.214.128.1 255.255.255.255 85.214.140.219 85.214.140.219 1
85.214.140.219 255.255.255.255 127.0.0.1 127.0.0.1 20
85.255.255.255 255.255.255.255 85.214.140.219 85.214.140.219 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 85.214.140.219 85.214.140.219 20
255.255.255.255 255.255.255.255 85.214.140.219 85.214.140.219 1
Default Gateway: 85.214.128.1
===========================================================================
Persistent Routes:
None
Lieber toter Rapper als lebender Singer/Songwriter!
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
Hi,
sende mir mal die Zugangsdaten per PM, ich schau mir das dann heut Abend mal an, wenn ich von meiner Oma ( ) zurück bin.
¤dit: Wenn du noch etwas selbst testen willst, kannst du ja mal dem Ratschlag von dem von dir geposteten Link folgen und die Gateway-IP als deine Server-IP eintragen. Das wird zwar eigentlich nur bei PPP-Verbindungen genutzt, aber wer weiß was Strato da gebastelt hat. Die anderen Einstellungen müssten dann passen, aber du musst unbedingt das /32-er Netz beibehalten, damit der Server nicht auf ARP-Requests von anderen Rechnern im Netz reagiert, wenn die Strato-Umsetzung doch anders ist.
sende mir mal die Zugangsdaten per PM, ich schau mir das dann heut Abend mal an, wenn ich von meiner Oma ( ) zurück bin.
¤dit: Wenn du noch etwas selbst testen willst, kannst du ja mal dem Ratschlag von dem von dir geposteten Link folgen und die Gateway-IP als deine Server-IP eintragen. Das wird zwar eigentlich nur bei PPP-Verbindungen genutzt, aber wer weiß was Strato da gebastelt hat. Die anderen Einstellungen müssten dann passen, aber du musst unbedingt das /32-er Netz beibehalten, damit der Server nicht auf ARP-Requests von anderen Rechnern im Netz reagiert, wenn die Strato-Umsetzung doch anders ist.
-
- Capture
- Beiträge: 6219
- Registriert: Nov 2006
dein postfach is voll
Ich habe grade mit dem befehl: netsh int ip set address "local area connection" source=static 85.214.128.1 255.255.255.0 85.214.128.1 1 mal die IP auf die des gateways geändert, seitdem komme ich auch nicht mehr auf die serielle konsole
werde den server jetzt mal neustarten, damit ich wenigtens wieder in die serielle console komme!
Ich habe grade mit dem befehl: netsh int ip set address "local area connection" source=static 85.214.128.1 255.255.255.0 85.214.128.1 1 mal die IP auf die des gateways geändert, seitdem komme ich auch nicht mehr auf die serielle konsole
werde den server jetzt mal neustarten, damit ich wenigtens wieder in die serielle console komme!
Lieber toter Rapper als lebender Singer/Songwriter!
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
Sooooooo, jetzt geht's erstmal wieder, ich konnte mich erfolgreich über die RDV einloggen.
Ich hab jetzt viel an der Config herumgefummelt (und dabei auch viel gelernt), deswegen kann ich jetzt nicht 100%tig genau sagen, woran es letztendlich lag, aber die IP-Config war auf jeden Fall falsch und zumindest auch teilweise die Firewallregeln.
Thema IP-Config:
----------------------
Aus der bestehenden Firewallconfig konnte ich sehen, dass die korrekte IP-Adresse die 85.214.140.219 255.255.255.255 ist.
Da mir der DHCP-Server keinen DG liefert habe ich hier nochmal die eigene IP hinterlegt (wie bei PPP-Verbindungen, warum auch immer...).
Thema Firewall:
---------------------
Du hattest in der Firewall vermutlich nur die TCP/UDP-Ports 47 (GRE), 500 (ISAKMP), 1701 (L2TP), 1723 (PPTP) und 4500 (IPSec) freigegeben. Damit verbietest du DNS, SSH und vermutlich auch ICMP (Ping/Tracert). Windows Remote-Desktop hätte soweit ich das in Google sehe TCP 3389. Ich hab die Firewallregeln jetzt gelöscht, da ich vermute, dass die bei der Einrichtung des RAS-Servers fälschlicherweise angelegt wurden. Wenn du die Regeln noch brauchst habe ich die letzte Config unter C:\Windows\System32\netsh.log und die aktuelle Config unter netsh3.log gespeichert. netsh2.log ist ein Zwischenstep und kann gelöscht werden. Ich kann aber nicht 100%tig sagen, dass die Firewallregeln gegriffen haben, da ich die falsche IP-Config erst im Anschluss geändert habe und die Regeln nicht wieder hinzufügen wollte (Die Zeilen sind ellenlang und Copy-Paste funzt nicht über die Console). Als Cisco-Mensch bin ich auch (noch) nicht mit der Verabeitungsreihenfolge der Windows-Config vertraut.
Der nützlichste Command innerhalb netsh war für mich der dump-Befehl. Wenn du das allerdings bei über die kleine Console ausgibst kannst du nichts lesen, aber mit:
netsh dump > netshX.log kannst du die Ausgabe in eine Datei umlenken und dann über more Seitenweise anzeigen lassen.
Du kannst die Netzwerkkonfiguration dann genau wie im Dump strukturiert manipulieren.
Ich hoffe dir ist erstmal geholfen...
¤dit: Wow, das waren jetzt nicht 4h
¤dit2: Die Webinterface-Logindaten brauch ich jetzt natürlich nicht mehr
Ich hab jetzt viel an der Config herumgefummelt (und dabei auch viel gelernt), deswegen kann ich jetzt nicht 100%tig genau sagen, woran es letztendlich lag, aber die IP-Config war auf jeden Fall falsch und zumindest auch teilweise die Firewallregeln.
Thema IP-Config:
----------------------
Aus der bestehenden Firewallconfig konnte ich sehen, dass die korrekte IP-Adresse die 85.214.140.219 255.255.255.255 ist.
Da mir der DHCP-Server keinen DG liefert habe ich hier nochmal die eigene IP hinterlegt (wie bei PPP-Verbindungen, warum auch immer...).
Thema Firewall:
---------------------
Du hattest in der Firewall vermutlich nur die TCP/UDP-Ports 47 (GRE), 500 (ISAKMP), 1701 (L2TP), 1723 (PPTP) und 4500 (IPSec) freigegeben. Damit verbietest du DNS, SSH und vermutlich auch ICMP (Ping/Tracert). Windows Remote-Desktop hätte soweit ich das in Google sehe TCP 3389. Ich hab die Firewallregeln jetzt gelöscht, da ich vermute, dass die bei der Einrichtung des RAS-Servers fälschlicherweise angelegt wurden. Wenn du die Regeln noch brauchst habe ich die letzte Config unter C:\Windows\System32\netsh.log und die aktuelle Config unter netsh3.log gespeichert. netsh2.log ist ein Zwischenstep und kann gelöscht werden. Ich kann aber nicht 100%tig sagen, dass die Firewallregeln gegriffen haben, da ich die falsche IP-Config erst im Anschluss geändert habe und die Regeln nicht wieder hinzufügen wollte (Die Zeilen sind ellenlang und Copy-Paste funzt nicht über die Console). Als Cisco-Mensch bin ich auch (noch) nicht mit der Verabeitungsreihenfolge der Windows-Config vertraut.
Der nützlichste Command innerhalb netsh war für mich der dump-Befehl. Wenn du das allerdings bei über die kleine Console ausgibst kannst du nichts lesen, aber mit:
netsh dump > netshX.log kannst du die Ausgabe in eine Datei umlenken und dann über more Seitenweise anzeigen lassen.
Du kannst die Netzwerkkonfiguration dann genau wie im Dump strukturiert manipulieren.
Ich hoffe dir ist erstmal geholfen...
¤dit: Wow, das waren jetzt nicht 4h
¤dit2: Die Webinterface-Logindaten brauch ich jetzt natürlich nicht mehr
-
- Accuracy
- Beiträge: 8185
- Registriert: Aug 2000
-
- Gebannt
- Beiträge: 1
- Registriert: Jan 2012
Ich habe das ebenso Problem mit mein Strato Win 2007............
Ist die Lösung änlich wie du gesagt hast?
Strato Gutscheincode
Ist die Lösung änlich wie du gesagt hast?
Strato Gutscheincode