Aus Subnetz auf paralleles Subnetz zugreifen

Hallo zusammen,

ich versuche gerade zwei Netze miteinander zu verbinden, bekomme aber eine Fehlermeldung.

Insgesamt existieren drei Fritzboxen A, B, C, wobei A (192.168.1.0/24) am Internet hängt und B (192.168.2.0/24) dahinter und A als Gateway nutzt. C (192.168.10.0/24) ist eine per VPN-Tunnel über das Internet erreichbare Box.

In A ist die VPN-Konfiguration für den Tunnel zu C eingerichtet. Wenn ich also im Netz A bin und eine Adresse aus dem Adressbereich von C aufrufe, wird der VPN-Tunnel aufgebaut und ich bin mit C verbunden. So weit so gut.
Wenn ich nun im Netz B bin und eine Adresse aus dem Netz C aufrufe, funktioniert das nicht. Auch nachvollziehbar. Aus diesem Grund dachte ich daran, in B eine statische Route einzurichten, die wie folgt aussieht:

bildschirmfoto 2022-01-13 um 21.47.44

Kann mir jemand erklären, wo mein Denkfehler ist?

Danke und Grüße
Stefan

Content-Key: 1720467417

Url: https://administrator.de/contentid/1720467417

Ausgedruckt am: 27.01.2022 um 21:01 Uhr

Mitglied: incisor2k
incisor2k 13.01.2022 um 22:25:27 Uhr
Goto Top
'N Abend.
Ich vermute mal, dass das von dir angegebene Gateway außerhalb des Netzbereichs X.X.10.0/24 liegt und ist damit nicht verwendbar.
Mitglied: IceBeer
IceBeer 13.01.2022 aktualisiert um 22:31:47 Uhr
Goto Top
Hi,

du schreibst "und B (192.168.2.0/24) dahinter und A als Gateway nutzt".
Denke du meinst damit A ist für FB B das Standardgateway
-> alles was B selbst nicht kenn schickt es an A
-> somit ist deine Route damit abgedeckt
oder verwurstel ich hier was?
Ich denke eher das C den Rückweg zu B nicht kennt. Denke dir fehlt eine Route auf FB C alles für 192.168.2.0/24 soll an 192.168.1.1 gehen.

Gruß IceBeer
Mitglied: alve89
alve89 14.01.2022 um 05:40:49 Uhr
Goto Top
Zitat von @IceBeer:

Hi,

du schreibst "und B (192.168.2.0/24) dahinter und A als Gateway nutzt".
Denke du meinst damit A ist für FB B das Standardgateway
-> alles was B selbst nicht kenn schickt es an A

Das ist korrekt.

Ich denke eher das C den Rückweg zu B nicht kennt. Denke dir fehlt eine Route auf FB C alles für 192.168.2.0/24 soll an 192.168.1.1 gehen.

Der Tunnel lässt sich nur von A zu C aufbauen, nicht andersrum. Die von dir beschriebene Route würde also nur bei bestehendem Tunnel funktionieren. Außerdem muss der Router wissen, dass die Anfrage an C von B gestartet wurde und daher die Antwort auch dorthin (an B) weiterleiten - das ist nach meinem Verständnis die Kernaufgabe eines Routers. Oder habe ich da einen Denkfehler?

Und ich bekomme ja schon beim Einrichten der Route in B die Fehlermeldung, nicht erst beim Ausführen, daher ist meine Befürchtung, dass ich schon in der Theorie etwas missverstanden habe.



Zitat von @incisor2k:

'N Abend.
Ich vermute mal, dass das von dir angegebene Gateway außerhalb des Netzbereichs X.X.10.0/24 liegt und ist damit nicht verwendbar.

Diese statischen Routen sind laut der Beschreibung in der FB dazu gedacht, unbekannte Netze „bekannt“ zu machen:


