CMD Befehl SC.exe per VPN nicht möglich, RPC-Server nicht verfügbar

Hi zusammen ich hoffe das ist das richtige Forum.

Zum Problem: Wir nutzen Sophos VPN und ich habe einen automatischen Script erstellt welcher per SC.exe Dienste beendet. Das klappt im internen Netz super, extern im VPN kommt leider RPC-Server nicht verfügbar.
Erst dachte ich das es ein DNS Problem ist, allerdings liegt es "leider" nicht daran. Gibt es Erfahrungen oder Alternativen um einen Dienst Remote beenden zu können, wenn der Client im VPN Netz hängt?
Ping und RDP funktioniert übrigens problemlos, auch vom VPN-Client aus (aus dem VPN Netz heraus) kann ich einen Dienst an einem internen PC im internen Netz ändern.

Etwas kompliziert aber ich hoffe es hat wer einen Tipp. Vielleicht gibt es noch eine Alternative zum SC Befehl. Ziel des ganzen: Ich trenne im Prinzip "nur" die LAN Verbindung und deaktiviere sie über den DHCP Dienst. (das ganze muss automatisch durch eine LogFile passieren können OHNE selber tätig zu werden)

Danke

Mit freundlichen Grüßen Rob

EDIT auch der Powershell Befehl get-service funktioniert im VPN nicht

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 249565

Url: https://administrator.de/forum/cmd-befehl-sc-exe-per-vpn-nicht-moeglich-rpc-server-nicht-verfuegbar-249565.html

Ausgedruckt am: 24.12.2024 um 03:12 Uhr

16 Kommentare

Neuester Kommentar

Moin,

"hört" sich nach Firewall an. Schau mal in den Windows-Firewallregeln des zielhosts, ob auch die anderen Netze RPC nutzen dürfen.

lks

War ein guter Ansatz, stimmt natürlich das die Domain-Regeln im VPN Nicht zählen, aber selbst mit deaktivierter Firewall oder mit händischer Freigabe des RPC auf dem Client, leider keine Änderung. Könnte es an der Windows-Anmeldung liegen? Der Client meldet sich ja nicht an der AD an, wenn er VPN nutzt (bzw. nur teilweise) Echt blöde Sache aber langsam gehen mir die Ideen aus.

mfg Rob

Zitat von @Borob14:

Könnte es an der Windows-Anmeldung liegen? Der Client meldet sich ja nicht an der AD an, wenn er VPN nutzt (bzw. nur teilweise)

Ist die Kiste Domänen Mitglied?
Ist der Benutzer Domänenbenutzer?
Nutzt die Kiste/der benutzer shares aus der Domain?

Wenn da nicht irgendwelche credentials vorhanden sind, die die Nutzung von Damänendiensten erlauben, geht das natürlich schief.

lks

Und hat die VPN Software eventuell nochmals eigene Firewall Regeln, die was blocken können?

•Ist die Kiste Domänen Mitglied?
-> Jup ist sie

•Ist der Benutzer Domänenbenutzer?
-> Jup bin sogar mit DomainAdmin angemeldet

•Nutzt die Kiste/der benutzer shares aus der Domain?
-> Was meinst du damit, bin mir nicht sicher was du meinst? Zugriffe aufs Firmennetz sind natürlich möglich.
-> Die Anmeldung erfolgt natürlich nur mit dem gecachten Profil, VPN Verbindung wird erst nach Anmeldung aufgebaut

•Und hat die VPN Software eventuell nochmals eigene Firewall Regeln, die was blocken können?
-> bin ich mir nicht sicher, eigentlich nein und da es sich nach Aufbau der VPN-Verbindung um eine interne<->interne Verbindung der Clients handelt gelten an der Firmenfirewall die selben Regeln wie im reinen internen Netz (wo es bisher ja ohne Probleme klappt)
Werde mich aber nochmal über den Sophos VPN Client belesen ob dort zusätzliche Regeln/Einstellungen möglich sind. (glaube aber nicht, da dies die Firewall Regeln sein sollte, an der der VPN Client anklopft)

Moin Rob,
ein Trace mit Wireshark sollte dir Klarheit verschaffen. Dann hast du Gewissheit ob die Pakete den Client überhaupt erreichen. RPC-Server nicht verfügbar bedeutet entweder das der RPC Port geblockt wird oder du die falschen Credentials mitgibst. Domain-Credentials muss der Client natürlich auflösen können. Versuch es mal mit einem "lokalen" Adminaccount der auf dem Client existiert. Hier läuft das ganze auch problemlos über VPN, also ist das dein Ansatzpunkt.

btw. mit VBS lässt sich das ganze hiermit zuverlässiger machen, als nur den DHCP-Dienst zu beenden:

On Error Resume Next
strComputer = "10.10.20.33"  
Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")  
Set colAdapters = objWMIService.ExecQuery("Select * from Win32_Networkadapter where NetEnabled='True'")  
For Each adapter in colAdapters
    adapter.Disable()
Next

Grüße Uwe

HiHo Uwe,

