Master Luke
Enthusiast
OK, mal detailliert: Es geht um ein Stück Hardware für mein Heimnetz. Funzt oder nicht?
Dass die Intel-NICs weniger Probleme machen, ist mir (persönlich) bekannt.
[Sammelthread] Sophos UTM-Sammelthread
- Ersteller XTaZY
- Erstellt am
OK, mal detailliert: Es geht um ein Stück Hardware für mein Heimnetz. Funzt oder nicht?
Dass die Intel-NICs weniger Probleme machen, ist mir (persönlich) bekannt.
Master Luke
Enthusiast
danke dir!
Versteht mich nicht falsch: ich habe viel in letzter Zeit gelesen und wollte einfach noch mal "ein paar Augen drüber schauen lassen".
Die NICs in der Kiste von Realtek sollen auf der Kompatibilitätsliste stehen und laut Google finde ich in kurzer Zeit mind. 5 Anwender, die die Kiste am laufen haben.
SSD soll mind. 100-120GB groß sein.
Wieviel RAM? Reichen 2x1GB?
Danke!
Was die Hardware angeht, schau mal hier https://community.sophos.com/produc...67/unofficial-hardware-compatibility-list-hcl und hier Hardware Empfehlung Firewall
https://r.tapatalk.com/shareLink?ur...&share_tid=1115423&share_fid=200&share_type=t
Gesendet von iPhone mit Tapatalk
https://r.tapatalk.com/shareLink?ur...&share_tid=1115423&share_fid=200&share_type=t
Gesendet von iPhone mit Tapatalk
Abgesehen vom Wlan Modul läuft die UTM auf der Zotac Box absolut problemlos. Mit 2gb RAM wirst du vermutlich auskommen, ich würde jedoch gleich 4gb verbauen. Bei der SSD kannst du durchaus auch etwas deutlich kleineres nehmen.
Zuletzt bearbeitet:
![[SoD]r4z0r](/community/data/avatars/m/111/111944.jpg?1577437183){kind=avatar}
[SoD]r4z0r
Enthusiast
- Mitglied seit
- 11.04.2009
- Beiträge
- 3.950
@Master Luke
Unterstützt das Zotac Teil nicht max. 8GB RAM?
Ich nutze bei meiner Sophos Home 8GB (2x4), bei der SG230 auf der Arbeit reichen die 8GB auch total aus. Von 2GB rate ich ab und wenn der Preisunterschied zu vernachlässigen ist würde ich eher 8GB als 4GB nehmen.
Zum Thema SSD (bei meiner 120GB SSD):
Auch bei der SG230 auf der Arbeit reicht die SSD mehr als locker aus. Auch bei den älteren ASG 220v4/220v5 die wir im Einsatz hatten hat wurde die Platte nicht ansatzweise voll.
Unterstützt das Zotac Teil nicht max. 8GB RAM?
Ich nutze bei meiner Sophos Home 8GB (2x4), bei der SG230 auf der Arbeit reichen die 8GB auch total aus. Von 2GB rate ich ab und wenn der Preisunterschied zu vernachlässigen ist würde ich eher 8GB als 4GB nehmen.
Zum Thema SSD (bei meiner 120GB SSD):
Code:
Log partition size: 53008 MB
Free space: 49209 MB
Current fillup rate: 3 MB/day
Free space will be exhausted in 19242 days at current fillup rate.Auch bei der SG230 auf der Arbeit reicht die SSD mehr als locker aus. Auch bei den älteren ASG 220v4/220v5 die wir im Einsatz hatten hat wurde die Platte nicht ansatzweise voll.
Master Luke
Enthusiast
Danke euch!
Ich mache 2x2Gb rein und nehme eine vorhandene SSD aus dem Regal (120er oder 240er).
Ich mache 2x2Gb rein und nehme eine vorhandene SSD aus dem Regal (120er oder 240er).
Hallo zusammen,
hat hier schon jemand Erfahrung mit Hochrüstung vom RAM-Speicher bei den "kleineren" Modellen.
Explizit geht es in meinem Fall um eine SG 105.
Nach dem Wechsel des RAM-Riegels ist eine Verbindung auch innerhalb des Netzwerkes nicht möglich.
Was muss ich genau beachten?
Danke und LG
hat hier schon jemand Erfahrung mit Hochrüstung vom RAM-Speicher bei den "kleineren" Modellen.
Explizit geht es in meinem Fall um eine SG 105.
Nach dem Wechsel des RAM-Riegels ist eine Verbindung auch innerhalb des Netzwerkes nicht möglich.
Was muss ich genau beachten?
Danke und LG
Wo wir letztens beim Thema Schutz waren und ausbrechen aus VM usw: Hab ein eigenes Netz angelegt und dort einen einzelnen PC hingesteckt mit RDP von außen - Da war ein DC-User mit dem Namen "anna@uebungdc.de" und dem PW "anna" eingerichtet ohne Admin Settings. Keine 24h hat es gedauert (Nachdem ich Country Blocking aus Russia, USA, China abgestellt hab) bis jemand drauf war und meinte, den PC verschlüsseln zu müssen. (oder zumindest es zu versuchen - war wohl nicht so professionel)
Sophos EndPoint spuckte im WebAdmin aus, dass jemand eine "a22.exe" starten wollte:
Als ich mich dann mit dem Benutzer anna lokal angemeldet hab, war die russische Tastatur aktiviert und irgendein asia Hacking Team (Leider kein Bild gemacht, schade auch) Bild da mit der Aufforderung, Bitcoins zu kaufen um den PC zu entschlüsseln
Und falls wer fragt: Das war so nen alter ML110 G5 den ich hier rumstehen hatte - Schnell ESXi draufgekloppt und meinen Test DC und ne 08/15 Win8.1 VM ohne Daten usw. rüberkopiert und wirklich direkt an meine Sophos angehangen. Was ich mich jetzt eig. nur Frage: Ist es wirklich so leicht die DC herauszufinden? Ich mein, per rumtesten kommt man bestimmt direkt mit einem lokalen Benutzer Namens "anna" - Aber mit DC hinten dran? Vor allem "uebungdc.de"... Hmmm
Also niemals einfach nur ein Wort als Benutzer und keine einfachen PWs falls man direkt RDP Freigeben muss
Sophos EndPoint spuckte im WebAdmin aus, dass jemand eine "a22.exe" starten wollte:
Als ich mich dann mit dem Benutzer anna lokal angemeldet hab, war die russische Tastatur aktiviert und irgendein asia Hacking Team (Leider kein Bild gemacht, schade auch) Bild da mit der Aufforderung, Bitcoins zu kaufen um den PC zu entschlüsseln
Und falls wer fragt: Das war so nen alter ML110 G5 den ich hier rumstehen hatte - Schnell ESXi draufgekloppt und meinen Test DC und ne 08/15 Win8.1 VM ohne Daten usw. rüberkopiert und wirklich direkt an meine Sophos angehangen. Was ich mich jetzt eig. nur Frage: Ist es wirklich so leicht die DC herauszufinden? Ich mein, per rumtesten kommt man bestimmt direkt mit einem lokalen Benutzer Namens "anna" - Aber mit DC hinten dran? Vor allem "uebungdc.de"... Hmmm
Also niemals einfach nur ein Wort als Benutzer und keine einfachen PWs falls man direkt RDP Freigeben muss
Zuletzt bearbeitet:
poste doch mal das Security Log des Clients 
Da dürftest du sehen, was passiert ist, sofern das nicht schon gecleant wurde...
Bin mir aber grad nicht ganz sicher, allerdings könnte es reichen, wenn da jemand "anna | anna" probiert ohne die Domain... Zumindest ist die Domain in gewissen Konstellationen wurscht. So kannst du auch PC Übergreifend bei Windows auf die Freigaben der Clients drauf, wenn auf Quelle und Ziel User/PW gleich sind und der User am Quell PC auf eine Freigabe am Ziel PC geht, bei welchem eben die Freigabe auf den lokalen User mappt. -> ohne das die PCs selbst sich überhaupt kennen.
Das geht auch zwischen Single Client und AD Client, wie auch zwischen zwei völlig unterschiedlichen ADs.
Möglicherweise kann man das auch hintricksen mit RDP...
Grundsätzlich wundert das aber schon irgendwie... Es gibt zu Hauf offene RDP Hosts im Netz. Nicht zuletzt wohl einige gehostete Windows Maschinen irgendwo in der Cloud. Würde das keine 24h dauern, dann wären die alle samt lahm gelegt.
-> scheint mir eher ne unglückliche Konstellation gewesen zu sein oder sowas.
PS: dein RDP Port ist immernoch "offen" und lauscht auf RDP
Nur so als Nebenbei Info
Da dürftest du sehen, was passiert ist, sofern das nicht schon gecleant wurde...
Bin mir aber grad nicht ganz sicher, allerdings könnte es reichen, wenn da jemand "anna | anna" probiert ohne die Domain... Zumindest ist die Domain in gewissen Konstellationen wurscht. So kannst du auch PC Übergreifend bei Windows auf die Freigaben der Clients drauf, wenn auf Quelle und Ziel User/PW gleich sind und der User am Quell PC auf eine Freigabe am Ziel PC geht, bei welchem eben die Freigabe auf den lokalen User mappt. -> ohne das die PCs selbst sich überhaupt kennen.
Das geht auch zwischen Single Client und AD Client, wie auch zwischen zwei völlig unterschiedlichen ADs.
Möglicherweise kann man das auch hintricksen mit RDP...
Grundsätzlich wundert das aber schon irgendwie... Es gibt zu Hauf offene RDP Hosts im Netz. Nicht zuletzt wohl einige gehostete Windows Maschinen irgendwo in der Cloud. Würde das keine 24h dauern, dann wären die alle samt lahm gelegt.
-> scheint mir eher ne unglückliche Konstellation gewesen zu sein oder sowas.
PS: dein RDP Port ist immernoch "offen" und lauscht auf RDP
Nur so als Nebenbei Info
Verstehe ich nun ehrlich gesagt sooo nicht.
Einerseits postest du hier, dass innerhalb weniger Stunden da irgendwelche Russen scheinbar über eine RDP Verbindung auf ein Windows eingedrungen sind und andererseits sagst du, da ist sowieso allerhand offen!? Wie passt das denn zusammen?
Für gewöhntlich ist wohl das Risiko, wenn da einmal wer irgendwie "drin" ist, höher von drinnen einfach weiter zu machen als wenn er gar nicht erst rein kommt...
PS: hat wer eigentlich hier schonmal ein Site-to-Site SSL VPN zwischen einer aktuellen UTM (als Client!) und einem OpenVPN Server -> gehostet irgendwo in der Cloud, herstellen können? Im Moment tue ich mich irgendwie schwer damit...
Der Plan sieht vor, irgendwo in die Cloud so ne OpenVPN Flunder hinzustellen, dort die Mobilen Clients einzufangen und über nen Tunnel nach Hause ins Netzwerk zu lassen. Nicht überall hin, aber in Teilen zumindest. Eben, was so unterwegs notwendig ist.
Leider sind die ganzen Howtos im Netz irgendwie, nunja, wie soll man sagen, teils unterschiedlich wie die Nacht, teils unvollständig, teils völlig ohne Erklärungen, WAS da überhaupt stattfindet usw. usf.
Einerseits postest du hier, dass innerhalb weniger Stunden da irgendwelche Russen scheinbar über eine RDP Verbindung auf ein Windows eingedrungen sind und andererseits sagst du, da ist sowieso allerhand offen!? Wie passt das denn zusammen?
Für gewöhntlich ist wohl das Risiko, wenn da einmal wer irgendwie "drin" ist, höher von drinnen einfach weiter zu machen als wenn er gar nicht erst rein kommt...
PS: hat wer eigentlich hier schonmal ein Site-to-Site SSL VPN zwischen einer aktuellen UTM (als Client!) und einem OpenVPN Server -> gehostet irgendwo in der Cloud, herstellen können? Im Moment tue ich mich irgendwie schwer damit...
Der Plan sieht vor, irgendwo in die Cloud so ne OpenVPN Flunder hinzustellen, dort die Mobilen Clients einzufangen und über nen Tunnel nach Hause ins Netzwerk zu lassen. Nicht überall hin, aber in Teilen zumindest. Eben, was so unterwegs notwendig ist.
Leider sind die ganzen Howtos im Netz irgendwie, nunja, wie soll man sagen, teils unterschiedlich wie die Nacht, teils unvollständig, teils völlig ohne Erklärungen, WAS da überhaupt stattfindet usw. usf.
Im Moment scheitere ich wohl am Verständnis der OpenVPN Config
-> scheint mir aber eher ein Layer8 Problem zu sein, sprich man ließt genügend viele HowTos/Tutorials und am Ende ist man noch "dümmer", weil alle in Teilen zumindest was anderes aussagen...
Im ersten Step gehts mir primär erstmal darum zu verstehen, welche Parameter ich zwangsweise notwendig brauche, damit das mit der UTM funktioniert. Soweit mir bekannt kann man über die UTM nur mit den Config Files arbeiten. Sprich keine direkte auf Kommandozeile Editierung der Parameter -> das File hat irgendwie Endung .apc -> das Files von OpenVPN hat irgendwie .ovpn (per default?). Es gibt Shellscripte im Netz, die das migrieren können.
Nur was muss nun wirklich auf der Serverseite konfiguriert werden, damit die UTM damit was anfangen kann? Soweit ich das verstehe, die UTM will wohl A) ein Zertifikat haben und B) User/PW zusätzlich?? Richtig?
Achso bevor es untergeht, im Moment studiere ich den Spaß erstmal in einer Trockenübung. Sprich das ist ein Testaufbau.
Zur Erklärung, UTM + OpenVPN Server auf Ubuntu 16.04, jeweils eine VM zusammen über ein Gateway verbunden, um das "Internet" zu simulieren. Die UTM + der OpenVPN Server haben eine statische Route zum Netz, wo der OpenVPN Server steht über das Gateway und umgekehrt. Der public Client sinnigerweise nicht! Hinter der UTM steht ein Mint als Client mit def. GW auf die UTM sowie es ein weiteres Mint gibt, was im Netz des Ubuntu ist.
Was soll rauskommen?
Der public Client soll einen Tunnel zum OpenVPN Server aufbauen, der OpenVPN Server und die UTM betreiben eine Site-to-Site Verbindung und der public Client soll A) zu Ressourcen hinter der UTM kommen und (helle grüne Linie) B) über die UTM (Proxy) surfen. (dunkle grüne Linie)
Im zweiten Step -> aber erst nachgelagert zur Grundfunktion, sollen Clients im internen Netz (rechts auf dem Bild) über die UTM (Proxy) gewisse Seiten nicht direkt erreichen, sondern über den Tunnel zum OpenVPN Server und dort dann ins Netz gehen. Das löse ich warscheinlich über einen Parent-Proxy um bspw. Youtube und diversem anderen Streamingzeug, was dank bescheidenem Telekom Peering äußerst mau läuft, besser nutzen zu können.
Der Testaufbau lässt sich so fast 1:1 auf den späteren Live-Aufbau adaptieren, nur das dort dann noch ein paar mehr Instanzen zwischen sind. Die Live-UTM steht im Moment nicht direkt public, sondern ist hinter einem Router über ein Transit-Netz (v4) genattet. IPv6 bezieht sie direkt eine IP vom Router davor, wobei ich das ggf. später noch umstelle und mit ULAs arbeiten werde/will. Interm im Netz wird im Moment v4 only gefahren. Der Router vorn ist im Moment ein Speedport -> der kann nix mit statischen Routen anfangen, der wird ggf. noch getauscht um nicht doppelt zu NATen usw.
-> scheint mir aber eher ein Layer8 Problem zu sein, sprich man ließt genügend viele HowTos/Tutorials und am Ende ist man noch "dümmer", weil alle in Teilen zumindest was anderes aussagen...
Im ersten Step gehts mir primär erstmal darum zu verstehen, welche Parameter ich zwangsweise notwendig brauche, damit das mit der UTM funktioniert. Soweit mir bekannt kann man über die UTM nur mit den Config Files arbeiten. Sprich keine direkte auf Kommandozeile Editierung der Parameter -> das File hat irgendwie Endung .apc -> das Files von OpenVPN hat irgendwie .ovpn (per default?). Es gibt Shellscripte im Netz, die das migrieren können.
Nur was muss nun wirklich auf der Serverseite konfiguriert werden, damit die UTM damit was anfangen kann? Soweit ich das verstehe, die UTM will wohl A) ein Zertifikat haben und B) User/PW zusätzlich?? Richtig?
Achso bevor es untergeht, im Moment studiere ich den Spaß erstmal in einer Trockenübung. Sprich das ist ein Testaufbau.
Zur Erklärung, UTM + OpenVPN Server auf Ubuntu 16.04, jeweils eine VM zusammen über ein Gateway verbunden, um das "Internet" zu simulieren. Die UTM + der OpenVPN Server haben eine statische Route zum Netz, wo der OpenVPN Server steht über das Gateway und umgekehrt. Der public Client sinnigerweise nicht! Hinter der UTM steht ein Mint als Client mit def. GW auf die UTM sowie es ein weiteres Mint gibt, was im Netz des Ubuntu ist.
Was soll rauskommen?
Der public Client soll einen Tunnel zum OpenVPN Server aufbauen, der OpenVPN Server und die UTM betreiben eine Site-to-Site Verbindung und der public Client soll A) zu Ressourcen hinter der UTM kommen und (helle grüne Linie) B) über die UTM (Proxy) surfen. (dunkle grüne Linie)
Im zweiten Step -> aber erst nachgelagert zur Grundfunktion, sollen Clients im internen Netz (rechts auf dem Bild) über die UTM (Proxy) gewisse Seiten nicht direkt erreichen, sondern über den Tunnel zum OpenVPN Server und dort dann ins Netz gehen. Das löse ich warscheinlich über einen Parent-Proxy um bspw. Youtube und diversem anderen Streamingzeug, was dank bescheidenem Telekom Peering äußerst mau läuft, besser nutzen zu können.
Der Testaufbau lässt sich so fast 1:1 auf den späteren Live-Aufbau adaptieren, nur das dort dann noch ein paar mehr Instanzen zwischen sind. Die Live-UTM steht im Moment nicht direkt public, sondern ist hinter einem Router über ein Transit-Netz (v4) genattet. IPv6 bezieht sie direkt eine IP vom Router davor, wobei ich das ggf. später noch umstelle und mit ULAs arbeiten werde/will. Interm im Netz wird im Moment v4 only gefahren. Der Router vorn ist im Moment ein Speedport -> der kann nix mit statischen Routen anfangen, der wird ggf. noch getauscht um nicht doppelt zu NATen usw.
Zuletzt bearbeitet:
An der Stelle würde ich eigtl. empfehlen, OpenVPN mal komplett zu Fuß aufzusetzen und die man page mal komplett durchzulesen, bevor man sich mit unnötigen Abstraktionen rumschlägt.
Wenn man weiß, wie es "eigtl." funktionieren sollte, ist es leichter, bestimmte Sachverhalte einzuordnen, die einem das Klickibunti-Interface vorsetzt. Das ist zwar das genaue Gegenteil von dem, was so ein Interface bezwecken soll, aber ich halt absolut nichts davon, _nur_ das Interface zu kennen und nicht zu wissen, was dahinter eigtl. abgeht.
Grundlegend gibt es verschiedene Aspekte, die ein OpenVPN-Setup beinhaltet:
Layer 2 vs. Layer 3: Übertrage ich komplette Ethernet-Frames oder nur IPv4/IPv6? Site-to-site kann man mit beiden machen, Roadwarrior eher Layer 3. Mein Site-to-site-VPN läuft auch als Layer 3.
UDP vs. TCP als äußeres Trägerprokoll: Wenn möglich, immer UDP. TCP in TCP tunneln ist schlecht.
Dynamische vs. statische IP-Config: Konfiguriere ich Interfaces und Routen "außerhalb" von OpenVPN manuell selber oder lasse ich das OpenVPN machen? Bei festen Site-to-site-VPNs wäre ich für die erste Variante, bei Roadwarrior-Setups für letztere.
Statische Keys vs. komplettes TLS mit Zertifikaten: Hier eigtl. immer TLS.
Authentifizierung mit Zertifikaten vs. User/PW: Grundsätzlich sind Zertifikate der bessere Weg. User/PW eigtl. nur, wenn man das Zertifikat mit Key aus der Hand gibt, sprich man ist entweder öffentlicher VPN-Anbieter oder hat in der Firma nicht die Möglichkeit, jedem Client ein eigenes Zertifikat zu verpassen.
Darüber hinaus kann man dann noch Sachen wie Routen oder DNS-Infos zu den Clients pushen, das ist dann aber quasi alles schon nach dem Aufbau des VPNs. Es ist nicht direkt DHCP als Protokoll, aber vom Prinzip her das Gleiche.
Das ist zwar wenig konkret auf UTM bezogen, aber ich finde, man sollte OpenVPN wirklich "kennen".
Die wirklich relevanten Bits meiner Site-to-site-Config auf dem Server z.B. beschränken sich eigtl. auf Folgendes:
Client:
Mehr ist es nicht. Die Interfaces sind vorkonfiguriert mit demselben /31, die Routen werden auch passend manuell gesetzt.
Wenn man weiß, wie es "eigtl." funktionieren sollte, ist es leichter, bestimmte Sachverhalte einzuordnen, die einem das Klickibunti-Interface vorsetzt. Das ist zwar das genaue Gegenteil von dem, was so ein Interface bezwecken soll, aber ich halt absolut nichts davon, _nur_ das Interface zu kennen und nicht zu wissen, was dahinter eigtl. abgeht.
Grundlegend gibt es verschiedene Aspekte, die ein OpenVPN-Setup beinhaltet:
Layer 2 vs. Layer 3: Übertrage ich komplette Ethernet-Frames oder nur IPv4/IPv6? Site-to-site kann man mit beiden machen, Roadwarrior eher Layer 3. Mein Site-to-site-VPN läuft auch als Layer 3.
UDP vs. TCP als äußeres Trägerprokoll: Wenn möglich, immer UDP. TCP in TCP tunneln ist schlecht.
Dynamische vs. statische IP-Config: Konfiguriere ich Interfaces und Routen "außerhalb" von OpenVPN manuell selber oder lasse ich das OpenVPN machen? Bei festen Site-to-site-VPNs wäre ich für die erste Variante, bei Roadwarrior-Setups für letztere.
Statische Keys vs. komplettes TLS mit Zertifikaten: Hier eigtl. immer TLS.
Authentifizierung mit Zertifikaten vs. User/PW: Grundsätzlich sind Zertifikate der bessere Weg. User/PW eigtl. nur, wenn man das Zertifikat mit Key aus der Hand gibt, sprich man ist entweder öffentlicher VPN-Anbieter oder hat in der Firma nicht die Möglichkeit, jedem Client ein eigenes Zertifikat zu verpassen.
Darüber hinaus kann man dann noch Sachen wie Routen oder DNS-Infos zu den Clients pushen, das ist dann aber quasi alles schon nach dem Aufbau des VPNs. Es ist nicht direkt DHCP als Protokoll, aber vom Prinzip her das Gleiche.
Das ist zwar wenig konkret auf UTM bezogen, aber ich finde, man sollte OpenVPN wirklich "kennen".
Die wirklich relevanten Bits meiner Site-to-site-Config auf dem Server z.B. beschränken sich eigtl. auf Folgendes:
Code:
[...]
cipher [...]
comp-lzo
dev tun0
persist-key
persist-tun
tls-server
ca keys/ca.crt
cert keys/[...].crt
key keys/[...].key
tls-auth [...]/keys/tlsauth.key 0
dh [...]/keys/dh4096.pem
keepalive 15 60
local [...]
proto udp
port 1194Client:
Code:
[...]
cipher [...]
comp-lzo
dev tun11
persist-key
persist-tun
tls-client
ca [...]/keys/ca.crt
cert [...]/keys/[...].crt
key [...]/keys/[...].key
tls-auth [...]/keys/tlsauth.key 1
ns-cert-type server
keepalive 15 60
<connection>
remote [...] 1194 udp
nobind
</connection>Mehr ist es nicht. Die Interfaces sind vorkonfiguriert mit demselben /31, die Routen werden auch passend manuell gesetzt.
Zuletzt bearbeitet:
Luckysh0t
Enthusiast
Mal ne Frage für Anfänger: Warum der Weg über den VPN Server in der Cloud und die Clients nicht direkt an die UTM VPN ? Umgehung einer Clientbegrenzug der UTM oder DS Lite ? Mehr fällt mir nicht ein - wenn auch gute Gründe.
Zuletzt bearbeitet:
Ist das nicht der Sinn einer Testleitung? Wie gesagt, ging über eine eigene Leitung wo so nen poppeliger Router für die Einwahl sorgt, da ist einiges offen, damit wenn ich wsa zum testen dahinter hänge keine Einschränkungen habe. (Modem könnte man auch direkt machen, aber meh)
Und wie soll jemand von innen weiter machen, wenn die VM, die DC VM und der Host nicht mehr existieren? Darum gings ja. Hab auch extra dem Netzwerk nichts nach außen erlaubt - Also auf scatchy Websites usw. konnte ähh nicht zugegriffen werden.
Hab an sich auch bisher keine Probleme gehabt mit nem Host per RDP direkt freigeben - Privat, Geschäftlich und bei Kunden sind da aber gescheite Usernames und vor allem PWs (8 Zeichen, Groß, Klein und Zahlen laut DC ist ja Standard - Beim ADM glaub ich zudem auch noch Sonderzeichen? Bin mir da aber grad nicht sicher) und nicht ein Name und das gleiche PW.War halt mal Interessant zu testen finde ich. Frage ist nur, ob mit IP oder einen der vielen Free-DNS Adressen zugegriffen wurde, aber das kann ich so wohl nicht erfahren.
Hab jetzt bissl gegoogelt, aber jetzt nichts dazu gefunden wie man sich auf eine RDP mit nem DC User verbindet, wenn man nur Username und nicht die DC kennt. Da forsche ich mal morgen in der Arbeit nach, hab da ja zum Glück genug Zeit
1) Ich hab mir das nun nochmal angesehen -> 2x OpenVPN auf Ubuntu 16.04... Der "Test" mit der UTM war so oder so nur die erste Idee. Möglicherweise kommt auch auf der internen Seite ein OpenVPN als Client nativ auf ner mini Linux zum Einsatz, die dann intern an ein Interface an die UTM gehangen wird. Es geht mir natürlich im ersten Step um das Verstehen -> deswegen ja auch der Testaufbau.
2) L3 wäre eher die Wahl. L2 brauch ich dort an der Stelle nicht... Zumindest fällt mir dazu aus dem Hut kein Anwendungsfall meinerseits ein, wobei doch, könnte ich mein Entertain von Remote erreichen
3) Es wird eher UDP werden... Bei der Mobile Client zu OpenVPN Server Geschichte bin ich aber noch unschlüssig... Weist du ob man eine Art "Fallback" Methode fahren kann? Weil wenn der Client, aus welchen Gründen auch immer mal nicht auf dem UDP Port ins Netz kommt -> geht keine Verbindung. Eine TCP443 Geschichte dürfte in so ziemlich jeder Lebenslage aber immer offen sein. Für die Site-to-Site Geschichte gibts diese Beschränkung hingegen nicht.
4) Dynamisch wäre schickt, Statisch für die Site-to-Site Verbindung geht ebenso. Der Client sollte es hinten aber dynamisch haben, weil einfach einfacher...
5) Ist mir an der Stelle wohl fast egal... "Sicher" und Funktional muss es sein. Der Initiale Aufwand ist mir persönlich fast egal.
6) beides? -> zumindest scheint das die UTM so zu fahren. Für den Test kann man es wohl durchgehen/probieren und verinnerlichen.
7) ja, das wäre der Nachgang...
8) So in etwa habe ich das dort bei mir ebenso... Die UTM hat damit scheinbar aber ein Problem.
Ich hab das wie gesagt nun mal mit 2x OpenVPN gemacht... Funktioniert soweit. Ich komme nun vom Mint Client "intern" über den OpenVPN Client (ehemals UTM) über den Tunnel zum OpenVPN Server...
- - - Updated - - -
Für mich das ist ein Stück weit "Alu-Hut-Denke", blendet man das aus, bleibt quasi folgendes über:
- Der Server in der Cloud hat ne fixe IP, die ist immer gleich und idealerweise auch gut erreichbar.
- Meine UTM hängt hinter ner stino VDSL Telekom Leitung. A) dynamische IP, B) Telekom -> bescheidenes Peering
- Ich möchte so wenig wie möglich offene Ports Zuhause haben
Direkt zur UTM würde natürlich auch gehen, keine Frage. Nur mach ich damit die UTM eben "auf"... Teils vom Ausland benötigter Access ist halt nicht so schick. Biste doch mal irgendwo in China oder Russland oder sonstwo unterwegs -> muss ich nicht zwangsweise den direkten Weg gehen...
Hab jetzt bissl gegoogelt, aber jetzt nichts dazu gefunden wie man sich auf eine RDP mit nem DC User verbindet, wenn man nur Username und nicht die DC kennt. Da forsche ich mal morgen in der Arbeit nach, hab da ja zum Glück genug Zeit
Was ich dir zumindest noch dazu sagen kann, wenn du zwei Clients hast, die beide AD Member sind aber in unterschiedlichen Domains -> die sich wiederum nicht! kennen. Also kein Trust oder ähnliches. Dann kannst du trotzdem bei korrekter Eingabe von User und PW im RDP Anmeldefenster eine Session von einem zum anderen aufbauen ohne die Domain zu wählen/zu schreiben. Per default trägt ja der Client, der AD Member ist als Domain seine eigene ein, wenn du nicht explizit VOR den Usernamen die Domain mit Syntax "domain\" schreibst bzw. den User als UPN in Form von "user@domain.tld" angibst.
Außer bei XP/2003 Server und älter, da geht das wohl so nicht... Allerdings wirst du dort auch direkt auf den Anmeldeschirm connectet ohne ein Authentication Fenster, wie es ab Vista/2008 der Fall ist...
Scheint mir so zu sein, dass der RDP Dienst die getätigte Eingabe per default dann als eine Art Fallback zu seinem DC schickt -> und der authentifiziert, wenn die Eingabe richtig ist...
Klar. Man kann soviele OpenVPN-Prozesse und tun(4) devices haben, wie man will. Bei mir habe ich für mobile Clients letztendlich auch jeweils TCP und UDP offen. Per Paketfilter wird das sogar von mehreren Ports eingesammelt. Ich kann auf 1194/udp, 1194/tcp, aber auch 22/tcp, 53/tcp, 80/tcp oder 443/tcp reinkommen. Dank HAProxy geht sogar SSH/HTTPS/OpenVPN auf einem einzigen Port. 53/udp ist dann allerdings für iodine reserviert.
Zertifikate hat man sowieso. Also ist die eigentliche Frage nur, ob man zusätzlich noch ein Passwort braucht. Wenn das strikt für Eigengebrauch ist und man die Zertifikate und Keys nicht aus der Hand gibt, wie das bei nem Provider oder ner Firma der Fall wäre, ist ein Passwort überflüssig. Es dient quasi nur dazu, mehrere User unterscheiden zu können, die alle dasselbe Zertifikat verwenden.
Die Client-Config biete verschiedene Profile als Möglichkeit, die bei Nichtverfügbarkeit der Reihe nach durchprobiert werden. Im Normalfall hat man maximal 2 Instanzen (TCP und UDP), auf die man mehrere Ports forwardet. Unterschiedliche OpenVPN-Prozesse heißt dann natürlich auch unterschiedliche IP-Bereiche, außer du machst Layer2 und bridgst alle tap-Geräte einfach zusammen.
Ah das klingt interessant... Was das zusammenbridgen angeht, das dürfte für meinen Zweck wenig eine Rolle spielen. Ich will ja nur die Clients vorn einsammeln und dann durch den Site-to-Site Tunnel nach Hause routen... Zur Not spanne ich halt zwei Tunnel von Zuhause zum Server in der Clound und route das hinten. Die mobilen Endgeräte müssen sich auch nicht sehen oder direkt auf Ressourcen auf dem Server zugreifen, außer den OpenVPN Server (Instanzen)
Aber ich denke das sind dann am Ende eher Details, die Basis muss für mich erstmal klar sein und stehen...
Ich habe (für die Details) ggf. noch die fixe Idee, das ganze in Docker Container zu verpacken. Mal gucken wie sich das realisieren lässt... So könnte man die Instanz(en) für die Mobile Einwahl von einer anderen Instanz trennen, die für einen Zugriff aus der anderen Richtung her über einen Proxy oder ggf. direkt genattet herhalten könnte. Und das ganze dann noch losgelöst von Dritten Containern. Klingt für mich erstmal soooo schlecht nicht.
Allerdings teste ich mich nach erstem Erfolg erstmal das jetzige Konstrukt auf die UTM als Client zu adaptieren...
Aber ich denke das sind dann am Ende eher Details, die Basis muss für mich erstmal klar sein und stehen...
Ich habe (für die Details) ggf. noch die fixe Idee, das ganze in Docker Container zu verpacken. Mal gucken wie sich das realisieren lässt... So könnte man die Instanz(en) für die Mobile Einwahl von einer anderen Instanz trennen, die für einen Zugriff aus der anderen Richtung her über einen Proxy oder ggf. direkt genattet herhalten könnte. Und das ganze dann noch losgelöst von Dritten Containern. Klingt für mich erstmal soooo schlecht nicht.
Allerdings teste ich mich nach erstem Erfolg erstmal das jetzige Konstrukt auf die UTM als Client zu adaptieren...
besterino
Legende
Nur eine Idee: Du könntest auch den OpenVPN Server einfach zu deinem Host stellen und von zu Hause statt über site2site als normaler Client connecten. Bei VPN kannst Du ja einstellen, dass sich die Clients gegenseitig sehen können. Kann jetzt aber nicht abschätzen, ob das zu Deiner Alu-Hut-Strategie passt. Müsstest dann im Zweifel aber auch deine UTM vermutlich an der ein oder anderen Stelle aufbohren (wenn Du nicht die VPN-Connection generell offen fährst bzw. die UTM in den Tunnel überhaupt reinschauen kann).
Irgendwo steht in den Anforderungen was von 4GB RAM und 100GB Disk, ich hab einen virtuelle UTM mit einer 40GB Disk.
Ich kann mich erinnern das ich test weise mal eine 32GB CF Card nutzen wollte und das der Installer dort verweigert hat - weil die Disk mindestens 40GB groß sein muss.
Weiß aber nicht ob das noch immer so ist.
Ich kann mich erinnern das ich test weise mal eine 32GB CF Card nutzen wollte und das der Installer dort verweigert hat - weil die Disk mindestens 40GB groß sein muss.
Weiß aber nicht ob das noch immer so ist.
ich kann mich erinnern das ich mal mit ner vm mit 40gb probleme hatte weil mir da die hdd volllief. hab jetzt immer 100gb genommen für meine installs und ruhe gehabt. so lange du Web Protection, Intrusion und sowas aber nicht direkt nutzt läuft da eigentlich garnichts voll
mueder joe
Enthusiast
Hab exakt das Ding bei mir als UTM laufen. Geht problemlos.
Solang man regelmäßig da drauf schaut hätte ich keine Bedenken.
Zuletzt bearbeitet: