ComputerBase
Aktuelles

Windows 7 VM Virtualbox - VM komplett über VPN

F

FAMEJBL

Gast
Hallo,

ich habe folgendes Problem und suche dafür eine Möglichkeit, das entsprechend umzusetzen:

Ich habe auf meinem Host System Ubuntu Mate 18.04 laufen und in Virtual Box in eine Windows 7 VM. In der Windows VM soll ein VPN Client laufen, der erstmal die Verbindung zum VPN Dienst / Server herstellt. Nun möchte ich, das der komplette Traffic der Windows VM über den VPN Server läuft und nichts daran vorbeikann. Desweiteren würde ich gerne nur die VM Verbindung über den VPN zulassen und das Hostsystem, in diesem Falle Ubuntu Mate soll nicht ins Internet gelangen. Es soll also nur die VM über den VPN zugriff auf das Internet haben, sonst nichts. Ist das irgendwie machbar?
 
Ups Sorry dann läuft das wohl aufs selbe raus. Dann kann dieser Thread hier gelöscht werden.
 
Hancock schrieb:
Der andere Thread ist jetzt zu:
​Du könntest via Netzwerkbrücke dein Win7 ins Netz lassen und dein Ubuntu ohne konfigurierte Netzwerkanbindung.
Zum Vergrößern anklicken....

Und wie würde ich das ganze Umsetzten? Via Software in der VM oder in Ubuntu? Gibt es da Anleitung zu?
 
Hancock schrieb:
Na ja: Netzwerk->Angeschlossen an "Netzwerkbrücke" (in VirtualBox in den Einstellungen zur VM)
​Und keine IP vergeben beim Host sollte auch möglich sein (Z.B. via statische IP und dann nix eingeben oder kein Gateway, z.B. im Network-Manager).
Zum Vergrößern anklicken....

Was muss ich dann in der Netzwerkbrücke einstellen? Habe folgende Parameter in Virtualbox:

Name: Da steht nur meine Ethernet Schnittstelle vom Host zur Verfügung
Adaptertyp: Da kann ich verschiedene auswählen -> http://prntscr.com/ix60qw
Promiscuous-Modus: Da kann ich das wählen -> http://prntscr.com/ix61ah
Mac Adresse ist eingetragen, kann man aber ändern / andere Laden
Bei Kabel gebunden ist ein häkchen.

Woe soll das gehen, dass man keine IP vergibt? und wo wäre das zu tun?
 
Hm.. Der Host darf nicht ins Internet, die VM dagegen schon, aber nur via VPN? Wer hat Zugriff auf Host und VM? Es geht darum, dass du ja ausschließlich via VPN online gehen willst so wie ich das verstehe. Wenn das VPN in der VM ist, kann der Nutzer unter Umständen das VPN einfach ausschalten. Im Idealfall lagert man solche Restriktionen auf ein Gerät vor der VM aus, um eben Manipulationen zu verhindern.

Wenn die VM beispielsweise via NAT am Host hängt, der Host das VPN herstellt und dessen Firewall dann so konfiguriert wird, dass Host-Traffic auf den VPN-Server beschränkt und VM-Traffic ausschließlich über das VPN geroutet wird (Stichwort: Policy Based Routing), kann der VM-Nutzer gar nichts dagegen tun. Sitzt das VPN hingegen in der VM, kann man dieses unter Umständen einfach abschalten und sofern die Firewall das nicht abfängt hat die VM dann uneingeschränkten Internet-Zugang.


Ich habe ein vergleichbares Beispiel in Betrieb, allerdings geht's mir primär um die einfache Umschaltung und nicht um VPN-only. Bei mir daheim werkelt ein kleiner PI mit einer VPN-Verbindung zu Cyberghost. Da ich nicht auf jedem Endgerät ein VPN herstellen will - und es zB von einem TV, Receiver oder sonstigen embedded Devices eh nicht geht - verwenden alle Geräte, die VPN nutzen sollen, den PI als Standard-Gateway. Die Geräte selbst bekommen gar nichts davon mit, dass ein VPN im Spiel ist. So wäre es eben auch bei dem oben beschriebenen Szenario mit dem VPN-Tunnel im Host. Die VM kann durch das NAT-Interface ausschließlich über den Host ins Netzwerk und der Host lenkt eben ins VPN um, die VM hat gar keine andere Wahl.
 