x.x.2.0 kennt x.x.10.0 nicht und muss daher erstmal dorthin kommen.
Ich will ja das ganze Netz erstmal bekannt machen, wie soll ich dazu ein Gateway aus diesem Adressbereich nutzen, wenn das ganze Subnetz unbekannt ist?


Soweit erstmal danke für die bisherigen Antworten, ich wüsste hier jedoch leider nicht, wie ich mit den begrenzten Bordmitteln der FB eure möglichen Ursachen lösen könnte - habt ihr noch weitere Ideen?
Mitglied: incisor2k
incisor2k 14.01.2022 um 06:46:21 Uhr
Goto Top
Moin.
Korrekt, grundsätzlich mag das gehen, die Fritzbox kann das aber nicht.
Vielleicht hilft dir dieser, ähnliche Beitrag, auch wenns da eher um Subnetze geht.

https://administrator.de/contentid/117163#comment-443596
Mitglied: IceBeer
IceBeer 14.01.2022 um 09:14:21 Uhr
Goto Top
Hallo alve89,

nur zur Sicherheit dass wir uns nicht missverstanden haben drösel ich das mit dem Routing (auch für mich nochmal - Bild malen wollte ich jetzt nicht) auf:
A kennt 192.168.1.0/24 -> eigenes Netz
A erreicht Internet -> Default Gateway=Provider
A kennt 192.168.10.0/24 -> VPN Konfiguration

B kennt 192.168.2.0/24 -> eigenes Netz
B erreicht Internet -> Default Gateway=A -> Provider
B erreicht 192.168.1.0/24 -> Default Gateway=A
B erreicht 192.168.10.0/24 -> Default Gateway=A -> VPN Konfiguration

C kennt 192.168.10.0/24 -> eigenes Netz
C erreicht Internet -> Default Gateway=Provider
C kennt 192.168.1.0/24 -> VPN Konfiguration

Wenn ich jetzt nicht grad ganz falsch bin fehlt Folgendes um alle Wege zu haben:
Auf A: Route für 192.168.2.0/24 die auf B zeigt
-> damit sollten Pakete aus A für:
- 192.168.2.0/24 an B gehen
- 192.168.10.0/24 via VPN an C gehen
- der Rest zum Provider
Auf B: keine extra Route
-> damit sollten Pakete aus B für:
- 192.168.1.0/24 an A gehen
- 192.168.10.0/24 an A gehen, A gibt sie via VPN an C
- der Rest über A zum Provider
Auf C: Route für 192.168.2.0/24 die auf A zeigt
-> somit sollten Pakete aus C für:
- 192.168.1.0/24 via VPN an A gehen
- 192.168.2.0/24 via VPN an A gehen, A gibt sie an B
- der Rest zum Provider

Ob das ein schönes/gutes Design wäre weiß ich grad nicht. Der VPN Tunnel sollte sich meinem naiven Verständnis nach egal von wo du anfängst automatisch (wenn nicht anders konfiguriert) aufbauen, wenn er nicht schon steht.

ABER:
Vermutlich wird dich die Firewall auf B weder von A noch C "reinlassen", daher dürfte obiges mit der Hardware eher theoretischer Natur sein. Daher spielt es denk auch eine untergeordnete Rolle, ob der VPN Tunnel (bedingt durch Gegebenheiten oder Konfiguration) nur von einer oder beiden Seiten aufgebaut werden kann. Generell geht es da ja erst mal ums Routing, das jeder weiß, wo er welches Paket hinschicken müsste.
-> Insofern die FW von B nicht dazwischen spucken würde, könnte man das Routing ja mal bei bereits laufendem Tunnel probieren.

Gruß IceBeer
Mitglied: alve89
alve89 14.01.2022 um 09:41:35 Uhr
Goto Top
Sehr ausführliche Rückmeldung, danke. Aber:

Zitat von @IceBeer:
A kennt 192.168.1.0/24 -> eigenes Netz
A erreicht Internet -> Default Gateway=Provider
A kennt 192.168.10.0/24 -> VPN Konfiguration
B kennt 192.168.2.0/24 -> eigenes Netz
B erreicht Internet -> Default Gateway=A -> Provider
B erreicht 192.168.1.0/24 -> Default Gateway=A