du weißt auch mit allem Bescheid oder?
Danke dir für die Antwort, wir haben derzeit leider ne größere Firmenumstellung, daher keine Zeit das zu testen. Ich hoffe ich komme am Montag dazu.
Mit dem Netzwerkadapter das hab ich auch gesucht allerdings immer nur Sachen gefunden wo genau der Name angegeben werden musste. Wenn das so klappen würde wäre es absolut geil! Das mit Wireshark und dem lokalen ADM ist auch ne gute Idee. Danke für die Ansätze und ein wunder schönes Wochenende.

So hatte Heute "etwas" Zeit und konnte den Script erfolgreich auf deine Variante ändern, im VPN Netz leider trotzdem kein Erfolg. Ich teste es nun mit dem lokalen ADM der auf beiden vorhanden ist. Mit Wireshark muss ich mich erst etwas beschäftigen.

Guten Morgen zusammen,

ich komme mit Wireshark nicht weiter, kann mir wer die Meldungen übersetzen?
XX ist unsere Öffentliche Adresse die ich nicht gern hier posten würde ^^
Ping kommt super durch und sehe ich auf beiden Seiten nur der Netzwerkkarten sperren Befehl zeigt folgendes:

Am Ziel Client finde ich nur.
31 13.755294000 XX.XXX.XXX.XXX 192.168.1.105 TCP 121 [TCP Retransmission] 8443?49574 [PSH, ACK] Seq=429 Ack=445 Win=32038 Len=67

Am Auslösenden Client kommt:
70 2.089030000 192.168.109.128 10.242.2.34 TCP 66 52314→135 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
145 5.089060000 192.168.109.128 10.242.2.34 TCP 66 [TCP Retransmission] 52314→135 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
270 11.089363000 192.168.109.128 10.242.2.34 TCP 62 [TCP Retransmission] 52314→135 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1

Mit den paar Schnippseln nicht möglich, die sagen nur aus das der jeweilige Sender die Pakete versucht erneut zu verschicken, weil er keine Antwort bekommt (Retransmission)

Ist ja auch normal nachdem du die Verbindung gekappt hast

Grüße Uwe

Sorry das ich so lange nicht geschrieben habe, habe derzeit einfach keine Luft. Projekt ist aber noch offen. Ich denke es liegt an unserer Firewall und muss mich da mit nem "höheren" Admin dran setzen(hab auf unserer Firewall leider kaum Rechte) um zu schauen ob etwas geblockt wird. Wie du ja schon gesagt hast er wartet auf Rückantwort, mehr hat man dort nicht im Log gesehen, daher die Annahme das die Firewall was blockt. Komisch halt nur das es vom VPN Client ins interne Netz klappt nur vom Internen Netz nicht ins VPN Netz.

Ich danke dir erst mal und hoffe das ich bald dazu komme.

mfg Rob

Hallo Rob,
ich würde auch mal das Routing überprüfen. Ist auf dem Client in der VPN Software eingestellt das er das DefaultGW des internen Netzes nutzt ? Und wie macht ihr die VPN Einwahl? haben die VPN Clients ein separates Subnetz ?

Viele Grüße
Uwe

Hi Uwe,

wir haben ne Sophos und die Einwahl geschieht über die Sophos Software. (SSL VPN Client). Routing ist ne gute Idee, vielleicht funktioniert das nur in eine Richtung richtig.
Die VPN Clients haben ein anderes Netz, das ist korrekt. Internes Netz ist 192iger und VPN ist 10er. Da ich aber den Befehl von einem VPN Client erfolgreich an ein internes Gerät übersenden kann, sollte das Netz nicht das Problem sein.

Ich habe im verdacht, dass ein paar Ports nur in eine Richtung offen sind, dazu brauch ich aber meinen Chef (der noch weniger Zeit hat als ich ^^)
Naja mal schauen wann es endlich klappt mit dem Test.

Mit freundlichen Grüßen Rob

P.S. DefaultGW ist immer die Sophos (extern und intern)

Habe gerade nochmal getestet und festgestellt das RDP, Ping geht aber die Adminfreigaben (C$ etc.) z.Bsp. auch nicht gehen, was die Vermutung mit dem Firewall block verstärkt. Mal schauen ob Chefchen am Freitag Zeit hat ^^

Mit der Route kann eigentlich damit auch nicht sein, denn dann sollte gar nix gehen oder?

mfg Rob

Zitat von @Borob14:
die Vermutung mit dem Firewall block verstärkt. Mal schauen ob Chefchen am Freitag Zeit hat ^^

da wird dann sicherlich CIFS/SMB gefiltert.

Mit der Route kann eigentlich damit auch nicht sein, denn dann sollte gar nix gehen oder?

richtig wenn Pings etc. laufen, ist das Routing OK.

So es hat geklappt, es liegt definitiv an der Firewall, welche Ports alle benötigt werden müssen wir noch testen aber ne kurze Anyverbindung -> VPN Netz Freigabe hats gezeigt. Danke wie immer für die Hilfe