Raijin schrieb:
Hm.. Der Host darf nicht ins Internet, die VM dagegen schon, aber nur via VPN? Wer hat Zugriff auf Host und VM? Es geht darum, dass du ja ausschließlich via VPN online gehen willst so wie ich das verstehe. Wenn das VPN in der VM ist, kann der Nutzer unter Umständen das VPN einfach ausschalten. Im Idealfall lagert man solche Restriktionen auf ein Gerät vor der VM aus, um eben Manipulationen zu verhindern.

Wenn die VM beispielsweise via NAT am Host hängt, der Host das VPN herstellt und dessen Firewall dann so konfiguriert wird, dass Host-Traffic auf den VPN-Server beschränkt und VM-Traffic ausschließlich über das VPN geroutet wird (Stichwort: Policy Based Routing), kann der VM-Nutzer gar nichts dagegen tun. Sitzt das VPN hingegen in der VM, kann man dieses unter Umständen einfach abschalten und sofern die Firewall das nicht abfängt hat die VM dann uneingeschränkten Internet-Zugang.


Ich habe ein vergleichbares Beispiel in Betrieb, allerdings geht's mir primär um die einfache Umschaltung und nicht um VPN-only. Bei mir daheim werkelt ein kleiner PI mit einer VPN-Verbindung zu Cyberghost. Da ich nicht auf jedem Endgerät ein VPN herstellen will - und es zB von einem TV, Receiver oder sonstigen embedded Devices eh nicht geht - verwenden alle Geräte, die VPN nutzen sollen, den PI als Standard-Gateway. Die Geräte selbst bekommen gar nichts davon mit, dass ein VPN im Spiel ist. So wäre es eben auch bei dem oben beschriebenen Szenario mit dem VPN-Tunnel im Host. Die VM kann durch das NAT-Interface ausschließlich über den Host ins Netzwerk und der Host lenkt eben ins VPN um, die VM hat gar keine andere Wahl.
Zum Vergrößern anklicken....

Die Lösung einen Pi einzusetzen wäre ja somit eigentlich am besten und vor allen Dingen wohl auch am einfachsten / sichersten oder? Hast du dazu eine Anleitung parat? Geht das mit jedem VPN Dienst?
 
Jein, auch wenn die Lösung via PI durchaus ähnlich ist (verglichen mit VPN@Host und VM via NAT @Host), so unterscheidet sie sich in einem entscheidenden Punkt: Der VM-Nutzer kann problemlos das Standard-Gateway vom PI auf den Internet-Router umstellen und schon kommt er ungefiltert ins www. Daher ja meine Frage wer Zugriff auf Host bzw. VM hat. Bedenke, dass wir ja deine Intention hinter der Sache nicht kennen, du schreibst sinngemäß nur, dass die VM ausschließlich via VPN ins www soll. Bist du selbst der einzige Nutzer, ist die Gefahr der Manipulation innerhalb der VM natürlich hinfällig, bei Familienmitgliedern aber durchaus gegeben.

Wenn das Host-System aber sowieso Linux ist, wäre der PI hinfällig, weil du das ebenso auf dem Host konfigurieren kannst. Ist die VM als NAT konfiguriert, hat sie ja gar keine andere Wahl als über den Host zu gehen. Den Host kann man wie gesagt selbst entsprechend absichern, dass dort eben ausschließlich der VPN-Server erreichbar ist - gesetzt den Fall der hat ne feste WAN-IP.

Eine konkrete Anleitung habe ich leider nicht wirklich parat, weil ich das hobbymäßig zusammenbastel und dafür kein Tutorial, o.ä. brauche.

Das entscheidende Stichwort im Falle der VPN@Host Variante ist "Policy Based Routing". Standardmäßig wird stets nach der Ziel-IP geroutet. Frei nach dem Motto "Die IP ab.c.d. soll via VPN gehen, die IP w.x.y.z via Provider". Windows kann ausschließlich auf diese Art und Weise routen. PBR hingegen lässt sich so konfigurieren, dass beispielsweise anhand des Ziel-Ports geroutet wird. Also zB alle Verbindungen über http/https (TCP 80 / 443) via Provider, aber Port 12345 via VPN. Ebenso lässt sich die Quell-IP als Trigger verwenden und genau hier liegt der Knackpunkt. Konfiguriert man PBR am Host so, dass die Quell-IP = VM-IP als Trigger dient, kann man explizit diesen Traffic via VPN routen - alles andere (bis auf das VPN selbst) wird geblockt.
Ergänzung ()

Am besten erklärst du kurz was genau du damit bezweckst. Die Hintergründe, das Wieso und Warum, sind nicht ganz unwichtig. Sonst läuft es am Ende auf ein X-Y-Problem hinaus und du willst eigentlich etwas ganz anderes, hast uns aber durch deine Fragestellung explizit auf den falschen Weg gelenkt.
 
Raijin schrieb:
Jein, auch wenn die Lösung via PI durchaus ähnlich ist (verglichen mit VPN@Host und VM via NAT @Host), so unterscheidet sie sich in einem entscheidenden Punkt: Der VM-Nutzer kann problemlos das Standard-Gateway vom PI auf den Internet-Router umstellen und schon kommt er ungefiltert ins www. Daher ja meine Frage wer Zugriff auf Host bzw. VM hat. Bedenke, dass wir ja deine Intention hinter der Sache nicht kennen, du schreibst sinngemäß nur, dass die VM ausschließlich via VPN ins www soll. Bist du selbst der einzige Nutzer, ist die Gefahr der Manipulation innerhalb der VM natürlich hinfällig, bei Familienmitgliedern aber durchaus gegeben.

Wenn das Host-System aber sowieso Linux ist, wäre der PI hinfällig, weil du das ebenso auf dem Host konfigurieren kannst. Ist die VM als NAT konfiguriert, hat sie ja gar keine andere Wahl als über den Host zu gehen. Den Host kann man wie gesagt selbst entsprechend absichern, dass dort eben ausschließlich der VPN-Server erreichbar ist - gesetzt den Fall der hat ne feste WAN-IP.

Eine konkrete Anleitung habe ich leider nicht wirklich parat, weil ich das hobbymäßig zusammenbastel und dafür kein Tutorial, o.ä. brauche.

Das entscheidende Stichwort im Falle der VPN@Host Variante ist "Policy Based Routing". Standardmäßig wird stets nach der Ziel-IP geroutet. Frei nach dem Motto "Die IP ab.c.d. soll via VPN gehen, die IP w.x.y.z via Provider". Windows kann ausschließlich auf diese Art und Weise routen. PBR hingegen lässt sich so konfigurieren, dass beispielsweise anhand des Ziel-Ports geroutet wird. Also zB alle Verbindungen über http/https (TCP 80 / 443) via Provider, aber Port 12345 via VPN. Ebenso lässt sich die Quell-IP als Trigger verwenden und genau hier liegt der Knackpunkt. Konfiguriert man PBR am Host so, dass die Quell-IP = VM-IP als Trigger dient, kann man explizit diesen Traffic via VPN routen - alles andere (bis auf das VPN selbst) wird geblockt.
Ergänzung ()

Am besten erklärst du kurz was genau du damit bezweckst. Die Hintergründe, das Wieso und Warum, sind nicht ganz unwichtig. Sonst läuft es am Ende auf ein X-Y-Problem hinaus und du willst eigentlich etwas ganz anderes, hast uns aber durch deine Fragestellung explizit auf den falschen Weg gelenkt.
Zum Vergrößern anklicken....

Ich benutze den Pc als einziger, sonst hat keiner Zugriff auf den gesamten PC, sprich sowohl Host als auch Gast. Da kann also keiner hingehen und irgendwas ändern. Der VPN läuft wie gesagt momentan in der VM. Unter Ubuntu gibt es den Client auch, aber da sind die Einstellung in der grafischen Oberfläche nicht so vielseitig und das hantieren mit OpenVPN würde ich gerne vermeiden. Wenn der VPN dann nicht unter Ubuntu, sondern nur in der VM läuft, bringt das mit dem Routing überhaupt etwas? Ich müsste mal nachsschauen, aber ich glaube der VPN Anbieter bietet auch VPN Router an. Habe einen Telekom speedport, der eignet sich wahrscheinlich nicht dafür oder? Meine eigentlich Intention besteht darin, das ich in der Windows VM ein Programm installieren will um auf einen Dedicated Server zu verbinden. Diese Verbindung soll über den VPN aufgebaut werden, sodass der Dedicated Server quasi die VPN IP „sieht“. Desweiteren möchte ich, das jegliche Verbindung die ich in der Windows VM habe, über den VPN geht. Wie gesagt, in der VM läuft ja der Client indem ich meine Verbindung bzw. den server auswählen kann. Während ich in der VM die Verbindungen herstelle ( wie gesagt z.b zum Dedicated Server oder ins Internet durch Firefox) möchte ich nicht das Ubunut Mate 18.04, also mein Host System, irgendetwas ins Internet sendet oder irgendeine Verbindung hat. Es soll quasi „Offline“ sein, sodass ich nur in der VM internet habe. Das ganze sollte am besten noch Schaltbar sein, das wenn ich z.B nicht in der VM tätig bin und VirtualBox schließe, das ich dann das Internet für meinen Ubuntu Host wieder freischalten kann.

Danke schonmal für die Vielen Tipps :) Bei unklarheiten einfach nachfragen, dann reiche ich die Infos nach.
 
Das klingt ehrlich gesagt etwas seltsam. Was ist das Problem mit dem Host-System, wenn du in der VM unterwegs bist? Schaltest du die VM wieder aus, soll der Host wieder Internet haben. Ich sehe den Zusammenhang irgendwie nicht. Was sollte das Host-System tun, während du in der VM unterwegs bist, was es nicht tut, wenn du direkt im Host arbeitest? Das erschließt sich mir nicht wirklich.

Wie dem auch sei, nu sieht die Sache schon wieder etwas anders aus.

Ich würde das VPN in der VM belassen, weil etwaige Sicherheitsmechanismen und Zwänge über ein externes VPN-Gateway ja hinfällig sind. Über iptables würde ich

a) Traffic zur/von der WAN-IP des VPN-Servers accepten
b) Traffic von der eignen VPN-IP accepten
c) Den Rest blocken

Baut man den VPN-Tunnel auf, wird der Tunnel an sich durch a) erlaubt. Weiterer Traffic wird dann ja über das VPN getunnelt (Standard-Gateway redirect des VPNs). Dieser Traffic wird duch b) erlaubt. Traffic, der weder per WAN zum VPN-Server geht noch über die VPN-Verbindung geht, wird durch c) geblockt. Das alles kommt in die OUTPUT chain.

iptables (Freihand) müssten in etwa so aussehen:

iptables -I OUTPUT -d VPNSERVER_WAN -j ACCEPT
iptables -I OUTPUT -s VPNCLIENT_IP -j ACCEPT
iptables -I OUTPUT -j DROP


*edit:
Wollte gerade die iptable Kommandos prüfen und ggfs korrigieren, dabei bin ich auf folgende Seite gestoßen: Klick! Ähnlich wie mein Ansatz, aber basierend auf den Interfaces anstelle von IPs. Ist in der Form sogar besser - und ich meine, dass ich das auf meinem PI ähnlich gemacht habe - da unabhängig vom VPN-Subnetz, das im Falle von verschiedenen VPN-Servern eben auch durchaus unterschiedlich sein kann. tap/tun (=VPN) wird erlaubt, der Rest (also zB eth0) wird geblockt.
 
Zuletzt bearbeitet:
Raijin schrieb:
Das klingt ehrlich gesagt etwas seltsam. Was ist das Problem mit dem Host-System, wenn du in der VM unterwegs bist? Schaltest du die VM wieder aus, soll der Host wieder Internet haben. Ich sehe den Zusammenhang irgendwie nicht. Was sollte das Host-System tun, während du in der VM unterwegs bist, was es nicht tut, wenn du direkt im Host arbeitest? Das erschließt sich mir nicht wirklich.

Wie dem auch sei, nu sieht die Sache schon wieder etwas anders aus.

Ich würde das VPN in der VM belassen, weil etwaige Sicherheitsmechanismen und Zwänge über ein externes VPN-Gateway ja hinfällig sind. Über iptables würde ich

a) Traffic zur/von der WAN-IP des VPN-Servers accepten
b) Traffic von der eignen VPN-IP accepten
c) Den Rest blocken

Baut man den VPN-Tunnel auf, wird der Tunnel an sich durch a) erlaubt. Weiterer Traffic wird dann ja über das VPN getunnelt (Standard-Gateway redirect des VPNs). Dieser Traffic wird duch b) erlaubt. Traffic, der weder per WAN zum VPN-Server geht noch über die VPN-Verbindung geht, wird durch c) geblockt. Das alles kommt in die OUTPUT chain.

iptables (Freihand) müssten in etwa so aussehen:

iptables -I OUTPUT -d VPNSERVER_WAN -j ACCEPT
iptables -I OUTPUT -s VPNCLIENT_IP -j ACCEPT
iptables -I OUTPUT -j DROP


*edit:
Wollte gerade die iptable Kommandos prüfen und ggfs korrigieren, dabei bin ich auf folgende Seite gestoßen: Klick! Ähnlich wie mein Ansatz, aber basierend auf den Interfaces anstelle von IPs. Ist in der Form sogar besser - und ich meine, dass ich das auf meinem PI ähnlich gemacht habe - da unabhängig vom VPN-Subnetz, das im Falle von verschiedenen VPN-Servern eben auch durchaus unterschiedlich sein kann. tap/tun (=VPN) wird erlaubt, der Rest (also zB eth0) wird geblockt.
Zum Vergrößern anklicken....