Korrekt.

Zitat von @IceBeer:
B erreicht 192.168.10.0/24 -> Default Gateway=A -> VPN Konfiguration

Falsch. Genau das funktioniert nicht, auch wenn das nach meinem Verständnis durch die Konfiguration aus dem Screenshot eigentlich passieren soll.

Zitat von @IceBeer:
C kennt 192.168.10.0/24 -> eigenes Netz
C erreicht Internet -> Default Gateway=Provider

Korrekt.

Zitat von @IceBeer:
C kennt 192.168.1.0/24 -> VPN Konfiguration

Falsch, ist so aber auch gewollt, da C keine Konfiguration für den Verbindungsaufbau hat (C kennt A nicht).

Zitat von @IceBeer:
Wenn ich jetzt nicht grad ganz falsch bin fehlt Folgendes um alle Wege zu haben:
Auf A: Route für 192.168.2.0/24 die auf B zeigt
-> damit sollten Pakete aus A für:
- 192.168.2.0/24 an B gehen
- 192.168.10.0/24 via VPN an C gehen
- der Rest zum Provider

A soll nicht auf B zugreifen können (A ist eine "DMZ" mit IoT-Geräten, B ist das Privatnetz).

Zitat von @IceBeer:
Auf B: keine extra Route
-> damit sollten Pakete aus B für:
- 192.168.1.0/24 an A gehen
- der Rest über A zum Provider

Funktioniert.

Zitat von @IceBeer:
- 192.168.10.0/24 an A gehen, A gibt sie via VPN an C

Aufrufe von 192.168.2.0/24 an 192.168.10.0/24 funktionieren nicht, das wäre aber das, was gewünscht ist.

Zitat von @IceBeer:
Auf C: Route für 192.168.2.0/24 die auf A zeigt
-> somit sollten Pakete aus C für:
- 192.168.1.0/24 via VPN an A gehen
- 192.168.2.0/24 via VPN an A gehen, A gibt sie an B
- der Rest zum Provider

Aufrufe von C nach A und von A nach B sind nicht gewünscht. Bzw. [und hier weiß ich nicht, ob ich die einzelnen Protokolle richtig verstehe] als Antwort auf Anfrage von B an C auch über A an B zurück).

Zitat von @IceBeer:
Ob das ein schönes/gutes Design wäre weiß ich grad nicht. Der VPN Tunnel sollte sich meinem naiven Verständnis nach egal von wo du anfängst automatisch (wenn nicht anders konfiguriert) aufbauen, wenn er nicht schon steht.

Geht nicht, da C keine Kenntnis von A hat. Ist so gewollt.


Zitat von @IceBeer:
Vermutlich wird dich die Firewall auf B weder von A noch C "reinlassen", daher dürfte obiges mit der Hardware eher theoretischer Natur sein. Daher spielt es denk auch eine untergeordnete Rolle, ob der VPN Tunnel (bedingt durch Gegebenheiten oder Konfiguration) nur von einer oder beiden Seiten aufgebaut werden kann. Generell geht es da ja erst mal ums Routing, das jeder weiß, wo er welches Paket hinschicken müsste.
-> Insofern die FW von B nicht dazwischen spucken würde, könnte man das Routing ja mal bei bereits laufendem Tunnel probieren.

Die Schlussfolgerung macht Sinn für deine nicht ganz zutreffenden Annahmen der bestehenden Netzwerkstruktur. Den Test, ob von C nach A zugegriffen werden kann, wenn der Tunnel steht, muss ich noch machen. Ist ein guter Hinweis, auch wenn Zugriffe in diese Richtung selten bis (sehr wahrscheinlich) niemals stattfinden werden.


Ergebnis: Problem ist der Zugriff von
192.168.2.0/24 -> Standardgateway -> 192.168.1.0/24 -> VPN -> 192.168.10.0/24

