zeppelin
Goto Top

Links im lokalen Browser öffnen, trotz Terminalserver

Hallo liebe Community,

ich stehe aktuell vor einer Herausforderung und hoffe, dass der gebündelte Wissensschatz hier im Forum mir weiterhelfen kann. Sicherheit ist für mich ein zentraler Aspekt, weshalb mein Netzwerk vielleicht etwas übertrieben wirkt – aber das soll hier nicht das Thema sein.

Ich betreibe einen Terminalserver, auf dem ich ein E-Mail-Programm verwende, um Nachrichten zu empfangen und zu versenden. Aus Sicherheitsgründen können dort keine Links direkt geöffnet werden, da keine direkte Internetverbindung besteht. Ich nutze ein Whitelisting-Verfahren, um Zugriffe zu steuern.

Nun möchte ich die Funktionalität verbessern: Wenn ein Link im Terminalserver angeklickt wird, soll dieser an den lokalen Arbeitsplatz gesendet und dort automatisch geöffnet werden. Aktuell muss man die URL manuell kopieren und im Lokalen Browser einfügen – das ist umständlich und nicht benutzerfreundlich.

Bisher habe ich ein PowerShell-Skript namens URLForwarder.ps1 erstellt:
param(
    [string]$url
)

# URL in die Zwischenablage kopieren
Set-Clipboard -Value $url

# Optional: URL über eine TCP-Verbindung an den lokalen Rechner senden
$tcpClient = New-Object System.Net.Sockets.TcpClient("127.0.0.1", 8080)  
$stream = $tcpClient.GetStream()
$writer = New-Object System.IO.StreamWriter($stream)
$writer.WriteLine($url)
$writer.Flush()
$writer.Close()
$tcpClient.Close()

Write-Host "URL weitergeleitet: $url"  

Dieses Skript habe ich mit dem Tool PS2EXE in eine ausführbare Datei (.exe) umgewandelt. Mein Plan war, in Windows den Standardbrowser für HTTP- und HTTPS-Protokolle auf diese .exe umzuleiten. Das geht theoretisch über die Einstellungen bei „Standard-Apps nach Protokoll“. Allerdings habe ich noch keine Möglichkeit gefunden, eine .exe dort direkt zu hinterlegen – vielleicht über die Registry?

Falls jemand dazu Tipps hat, wäre ich sehr dankbar!
Zum Nachvollziehen:

Drückt Windows-Taste + I, wählt „Apps > Standard-Apps“ aus.
Scrollt nach unten zu „Standard-Apps nach Protokoll auswählen“, sucht HTTP und HTTPS heraus, und versucht, eine andere Anwendung auszuwählen.
Parallel dazu muss der lokale Rechner die empfangene URL öffnen. Hierfür habe ich folgendes Skript geschrieben:

$listener = New-Object System.Net.Sockets.TcpListener([System.Net.IPAddress]::Loopback, 8080)
$listener.Start()
Write-Host "Listener läuft auf Port 8080..."  

while ($true) {
    $client = $listener.AcceptTcpClient()
    $stream = $client.GetStream()
    $reader = New-Object System.IO.StreamReader($stream)
    $url = $reader.ReadLine()
    Write-Host "Empfangene URL: $url"  
    
    # URL im lokalen Standardbrowser öffnen
    Start-Process $url

    $reader.Close()
    $client.Close()
}

Dieses Skript habe ich als URLListener.ps1 gespeichert. Geplant ist, es ebenfalls in eine .exe umzuwandeln und dem Autostart hinzuzufügen, damit es automatisch aktiv ist.

Meine Frage an die Gruppe:

Habt ihr Ideen, wie ich die .exe als Standardanwendung für HTTP und HTTPS registrieren kann?
Gibt es vielleicht eine bessere Lösung für meine Anforderung?
Ich freue mich auf eure Vorschläge und bedanke mich schon im Voraus für eure Unterstützung!

Liebe Grüße
Zeppelin

Content-ID: 670605

Url: https://administrator.de/forum/links-im-lokalen-browser-oeffnen-trotz-terminalserver-670605.html

Printed on: January 14, 2025 at 07:01 o'clock

kpunkt
kpunkt Jan 10, 2025 at 05:38:44 (UTC)
Goto Top
Hm...würde es evtl. funktionieren, wenn du die erstellte EXE in die EXE der Browser-Anwendung umbenennst und die dann im Ordner einfach ersetzt?
Zeppelin
Zeppelin Jan 10, 2025 at 09:43:54 (UTC)
Goto Top
Vielen Dank für den Hinweis – das ist ein guter Gedanke. Allerdings nutze ich auch andere webbasierte Anwendungen, und in diesen Fällen möchte ich, dass sie über den herkömmlichen Weg geöffnet werden. Wenn ich ein anderes Tool verwenden würde, könnte dies dazu führen, dass die Anwendungen außerhalb des Terminalservers gestartet werden, was ein unerwünschtes Verhalten nach sich ziehen würde.

Eine mögliche Lösung wäre, festzulegen, dass für Anwendungen auf dem Terminalserver Webbrowser A verwendet wird, während für alle anderen Zugriffe Webbrowser B zum Einsatz kommt. So könnte der Übergang zur lokalen Ebene ermöglicht werden.

Ich habe mir in der Nacht weitere Gedanken gemacht, wie man das Problem lösen könnte. Eventuell liegt die Ursache bei Microsoft RDP. Ab Windows Server 2019 gibt es theoretisch die Möglichkeit, einen SSL/VPN-Zugriff direkt über den Webbrowser zu realisieren. Da ich Windows Server 2022 einsetze, sollte es möglich sein, statt einer herkömmlichen RDP-Verbindung eine webbasierte "RDP"-Lösung anzubieten.

Derzeit nutzen wir, wie die meisten, die mit Terminalservern arbeiten, eine klassische RDP-Verbindung. Einige setzen auf Citrix, während andere den Webzugriff über eine SSL/VPN-Anbindung nutzen.

Zusätzlich zur RDP-Verbindung muss bei uns immer ein VPN-Tunnel aufgebaut werden, ergänzt durch die Verwendung einer Zwei-Faktor-Authentifizierung (2FA).