Ich arbeite so gut wie nie im Host. Ich wollte eigentlich Windows 7 als Host aufspielen, aber Ryzen 7 macht da große Probleme. Deswegen habe ich Ubuntu als Host genommen um darauf Windows zu virtualisieren. Ich möchte einfach nicht das Ubuntu, also der Host, irgendwas sendet wenn ich in der VM tätig bin. Im Ubuntu Host mache ich eigentlich überhaupt nichts, außer VM starten und hin und wieder den Firefox benutzen. Ich werde mir den Ansatz basierend auf dem Interface mal genauer ansehen und mal versuchen das so umzusetzten. Kann ich dann bei der Virtuellen Maschine den Netzwerk Typ "NAT" stehen lassen?
 
Ich rate dir dringend, dich mehr mit Scripting auseinanderzusetzen. Blind Scripts einzusetzen, ohne dass man auch nur den blassesten Schimmer hat was es tut, ist nicht besonders klug. Hinzu kommt, dass Scripts aus Tutorials, etc. in den meisten Fällen eben nicht 100%ig auf das eigene Szenario passen.

Man muss ja nicht gleich selbst Skripte schreiben können, aber das besagte Skript ist trivial und wenn am Ende "nur Zorro-VPN" geblockt werden, nimmt man den Part eben raus. Das Skript hatte ich dir per PN ja grob erklärt. Die Datei VPN.list wird durch die Update-Funktion überschrieben. Nimmt man diese Funktion raus, sollte das Skript auch funktionieren, gesetzt den Fall du hast die VPN.list selbst mit den IPs deiner VPN-Server gefüllt.

Wie dem auch sei, ändere die main wie folgt (beachte die #)


Code: 
function main() {
    case $1 in
        start|restart|reload)
            #update_zorrovpn_ips
            if [ ! -f "$VPNLIST" -o ! -s "$VPNLIST"  ]; then
                echo "Failed: $VPNLIST file is empty, unable to start";
                exit 1;
            fi
            init_firewall_rules
            load_ips_for_blocking
            ;;
        stop)
            disable_blocking
            ;;
        #update)
        #    if ! update_zorrovpn_ips; then
        #        echo "Warning: update has been failed, try again";
        #    fi
        #    ;;
        add_dns_to_custom)
            add_dns_to_custom_list
            ;;
        *)
            echo -e "Usage: $0 start|restart|reload|stop|update|add_dns_to_custom"
            ;;
    esac
}

Das Problem lag in der update-Funktion. Dort wurden beim Start die zorro-ips aufgelöst und in die vpn.list geschrieben. Die Datei wird allerdings jedes Mal neu generiert, manuelle Einträge gehen also verloren. Entweder die Funktion wie oben gezeigt in der main auskommentieren oder entsprechend anpassen, zB auf die Domain deines VPN-Servers anstelle von zorrovpn.com.

Code: 
function update_zorrovpn_ips {
    host_command="host -T -W 2 -t A -4 hier.deine.vpn.domain" #guckst du hier
    ips=`$host_command | grep 'has address' | parse_ip_addr`;
    if [ ! -n "$ips" ]; then
        ips=`$host_command 8.8.8.8 | grep 'has address' | parse_ip_addr`;
    fi

    if [ ! -n "$ips" ]; then
        return 1
    fi

    # Das folgende Kommando überschreibt die vpn.list.
    echo "$ips" | sort > $VPNLIST
    return 0
}
 
Raijin schrieb:
Ich rate dir dringend, dich mehr mit Scripting auseinanderzusetzen. Blind Scripts einzusetzen, ohne dass man auch nur den blassesten Schimmer hat was es tut, ist nicht besonders klug. Hinzu kommt, dass Scripts aus Tutorials, etc. in den meisten Fällen eben nicht 100%ig auf das eigene Szenario passen.

Man muss ja nicht gleich selbst Skripte schreiben können, aber das besagte Skript ist trivial und wenn am Ende "nur Zorro-VPN" geblockt werden, nimmt man den Part eben raus. Das Skript hatte ich dir per PN ja grob erklärt. Die Datei VPN.list wird durch die Update-Funktion überschrieben. Nimmt man diese Funktion raus, sollte das Skript auch funktionieren, gesetzt den Fall du hast die VPN.list selbst mit den IPs deiner VPN-Server gefüllt.