Ich hoffe, damit ist zumindest der Ist-Zustand verständlich - Dank deiner sehr ausführlichen Aufgliederung!
Mitglied: NikosLykos
NikosLykos 14.01.2022 um 12:21:40 Uhr
Goto Top
Hallo alve89,


Kann mir jemand erklären, wo mein Denkfehler ist?

Und ich bekomme ja schon beim Einrichten der Route in B die Fehlermeldung, nicht erst beim Ausführen, daher ist > > meine Befürchtung, dass ich schon in der Theorie etwas missverstanden habe.

das Gateway ist das Gerät ("Tür") im eigenen Netz ("Zimmer"), über das andere Netze zu erreichen sind.
Wenn es im "Zimmer" nur eine "Tür" gibt, ist dieses Gerät das Standardgateway für alle Adressen außerhalb des Netzes.

Somit ist eine Route nur da nötig, wo das "Zimmer" mehrere "Türen" hat, d.h. es gibt mehrere Geräte im Netz, über die unterschiedliche Fremdnetze erreichbar sind, und nicht die "Standardtür" genutzt werden soll.

Bei dir hat nur das Netz der Fritzbox A mehrere Türen:
  • Internet (Standardgateway)
  • VPN zu FritzBox C
  • FritzBox B (um Antworten ins Netz 192.168.2.0/24 zu senden)

Gruß
NikosLykos
Mitglied: Reinartz
Reinartz 14.01.2022 um 12:36:54 Uhr
Goto Top
Ich denke es liegt einfach daran das die FB prüft ob GW und Netz zusammen passen. Ist bei Cisco Switchen auch so dass das GW im Netzbereich des Netzes sein muss. Bedeutet dein GW der Route auf FB B muss irgedwas mit 192.168.2.X /24 sein, sonst akzeptiert die FB die Eingabe nicht
Mitglied: pc-technik
pc-technik 14.01.2022 um 12:40:36 Uhr
Goto Top
Hallo @alve98,

du hast ein ein kleines Verständnisproblem:

Wenn die FB C das Netz B nicht kennt, dann wird es auf eine Anfrage (z.B ping) niemals antworten können, das es den Weg zum Netz B nicht kennt.

Gruß pc-technik
Mitglied: IceBeer
IceBeer 14.01.2022 um 19:02:11 Uhr
Goto Top
Hallo,

gerne, will ja helfen. ;-) face-wink

Zitat von @alve89:
Zitat von @IceBeer:
B erreicht 192.168.10.0/24 -> Default Gateway=A -> VPN Konfiguration

Falsch. Genau das funktioniert nicht, auch wenn das nach meinem Verständnis durch die Konfiguration aus dem Screenshot eigentlich passieren soll.

Ich behaupte: nicht falsch.
Es kann ja zwei Gründe geben dass es aus der Anwender Sicht nicht funktioniert:
1) Die Frage kommt nicht an
2) Die Antwort kommt nicht an
Behauptung: 2) Die Antwort kommt nicht an -> du brauchst eine Route für den Rückweg nicht den Hinweg.

Mal von der Firewall auf B abgesehen - die dich sehr wahrscheinlich eh blockt - ist vermutlich genau dass dein Problem:
Zitat von @alve89:
Zitat von @IceBeer:
C kennt 192.168.1.0/24 -> VPN Konfiguration
Falsch, ist so aber auch gewollt, da C keine Konfiguration für den Verbindungsaufbau hat (C kennt A nicht).

Damit hast du keine Möglichkeit C zu sagen über welchen Weg B zu erreichen.
Um von C nach B zu kommen fehlt dir die Route dass diese Daten an A müssen und nicht an das Default Gateway.

