Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?


  • Hallo Zusammen!

    Ich weiß das ich hier falsch bin, und es hier ein Off-Topic gibt. Aber mein schriftliches Englisch ist so ziemlich beschissen wenn ich ehrlich bin.

    Und da ich letztens hier ruckzuck und kompetent weitergeholfen wurde, wollt ich gern hier meine Frage stellen :-)

    Es geht sich um folgendes: Ich habe nun dank euch erfolgreich ein OpenVPN IPv6 only Server auf pfSense konfiguriert. Da ich WAN-Seite nur eine IPv6 Adresse habe.

    Nun möchte ich wie im Titel "schematisch" dargestellt habe fragen ob dies möglich ist ein vserver zu mieten, diesen über IPv6-only nach Hause verbinden über openvpn, und ein IPv4-Client verbindet sich mit dem OpenVPN IPv4 only Server auf dem vserver. Da die Ethernetschnittstelle des Tunnels ja von pfSense zuhause eine IPv4 u. IPv6 Adresse von DHCP bekommt, denk ich mir wäre es doch dann kein Problem das die IPv4 only Clienten auf die IPv4 Dienste in meinem Netzwerk zugreifen?

    Ich weiß das ginge mit feste-ip.net (also das Resultat das ich erreichen will, wie technisch gelöst ist keine Ahnung).

    Ich denke die lösen es genau so. Nur kostet das dann nicht 1€ im Monat sondern mehr + die Anschaffung derer FIP Box.

    Mit einfachen Portmapping von feste-ip.net + OpenVPN Server auf pfSense auf TCP only zu stellen klappt leider nicht.

    Laut OpenVPN Log bricht er immer am folgenden Punkt ab:

    ERROR: FreeBSD route add command failed: external program exited with error status: 1


  • Hallo @Krautsalatmission ,

    OpenVPN kann seit Version 2.4 DualStack. Ich sehe da also kein Problem, auf einem Virtuallen Server einen OpenVPN-Server einzurichten, der eine Brücke zwischen einer statischen IP und einem dynamischen Heimnetz herstellt. In deiner schematischen Darstellung müsstest du natürlich einen OpenVPN-Server und einen -Client auf dem Virtuallen Server installieren und das Routing zwischen den Tunnelnetzen sicherstellen. Die einfachere Methode wäre vermutlich, pfSense als Client auf den Virtuellen Server verbinden und am OpenVPN-Server die Inter-Client-Communication zu erlauben.

    Eine weitere Möglichkeit wäre, einen Site-to-Site-Tunnel zwischen pfSense und dem Virtuellen Server herzustellen und einzelne Ports oder eine zusätzliche IPv4 über den Tunnel an deine pfSense (und von dort aus ggf. weiter an deinen heimischen VPN-Server) zu routen. So könntest du deinen heimischen VPN-Server am IPv6-Provider-Anschluss auch für IPv4-Clients verfügbar machen.


  • Danke Libratix!

    Den letzten Absatz habe ich ehrlich gesagt gar nicht verstanden! :-)

    Erstere schon. Die pfSense möchte ich nicht als Client verbinden lassen, weil dann würde mein ausgehender Verkehr (von zu Hause) denk ich mal permanent da durch gehen oder?

    Dann miete ich mir mal so ein paar Cent vserver an. Wie ich auf Debian ein OpenVPN Server u. Client einrichte weiß ich.

    Nur sagtest du gerade, ich müsste das Routing zwischen den beiden Netzwerken herstellen.

    Kannst mir sagen wie das geht?

    Am besten melde ich mich wieder sobald den Server + die OpenVPN Sache eingerichtet habe.

    Danke schon mal!


  • Nein, der ausgehende Traffic von zu Hause muss nicht zwingend über den Tunnel. Über deine Routing-Regeln kannst du genau steuern, welcher Traffic den VPN-Tunnel nutzt und welcher das normale WAN. In diesem Fall sollte pfSense so konfiguriert werden, dass nur Traffic an das Tunnel-Netzwerk auch über den Tunnel geht. Zudem wäre das die einfachste Konfiguration, weil du nur 1 OpenVPN-Instanz auf dem virtuellen Server hast und sich die Clients und das Heimnetz das selbe Tunnelnetzwerk teilen.

    In deinem Layout brauchst du 2 OpenVPN-Instanzen auf dem virtuellen Server und somit auch 2 Tunnelnetzwerke. Je nach eingesetztem Betriebssystem musst du dann erstmal Routing aktivieren (in den meisten Linux-OSes net.ipv4.ip_forward=1 für IPv4 Tunnelnetze), eventuell benötigte statische Routen setzen (alle zu erreichbaren Systeme außerhalb der Tunnelnetzwerke) und sicherstellen, dass keine Firewall den Traffic blockiert.


  • Ah ok. Dann ist das defintiv die bessere Lösung.

    Der OpenVPN Server auf dem pfSense kann aber aktiv bleiben?

    Weil ich mich mit dem direkt verbinden könnte, an Orten wo ich IPv6 zur Verfügung hätte.

    Den "Proxy" brauch ich ja nur an Orten wo ich nur IPv4 habe.

    Ich richte gerade ein vserver u. OpenVPN ein.

    Und danach einfach pfSense als Client + anderer Client verbinden (und die inter-client-communication aktivieren) und es läuft? Das wäre ja sehr einfach :-)

  • LAYER 8 Moderator

    OK ich verstehe den Titel schon nicht, die Beschreibung wird bei mir nicht besser.

    Du willst einen vServer mieten und mit diesem eine v4 (und möglichst auch ne v6!). Und was dann? Was willst du wie erreichen und wohin? Das ist mir hierbei noch nicht wirklich klar?


  • Da mein Anschluß zu Hause nur IPv6 anbietet, können Clienten außerhalb sich nur mit dem VPN verbinden, wenn die ebenfalls IPv6 sprechen können.

    Das ist soweit auch nicht schlimm, da 99% ich mich nur an Orte befinde, wo IPv6 existiert.

    Jedoch kann es natürlich zu der Situation kommen, wo man an einem Anschluß sitzt, der nur IPv4 beherrscht (oder so konfiguriert wurde).

    Und schon kann ich mich dann nicht mehr mit mein VPN verbinden.

    Daher brauche ich einen "Proxy" bzw "Zwischenstation" der beides sprechen kann. IPv4 u. IPv6.

    Und dafür gibt es Anbieter wie feste-ip.net. Die einem ein angepasstes raspberry-pi (bzw die Software darauf) anbieten. Oder andere Lösungen.


  • @Krautsalatmission ,
    ja, im Grunde ist es so einfach! Wenn es nicht auf anhieb funktioniert, dann fällt das wohl unter Feintuning. Firewallports richtig setzen, ggf. MTUs anpassen und natürlich die für dieses Szenario richtige VPN-Server Konfiguration. Eine Google-Recherche zu site-to-site OpenVPN bringt da sicher ein paar nützliche Tips, da du ja zum Beispiel keine default Route pushen willst sondern nur bestimmte Netzbereiche.
    Und es können auch mehrere OpenVPN-Instanzen auf dem selben Gerät parallel betrieben werden. Bei Server-Instanzen muss man nur jeder Instanz einen eigenen Port zuweisen. Clients suchen sich in der Regel automatisch einen freien Port. Die Anzahl der Instanzen wird effektiv wohl nur durch die Hardware limitiert, da für jede Instanz durchaus etwas Rechenpower nötig ist.

    Ich habe meinen vServer so konfiguriert, dass er den Tunnel mit der pfSense aufbaut und seine zweite öffentliche IPv4 über den Tunnel an die pfSense weiterleitet. So habe ich eine feste öffentliche IPv4 auf meiner pfSense, die über den Tunnel mit dem Internet verbunden ist. Meine Clients nutzen dann diese IP, um sich direkt auf den VPN-Server auf der pfSense zu verbinden. (Als Hinweis, was sonst noch machbar wäre.)

  • LAYER 8 Moderator

    @Krautsalatmission said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:

    Da mein Anschluß zu Hause nur IPv6 anbietet, können Clienten außerhalb sich nur mit dem VPN verbinden, wenn die ebenfalls IPv6 sprechen können.

    Aye.

    Das ist soweit auch nicht schlimm, da 99% ich mich nur an Orte befinde, wo IPv6 existiert.

    Du Glücklicher ;)

    Jedoch kann es natürlich zu der Situation kommen, wo man an einem Anschluß sitzt, der nur IPv4 beherrscht (oder so konfiguriert wurde).
    Und schon kann ich mich dann nicht mehr mit mein VPN verbinden.
    Daher brauche ich einen "Proxy" bzw "Zwischenstation" der beides sprechen kann. IPv4 u. IPv6.

    Jep, verstanden. Ja ist problemlos machbar. Einfachste Variante:

    • Lass deinen vorhandenen udp6 OVPN Einwahlserver in Ruhe, der läuft ja gut.
    • Miete irgendwo eine günstige VM mit v4 und v6 und installiere OVPN
    • Konfiguriere dort einen OVPN Service mit OVPN Tunnel Site2Site Server auf IPv6.
    • Konfiguriere auf deiner pfSense eine OVPN Tunnel Site2Site Client mit IPv6. Da du nicht Server spielst, ist der Port hier egal.
    • Tunnel so konfigurieren, dass die Route für dein internes v4 Netz auf der VM erreichbar wird
    • Konfiguriere einen IPv4 Einwahlserver auf der VM und pushe hier dein internes v4 Netz zum einwählenden Client

    Das wären jetzt so die Steps die mir dazu einfallen. Alternativ könnte man auch überlegen, ob man via stunnel oder ähnliches nicht direkt bei Verbindungsaufbau zur VM via IPv4 z.B. tcp/443 nicht direkt über den Site2Site IP6 Tunnel zu deiner pfSense durchroutet und dort direkt zum OVPN Server durchtunneln aber egal wie, machbar ist es auf jeden Fall.

    @Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:

    Die Anzahl der Instanzen wird effektiv wohl nur durch die Hardware limitiert, da für jede Instanz durchaus etwas Rechenpower nötig ist.

    Rein technisch? Nein. Die Anzahl der Instanzen ist völlig nebensächlich, das wird leider immer wieder mit dem tatsächlich verschlüsselten Traffic verwechselt. Dieser - und nur dieser - ist tatsächlich CPU Last erzeugend. Ob da ein OVPN Service oder 50 davon auf Verbindungen warten - oder Leerlauf Verbindungen halten - ist völlig nebensächlich, das ist dann mehr IRQ, Netzwerk und RAM Frage wo das aufschlägt. Aber der tatsächlich laufende Traffic der verschlüsselt und entschlüsselt wird, das ist der springende Punkt. Da kann ein OVPN Server der mit 250mbps Daten hin und her schaufelt die Kiste genauso lahmlegen, wie ein OVPN Roadwarrior Server mit 100 Verbindungen, bei denen jeder für 1-2Mbps Daten überträgt. :)


  • Hallo Zusammen,

    ich wollte ein kleinen Zwischenstand abgeben.

    Momentan komme ich nicht weiter, weil ich noch auf die Antwort warte von Strato Support.

    Weil auf meinen bei denen angemieteter Vserver anscheinend nicht möglich ist OpenVPN unteranderem zu betreiben, weil iptables gänzlich fehlt und somit keine Routen und Regeln anlegen kann.

    Da Docker ebenfalls nicht nutzen kann, denke ich mal das dies ein schlecht konfigurierter Container ist.


  • Puh, Strato hatte ich schon lange nicht mehr, weil mich Preis/Leistung für Privatzwecke nicht überzeugt hat.

    Mir fallen da spontan 2 Möglichkeiten:

    • der vServer nutzt ein Linux-System, das gar kein iptables mehr zur Verfügung stellt sondern auf Alternativen setzt.
    • in der Konfiguration der Repositorys stehen derzeit (abgespeckte) Strato-Repos, die sich durch die offiziellen Repos austauschen lassen um so iptables nach zu installieren.

  • Das ist immer das erste was ich mit so einem Server mache :-)

    In dem Fall ist das anders, weil ich keine eigene Module laden kann usw. Daher wahrscheinlich eine OpenVZ/Container Lösung.

    Welchen Anbieter würdest du denn empfehlen? Vor über 10 Jahren war ich mal Kunde bei Netcup. Domain + Vserver.

    Sehe gerade, kosten die hälfte und dort steht sogar explizit das per KVM virtualisiert wird.

    https://www.netcup.eu/vserver/vps.php#v-server-details

    Habe gerade einen von Strato, für 5€ im Monat. Habe auch nur dort einen gemietet, weil ich dort bereits einige Domains habe.


  • Netcup wäre für private Zwecke auch meine Empfehlung gewesen. Die KVM-Virtualisierung macht richtig Spaß und die Ausfallzeiten sind sehr gering. Insbesondere für den Preis.


  • 1 Kern reicht denke ich mal für ein bzw zwei Clienten? Also wegen OpenVPN und der stattfindenen Verschlüsselung während der Datenverkehr fließt.

  • LAYER 8 Moderator

    Ich würde das mit der neuen vCloud von Hetzner mal probieren. Meine paar Instanzen dort sind zum einen super günstig und nach einem doofen Start mit einer davon auch voll Dual Stack ausstaffiert.

    Könnte da notfalls mal testhalber OVPN draufladen, aber soweit ich das sehe (ich habe da Ubuntu 18.04 LTS Instanzen laufen), sehen die ein sauberes eth0 mit IP4/IP6. Mein Fail2Ban mit IPtables/NFtables und Fail2ban läuft da auch fein drauf. Vermutlich Kubernete oder KVM sauber virtualisiert - hatte noch keine Schwierigkeiten damit. Diese Pseudo-Containerisierung von manchen "vServern" ist echt gruselig... und die knapp 3€/mtl. sind kein Problem für nen Test (weniger wenn man mit der Kiste nur nen Tag spielt).


  • @JeGr said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:

    Könnte da notfalls mal testhalber OVPN draufladen, aber soweit ich das sehe (ich habe da Ubuntu 18.04 LTS Instanzen laufen), sehen die ein sauberes eth0 mit IP4/IP6. Mein Fail2Ban mit IPtables/NFtables und Fail2ban läuft da auch fein drauf. Vermutlich Kubernete oder KVM sauber virtualisiert - hatte noch keine Schwierigkeiten damit. Diese Pseudo-Containerisierung von manchen "vServern" ist echt gruselig... und die knapp 3€/mtl. sind kein Problem für nen Test (weniger wenn man mit der Kiste nur nen Tag spielt).

    Danke für den Tipp!

    Bin nun bei Netcup. Und soweit läuft nun alles so wie ich es will. OpenVPN installiert und eingerichtet usw. Kann mich mit nem Smartphone oder Notebook zb aus dem Mobilnetz mit dem Server verbinden.

    Gerade kämpfe ich mich bei der Konfiguration von pfSense durch. Das will noch nicht wie ich will.

    Bin mal so faul, und kopiere ein Teil der Konversation die ich mit Libratix geführt habe bzw dem geschrieben habe:

    Alles ist erledigt. Also Domain ist umgezogen und funktioniert. Server mit OpenVPN mit client-to-client eingerichtet, und Verbindung zum OpenVPN Server funktioniert auch.
    
    Jetzt muss ich nur noch den PFsense Router zuhause so konfigurieren, das er sich mit dem OpenVPN Server verbindet, aber jeglichen Traffic weiterhin "durch meine Internetleitung feuert" und nicht durch den VPN. Außer natürlich das, was durch den VPN angefragt wird. Kannst du mich darin unterstützen?
    
    Gehe übrigens hier nach: https://gist.github.com/InQuize/59e7c458c510ae779743
    
    Und für die Konfiguration habe ich die exportierte ovpn Datei als Vorlage genommen:
    
    client
    dev tun
    proto udp
    remote 1.1.1.1 1111
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    remote-cert-tls server
    auth SHA512
    cipher AES-256-CBC
    ignore-unknown-option block-outside-dns
    block-outside-dns
    verb 3
    <ca>
    -----BEGIN CERTIFICATE-----
    ganz geheim 1
    -----END CERTIFICATE-----
    </ca>
    <cert>
    -----BEGIN CERTIFICATE-----
    ganz geheim 2
    -----END CERTIFICATE-----
    </cert>
    <key>
    -----BEGIN PRIVATE KEY-----
    ganz geheim 3
    -----END PRIVATE KEY-----
    </key>
    <tls-crypt>
    -----BEGIN OpenVPN Static key V1-----
    ganz geheim 4
    -----END OpenVPN Static key V1-----
    </tls-crypt>
    
    Leider verbindet sich die pfsense nicht. Verbose habe ich auf 4 stehen, und sehe kein Grund weswegen:
    
    https://pastebin.com/mkFRzYCF
    

    Edit: Sehe gerade das der pastebin aus irgendeinem Grund entfernt worden ist. Poste ich einfach mal direkt hier:

    Restart pause, 10 second(s)
    NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    Re-using SSL/TLS context
    Control Channel MTU parms [ L:1622 D:1140 EF:110 EB:0 ET:0 EL:3 ]
    Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
    Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
    Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
    TCP/UDP: Preserving recently used remote address: [AF_INET]1.1.1.1:1111
    Socket Buffers: R=[42080->42080] S=[57344->57344]
    UDPv4 link local (bound): [AF_INET]2.2.2.2:0
    UDPv4 link remote: [AF_INET]1.1.1.1:1111
    MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
    MANAGEMENT: CMD 'status 2'
    MANAGEMENT: CMD 'quit'
    MANAGEMENT: Client disconnected
    [UNDEF] Inactivity timeout (--ping-restart), restarting
    TCP/UDP: Closing socket
    SIGUSR1[soft,ping-restart] received, process restarting
    Restart pause, 20 second(s)
    
  • LAYER 8 Moderator

    In Kürze:

    • Shared Key Tunnel einrichten zwischen dem Server und der pfSense
    • bei pfSense als Client einrichten
    • In der Konfiguration kein Remote Netz bei Tunnelkonfiguration auf pfSense definieren -> damit dann kein default-route oder route push
    • auf pfSense sollte in Routing Table dann nur das Transfernetz auftauchen
    • auf OVPN Server Seite mit IPTables (oder Filter der Wahl) NAT aufsetzen so dass alles was über den Tunnel zur pfSense kommt mit der IP des OVPN Server maskiert wird -> somit finden die Pakete auch problemlos ihren Rückweg wieder
    • eingehend Firewall Regeln auf pfSense auf OpenVPN Interface nicht vergessen

  • Dem Log entnehme ich, dass er sich eigentlich verbindet, aber wegen Inactivity timeout die Verbindung wieder schließt, sprich: keine Pakete durch den Tunnel gehen.

    Auf anhieb kommen mir die Werte für link-mtu und tun-mtu recht hoch vor. Für gewöhnlich bewegen sich die Werte zwischen 1300 und 1400.

    Bei meinem pfSense Client habe ich "Peer to Peer (SSL/TLS)" Vorlage aus der Gui gewählt und im Grunde nur IP, Port, Zertifikate und Algorithmen passend zum Server eingetragen.

    In den custom options stehen dann noch:
    tun-mtu 1372
    mssfix 1332
    remote-cert-tls server

    Die Werte für MTU und MSS habe ich anhand der Ping-Methode "errechnet". Als Start kann man es mit mssfix 1300 mal ausprobieren, wenn die Verbindung dann klappt, hat man den Fehler schon gefunden und kann dann einen größeren Wert austeste.

  • LAYER 8 Moderator

    @Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:

    Bei meinem pfSense Client habe ich "Peer to Peer (SSL/TLS)" Vorlage aus der Gui gewählt und im Grunde nur IP, Port, Zertifikate und Algorithmen passend zum Server eingetragen.

    Nope. Einfach wie oben beschrieben einen Shared Key Tunnel nutzen. Einfachste Vorgehensweise. P2P TLS kann problematisch sein, weil es hier kein definierter Partner besteht, sondern es ggf. mehrere eingewählte Tunnelendpunkte geben kann. Daher ist bspw. auch bei Protokollen wie OSPF der P2P TLS Mode nicht möglich, sondern NUR der SharedKey Mode.

    An irgendwelchen MTUs einfach rumzudrehen ohne Not würde ich ebenfalls nicht. Wenn es nicht läuft, OK, andernfalls unnötig wenn alle Peers ordentlich routen. Kein Grund das auf irgendwelche 1300er Werte runterzudrücken wenn es nicht sein muss.

    Dem Log entnehme ich, dass er sich eigentlich verbindet, aber wegen Inactivity timeout die Verbindung wieder schließt, sprich: keine Pakete durch den Tunnel gehen.

    Keine Pakete durch den Tunnel sind kein Argument. OVPN im P2P Mode baut nicht einfach den Tunnel ab weil grade nichts durch läuft. Inactivity Timeout auf Client Seite wird getriggert, wenn die Gegenseite nicht (mehr) antwortet und damit angenommen wird, dass die Verbindung abgerissen ist.


  • Oh, sag das mal meinem OSPF, dass er mit P2P TLS nicht möglich ist. Der weiß das offenbar noch nicht.

    Und bei mir konnte ich die Inactivity Timeouts eben durch Anpassung der MTU an die realen Umstände beheben.


  • Ehm, ich entnehme eurer Konversation also jetzt das ich alles richtig gemacht habe und es richtig ist das es nicht läuft? 😂

  • LAYER 8 Moderator

    @Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:

    Oh, sag das mal meinem OSPF, dass er mit P2P TLS nicht möglich ist. Der weiß das offenbar noch nicht.

    Klar. Keine Ahnung was du noch eingestellt hast, dass es vielleicht geht, aber sobald man mehrere S2S Verbindungen bei P2PTLS hat, sieht der OSPF seine Gegenstellen nicht mehr. Mehrfach nachgestellt und mit Core Switchen und Routern als Gegenstellen schon gehabt. Gerade erst vor einem Monat. Ist BTW auch genau so in der Doku und im Troubleshooting Guide explizit erwähnt. Sollte es durch das neue FRR zufällig jetzt gehen würde ich mich trotzdem nicht drauf verlassen.

    Ehm, ich entnehme eurer Konversation also jetzt das ich alles richtig gemacht habe und es richtig ist das es nicht läuft? 😂

    Nein, inactivity timeout heißt eben dass er keine Kommunikation mehr bekommt. Hat aber nichts mit "da geht kein Paket mehr drüber" -> kein Traffic - zu tun, sondern dass nichts ankommt, was ankommen SOLL. Zudem hatte ich nicht gesagt, dass es nicht an der MTU liegt, sondern, dass man daran nicht rumfingert wenns keinen Grund gibt. Und normalerweise gibts gerade zu irgendwelchen Datacentern eher keinen Grund - weil da niemand hinter irgendwelchen Modems oder sonstigen Gerätekopplern sitzt, die die MTU verhunzen. Es kann auch an anderen Settings liegen. Muss man eben mal das Logging auf 3 oder 4 hochdrehen und genau mitlesen.

    Zudem sollte nach Verbindungsaufbau ja das VPN Gateway (die Gegenstelle) in pfSense auftauchen und somit angepingt werden. Es gibt also normalerweise gar nicht die Situation, dass kein Traffic läuft.


  • Das ist bereits Logging auf 4.

    Mehr kommt leider nicht.

    Sobald zu Hause bin, werde ich es noch höher einstellen. Vielleicht kommt dann mehr Infos.

  • LAYER 8 Moderator

    Nah, 4 ist eigentlich schon genug. Wäre aber sinnvoll ggf. Server und Client Logs aus dem gleichen Zeitraum ggü stellen zu können.