Wie dem auch sei, ändere die main wie folgt (beachte die #)


Code: 
function main() {
    case $1 in
        start|restart|reload)
            #update_zorrovpn_ips
            if [ ! -f "$VPNLIST" -o ! -s "$VPNLIST"  ]; then
                echo "Failed: $VPNLIST file is empty, unable to start";
                exit 1;
            fi
            init_firewall_rules
            load_ips_for_blocking
            ;;
        stop)
            disable_blocking
            ;;
        #update)
        #    if ! update_zorrovpn_ips; then
        #        echo "Warning: update has been failed, try again";
        #    fi
        #    ;;
        add_dns_to_custom)
            add_dns_to_custom_list
            ;;
        *)
            echo -e "Usage: $0 start|restart|reload|stop|update|add_dns_to_custom"
            ;;
    esac
}

Das Problem lag in der update-Funktion. Dort wurden beim Start die zorro-ips aufgelöst und in die vpn.list geschrieben. Die Datei wird allerdings jedes Mal neu generiert, manuelle Einträge gehen also verloren. Entweder die Funktion wie oben gezeigt in der main auskommentieren oder entsprechend anpassen, zB auf die Domain deines VPN-Servers anstelle von zorrovpn.com.

Code: 
function update_zorrovpn_ips {
    host_command="host -T -W 2 -t A -4 hier.deine.vpn.domain" #guckst du hier
    ips=`$host_command | grep 'has address' | parse_ip_addr`;
    if [ ! -n "$ips" ]; then
        ips=`$host_command 8.8.8.8 | grep 'has address' | parse_ip_addr`;
    fi

    if [ ! -n "$ips" ]; then
        return 1
    fi

    # Das folgende Kommando überschreibt die vpn.list.
    echo "$ips" | sort > $VPNLIST
    return 0
}
Zum Vergrößern anklicken....

Vielen vielen herzlichen Dank für deine ausführliche Antwort. Leider bin ich ein kompletter Vollidiot im Scripting aber ich werde mich jetzt damit auseinander setzen und versuchen das Script zu verstehen. Da gibt es ja sicherlich bei Google genügend Info`s, was die einzelnen Zeilen / Funktionen bedeuten und was sie machen.

Vielen vielen Dank nochmal :)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

Jack10
Oracle VM VirtualBox Manager lässt sich kein Windows installieren
Antworten
10
Aufrufe
2.009
Jack10
Jack10
Deadendstreet
Bildschirm Anzeige drehen in Oracle VM VirtualBox
Antworten
3
Aufrufe
2.290
Nero1
Nero1
Konfekt
[VM VirtualBox] Schwerwiegender Fehler/ Guru
Antworten
1
Aufrufe
3.624
till69
T
F
Anno 1701 in einer Windows 7-VM: Keine Anti-Aliasing-Einstellungen
Antworten
5
Aufrufe
1.709
FatManStanding
F
Konfekt
VM vollständig isolieren (Oracle VM VirtualBox)
Antworten
7
Aufrufe
2.913
DubZ
D
Zurück
Oben

Willkommen auf ComputerBase!

Mit Werbung weiterlesen

Besuche ComputerBase wie gewohnt mit Werbung und Tracking. Die Zustimmung ist jederzeit widerrufbar.

Details im Privacy Center und in der Liste unserer Partner. Ein Widerruf ist möglich in der Datenschutzerklärung.

Dieser Dialog konnte nicht vollständig geladen werden, eine Zustimmung gilt daher nur vorläufig. Blockiert ein Browser-Add-on Third-Party-Scripte?

… oder ComputerBase Pro bestellen

Nutze ComputerBase ohne Werbebanner, Video-Ads und Werbetracking schon für 4 €/Monat oder 36 €/Jahr.

Mehr zu ComputerBase Pro

Bereits Pro-Nutzer? Hier anmelden.

Tracking: Wir und unsere 155 Partner verarbeiten personenbezogene Daten, indem wir mit auf Ihrem Gerät gespeicherten Informationen (z. B. eindeutige Kennungen in Cookies) ein Nutzungsprofil erstellen, um z. B. Anzeigen zu personalisieren. Verarbeitungszwecke: Genaue Standortdaten und Abfrage von Geräteeigenschaften zur Identifikation, Informationen auf einem Gerät speichern und/oder abrufen, Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen.

Impressum Kontakt Datenschutz