Evt. lässt sich meine Behauptung mit folgendem Szenario sogar beweisen:
- VPN Tunnel ist so konfiguriert, dass er "on-demand" aufgebaut wird
- VPN Tunnel ist NICHT aufgebaut
- Du sprichst von B aus C an
-> Dann müsste sich A dazu genötigt fühlen, den Tunnel zu C aufzubauen
Dennoch wirst du aus C keine Antwort bekommen, da C alles an sein Default Gateway schickt.

Gruß IceBeer
Mitglied: aqui
aqui 15.01.2022 aktualisiert um 17:20:43 Uhr
Goto Top
Wenn ich nun im Netz B bin und eine Adresse aus dem Netz C aufrufe, funktioniert das nicht. Auch nachvollziehbar.
Wieso ist das nachvollziehbar ?
Es kommt darauf an WIE die Fritz B an das Netz A angeschlossen ist. Wenn du das über den LAN1 Port gemacht hast (bestehende Internetverbindung nutzen) dann macht die Fritz B NAT (IP Adress Translation) ins Netz A. Sprich, sie taucht dort nicht mit Absender IPs 192.168.2.x auf sondern immer mit der Absender IP ihres LAN1 Ports der ja bei dieser Kopplung immer eine IP aus dem lokalen LAN der Fritz A hat, also 192.168.1.<lan1_fritz-b>
Fritz A "merkt" also in dieser Router Kaskade durch das NAT (IP Adress Translation) gar nichts von einem IP Netz Fritz B und behandelt diese Frames allesamt wie lokale IP Frames aus seinem LAN.
Statisches Routing an Fritz A und ganz besonders an B ist damit also auch überflüssig und nicht erforderlich. Ganz im Gegenteil ! Ist es eingetragen ist das eher kontraproduktiv in so einem LAN1 Koppelsetup mit NAT !
Das statische Routing an B ist deshalb also de facto FALSCH und völlig unsinnig oben im Screenshot weil du das nicht deaktivierbare NAT der FB völlig ignoriert hast ! :-( face-sad
Ein Wireshark Trace im Netz A hätte dir hier auch ohne Thread gleich die Augen geöffnet !

NAT ist am LAN1 Port der FB bekanntlich generell nicht abschaltbar, so das man immer mit dieser routingtechnischen Einbahnstrasse bei FritzBoxen leben muss. Eingehende Verbindungen die aus dem Netz A und aus dem Netz C kommen, können deshalb niemals das Netz B erreichen. Das ist mit FB Hardware so wegen der NAT Thematik technisch nicht möglich. Es geht immer nur andersrum von B nach A und nach C.
Ist beideseitiges Routing in so einem Setup erforderlich, wäre es sinnvoller deshalb keine FritzBox, sondern einen kleinen, preiswerten Koppelrouter an A zu verwenden, wie z.B. einen Mikrotik hAP lite bei dem problemlos das NAT deaktivierbar ist (siehe Tutorial unten). Auch OpenWRT fähige Router sind eine gute Alternative.

Folglich sollten also mit der o.a. FritzBox Kaskade alle Pakete aus dem Netz B über das VPN von A auch problemlos ins Netz C gelangen.
Das ganze Prozedere eines solchen Setups inklusive NAT Thematik ist in diesem Tutorial grundlegend erklärt ! (Suchfunktion lässt grüßen.. ;-) face-wink )
Kardinalssfrage ist also WIE Fritz B angeschlossen ist ??
Mitglied: alve89
alve89 17.01.2022 aktualisiert um 11:53:53 Uhr
Goto Top
Zitat von @aqui:
Kardinalssfrage ist also WIE Fritz B angeschlossen ist ??

Sie ist exakt so angeschlossen wie von dir beschrieben... :-( face-sad

Zitat von @aqui:
Das ganze Prozedere eines solchen Setups inklusive NAT Thematik ist in diesem Tutorial grundlegend erklärt ! (Suchfunktion lässt grüßen.. ;-) face-wink )

Wenn man weiß wonach man suchen soll, ja! :-D face-big-smile Hatte natürlich mehrfach Google bemüht und auch hier die SuFu, aber auf diesen Beitrag kam ich nicht. Meine Hauptsuche bezog sich immer auf die Fritzbox, da dort ja der Fehler herkommt...

Zitat von @IceBeer:
Evt. lässt sich meine Behauptung mit folgendem Szenario sogar beweisen:
- VPN Tunnel ist so konfiguriert, dass er "on-demand" aufgebaut wird
- VPN Tunnel ist NICHT aufgebaut
- Du sprichst von B aus C an
-> Dann müsste sich A dazu genötigt fühlen, den Tunnel zu C aufzubauen

Ich hatte tatsächlich erwartet, da genau das passiert! Und eigentlich funktioniert das ganze auch "on-demand", da bei der VPN-Konfiguration das Netz C (192.168.10.0) hinterlegt ist. Fritzbox A versteht also, dass Anfragen an x.x.10.0 über den VPN gehen sollen. Und da, wie in der Antwort von aqui geschrieben, sämtliche Anfragen aus Netz B von der gemeinsamen Adresse 192.168.1.254 kommen, bin ich davon ausgegangen, dass der Tunnel geöffnet wird.

Dennoch wirst du aus C keine Antwort bekommen, da C alles an sein Default Gateway schickt.
Das Problem habe ich damit verstanden (davon abgesehen, dass die Firewall B es vermutlich eh block). Aber: Warum schickt jedoch C Antworten an A, das Netz (x.x.1.0) kennt C ja auch nicht (es besteht nur ein einseitig aufgebauter VPN-Tunnel)?

Die einzige Möglichkeit, die von euch beschriebenen Probleme zu lösen, wären entweder eine FB auszutauschen oder eine zweite VPN-Verbindung zwischen B und C, das funktioniert dann wieder.
Ist evtl. sogar die sicherere Lösung, als meine DMZ mit einem externen Heimnetz zu verbinden. Allerdings komme ich dann auch nicht mehr von unterwegs auf C, wenn nur ein VPN zwischen B und C besteht. Oder gibt es die Möglichkeit eines "kaskadierten" VPN Internet -> FB A -> VPN -> FB B?
Mitglied: aqui
aqui 17.01.2022 um 12:25:33 Uhr
Goto Top
Habs gerade mal ausprobiert mit einer FritzBox Kaskade. In Ermangelung einer dritten FritzBox dann auf eine OPNsense Firewall. Das lokale LAN der kaskadierten FritzBox kam problemlos auf das LAN der OPNsense. Beweist mehr oder minder das das o.a. Design der Kaskade FB A und B auch generell so funktioniert.
Ist ja auch irgendwie klar, denn aus Sicht der FritzBox A ist die FB B ja lediglich wie ein zusätzlicher PC zu sehen. Vom Netz dahinter weiss A ja nichts.
Mitglied: alve89
alve89 23.01.2022 um 14:31:39 Uhr
Goto Top
@aqui Nun ist ja FB B (192.168.2.0) per LAN 1 an FB A (192.168.1.0) angeschlossen. Wie du schon richtig dargestellt hast, kommen alle aus dem Netz x.x.2.0 bei FB A von einer Adresse an (nämlich 192.168.1.254, das ist die Adresse von FB B im Netz A).
Habe ich es richtig verstanden, dass das mit den Fritzboxen nicht derart zu konfigurieren ist, dass die Anfragen bei FB A tatsächlich mit der jeweiligen Client-IP aus Netz B (also bspw. 192.168.2.25) ankommen, sondern immer nur mit der IP von FB B (192.168.1.254)?
Mitglied: aqui
aqui 23.01.2022 aktualisiert um 14:46:56 Uhr
Goto Top
dass die Anfragen bei FB A tatsächlich mit der jeweiligen Client-IP aus Netz B (also bspw. 192.168.2.25) ankommen
Ja, das hast du richtig erkannt.
Wie sollte es denn auch gehen ?? Die FritzBox B macht ja immer zwangsweise NAT an ihrem LAN1 Port mit dem sie an A kaskadiert ist. Das NAT ist bekanntlich bei FritzBoxen nicht abschaltbar.
Folglich "sieht" A also immer nur Fritz B IP Pakete mit seiner eigenen LAN IP Adresse (die, die der LAN1 Port der FritzBox B hat) als Absender. Erkennt also nie die wahren Absender IPs aus Netz B.
Sie kann also nie die wirkliche Absender IP des lokalen FritzB LANs erkennen. Die letztliche Zuordnung auf diese IPs macht nur Fritz B über ihre NAT Session Tabelle.
Klassische und simple NAT Logik ! ;-) face-wink

Wenn du kein NAT dort haben willst ist die FritzBox generell die falsche Hardware. Dann musst du einen Router verwenden bei dem das NAT frei konfigurierbar ist.
Mit einem 20 Euro Mikrotik hAP lite wäre das im Handumdrehen erledigt. Ebenso jeder Router der OpenWRT supportet. Alles andere an Router/Firewall Hardware was deaktivierbares NAT hat geht natürlich dann auch.
Heiß diskutierte Beiträge
general
Generator für endlose, kostenlose Energie? Ein gut gemachter Schwindel? gelöst beidermachtvongreyscullVor 1 TagAllgemeinOff Topic35 Kommentare

Mahlzeit Kollegen! Wenn ich mich strikt an physikalische Grundsätze halte, müsste ich sagen: Nein. Es ist nicht möglich. Ich stieß aber im Internet auf ein ...

general
FYI: In zwei Tagen zieht LetsEncrypt zahlreiche Zertifikate zurückipzipzapVor 1 TagAllgemeinVerschlüsselung & Zertifikate1 Kommentar

Hallo, zur Info, falls bei Euch übermorgen was knallt: Ruhiges Wochenende! ipzipzap ...

question
"minimale" Cloud-Telefonanlage gesuchtDatenreiseVor 1 TagFrageVoice over IP13 Kommentare

Hallo zusammen, ich bin auf der Suche nach einer Cloud-Telefonanlage, die sich für einen einzelnen Arbeitsplatz eignet und wollte hier fragen, ob jemand dazu einen ...

question
Abschätzung Nutzungsdauer von neuer Serverhardware gelöst lcer00Vor 22 StundenFrageHardware9 Kommentare

Hallo zusammen, bei uns stehen 2022 Neuanschaffungen an. Dabei geht es um einen Backupserver (das Cloud-Konzept überzeugt mich immer noch nicht vollständig ) und demnächst ...

tutorial
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry PiaquiVor 1 TagAnleitungLAN, WAN, Wireless1 Kommentar

Einleitung Das folgende Tutorial erhebt keinen Anspruch auf Vollständigkeit und ist ein einfaches Framework was die Funktion eines IPsec VPN Servers im groben Rahmen aufzeigt. ...

question
Vorkehrungen für einen StromausfallahussainVor 23 StundenFrageNetzwerke10 Kommentare

Hallo, wir betreiben ein Netzwerk mit 8 Clients, Router, Switches, IP-Telefonen, NAS und einem kleinen Anwendungsserver. Unsere einzige Vorkehrung gegen einen Stromausfall/Blackout ist aktuell eine ...

question
PfSense: nach 27-stündigem Ausfall der Deutschen Telekom streiken IPSec + OpenVPN gelöst vafk18Vor 1 TagFrageNetzwerke9 Kommentare

Einen Gruß aus der Eifel, nachdem wir wieder mal von einer großflächigen Störung der Telekom-Anschlüsse (Ausfall eines DSLAM mit mehreren Tausend Teilnehmern) heimgesucht wurden, deren ...

question
Backup Software für PostgreSQLDaniVor 1 TagFrageDatenbanken11 Kommentare

Moin, für eine Anwendung kommt PostgreSQL 13.5 zum Einsatz. Leider nicht unter Linux, sondern läuft unter Windows Server 2019. Nun gibt es für jeden Kollegen ...