[openVPN, Raspbian] externer Zugriff funktioniert, lokal nicht

[Jokeboy]

Hallo alle zusammen!

Folgendes Problem:

Ich habe gestern meinen Raspberry Pi 3 B+ erhalten und lasse gerade Pi-Hole und openVPN darauf laufen. Im Prinzip läuft beides: wenn ich z.B. mit meinem Smartphone über den Provider mit openVPN zu meinem Pi zuhause verbinde, geht das Ratzfatz und Werbung ist so gut wie keine mehr Sichtbar. Da ich aber das openVPN als always-on laufen lassen will, muss es dann zuhause im LAN ja auch gehen (verbunden über WLAN).

Leider funktioniert das nicht so wie ich es will.

Ich habe mir den einfachen Weg gegönnt und erstelle die Keys mit openvpn-install (das CA und server nicht auf dem gleichen Rechner laufen soll ist jetzt mal dahingestellt ). Bei der openVPN Einrichtung habe ich für Remote mein DynDNS eingesetzt. Nur scheint hier das problem zu sein das lokal es nicht möglich ist den aufzulösen, weshalb ich hoffe das ihr eventuell eine Idee hat was jetzt hier nicht stimmt. (server.conf von opeVPN zeigt auch auf Server (DNS Pi-Hole) push "dhcp-option DNS 192.168.1.235")


OS: Raspbian Stretch Lite
DNS: wird der Server verwendet (Pi-Hole DNS)

Danke!

JB

 

[TechX]

Lokal wirst Du ja keine VPN-Verbindung aufbauen - auf welchen DNS-Server zeigt denn dein WLAN-Router?
Der müsste ebenfalls auf den PiHole zeigen.

 

[Jokeboy]

Lokal wirst Du ja keine VPN-Verbindung aufbauen - auf welchen DNS-Server zeigt denn dein WLAN-Router?
Der müsste ebenfalls auf den PiHole zeigen.

Der Router zeigt auch auf den Pi.

Bevor ich den Pi erhalten habe, habe ich schon mit PiHole und openVPN auf einem uralt Rechner probiert (mit Ubuntu 18.04 Server). Da ging lokal und remote VPN mittels Smartphone. Von den Einstellungen her sind aber beide gleich, das einzige was anders ist das der alte Rechner über WLAN lief und der Pi mit Kabel.

 

[TechX]

Der RaspPi hat jetzt haargenau die selbe IP, wie der alte Rechner oder musstest Du noch nachkonfigurieren?
Du benutzt daheim nacktes WLAN oder möchtest Du hier ebenfalls per VPN verbinden?
Evtl. eine Regel in der Firewall?

 

[Jokeboy]

Der alte Rechner hängt ja nicht mehr am Netz den Static Lease habe ich zudem von dem schon entfernt und dem Pi zugewiesen.

Ich benutzte daheim auch WLAN (nackt nicht, ist natürlich gesichert). Aber damit openVPN auf dem Smartphone durchgehend läuft, was ich möchte, sollte es daheim im WLAN als auch Remote über den Telefonprovider (was schon funktioniert) laufen.

FIrewall müsste passen, sonst würde ich von außerhalb auch nicht darauf zugreifen können.

Es sieht aber hier eindeutig nach einem DNS fehler aus:


Habe den Hostname auch schon unter /etc/hosts eingetragen, half aber nicht.

Edit:
Ist jetzt natürlich nicht unbedingt notwendig, wäre ein Nice-to-have Das Grundprinzip, von außen einen sicheren Tunnel zu hause aufbauen, läuft ja.

 

[TechX]

Aber damit openVPN auf dem Smartphone durchgehend läuft, was ich möchte, sollte es daheim im WLAN als auch Remote über den Telefonprovider (was schon funktioniert) laufen.

Das habe ich dich schon Eingangs gefragt - d.h. also, trotz WLAN-Verbindung daheim, würdest Du (unnötigerweise) über den VPN-Tunnel arbeiten. Da deine Verbindung aus dem zu konektierenden Subnet kommt, wird die Verbindung gar nicht erst geroutet u. somit der DNS nicht aufgelöst.

Wenn Du den VPN-Connector deaktivierst u. "normal" im WLAN agierst sollte es sofort funktionieren. Ich schätze, Du hast vorher in der alten Konfiguration im WLAN auch ohne openVPN konnektiert.

Wenn der VPN-Adapter permanent aktiviert sein soll, da könnte die einfachste Methode ein Gast-WLAN sein, mit anderer IP-Adresse.

 

[Raijin]

Ich verstehe nicht warum du lokal überhaupt VPN nutzen willst. Wie oben schon angedeutet, ist das vollkommen überflüssig. Eingangs hast du geschrieben, dass die Werbung dann weg ist. Das impliziert, dass es dir eigentlich um pihole geht. Lokal kannst du pihole aber auch ohne VPN nutzen. Der DHCP des Routers (oder des PI, wenn er auch DHCP macht) muss einfach die IP des PI als DNS ausgeben und schon profitiert man im eigenen WLAN von den Blocklisten von pihole - ganz ohne VPN.

Wenn du trotzdem aus unerfindlichen Gründen auch innerhalb deines Heimnetzwerks das VPN nutzen willst - das VPN, das dann 5m WLAN-Verbindung tunnelt - dann musst du dafür sorgen, dass der DNS im Heimnetzwerk deine DDNS-Domain lokal auflöst. Das kann zB ganz banal über einen hosts-Eintrag am DNS-Server passieren oder besser über das Interface des DNS als Ausnahme hinzufügen.

Es geht aber auch ganz ohne den DNS, wenn man sich 2 OpenVPN-Profile anlegt. Eines mit "remote ddns.bla" und eines mit "remote 192.168.1.234".

Wie auch immer, VPN innerhalb des eigenen Netzwerks ergibt nur sehr bedingt einen Sinn. Ein sinnvolles Beispiel wäre die explizite Verschlüsselung der Verbindung, wenn auch Fremde Zugang zum WLAN haben. Aber auch dann ist der Traffic ab dem PI Richtung Internet so (un)verschlüsselt wie zuvor...

 

[Reflexion]

Ich hoffe ich störe nicht, falls doch lösche ich meine Frage hier..^^ Lohnt sich der Kauf des Raspberry Pi 3 B+ verglichen mit dem Raspberry Pi 2 für die Verwendung von PiVPN/(OpenVPN)? Denn das Zugreifen außerhalb auf meine Kodi Bibliothek ist zwar möglich, aber teils derbe langsam da werden keine ~42MBits drüber laufen, deshalb überlege ich den neuen Pi zu holen, soweit ich weiß ist aber OpenVPN single Core-lastig, was gar nicht gut für so kleine SoC oder
ASRock J5005-ITX allinOne Platinen ist.. zugegriffen wird bislang auf mein /24 Subnetz, und darauf auf mein kleinen Backup Server G4560 mit Unraid. Ich hatte auch schon einmal überlegt dort OpenVPN auf eine VM oder Docker zu setzen, nur finde ich es doof die Kiste permanent wach zu halten nur um einen VPN Verbindung aufzubauen, nicht immer möchte man ja auf Medien zugreifen.. da wäre der Raspberry Pi 3 B+ deutlich effizienter... es wäre schön wenn ~42MBits Up mal genutzt werden könnten.

 

[error]

Moin,

ich bekomme auf mein Pi 3 maximal 10 Mbit/s mit OpenVpn drüber. Ggf. geht mehr wenn du noch bezüglich der Verschlüsselung und weiterem optimierst.
Eine Alternative kann WireGuard sein. Da gibt es auch Apps für.

gruß

 

[phillow]

Hi,

Ich habe hier das gleiche Szenario erfolgreich laufen.
PiVPN in Kombination mit Pihole.
Habe ich nach folgender Anleitung eingerichtet:
https://www.kuketz-blog.de/pivpn-raspberry-pi-mit-openvpn-raspberry-pi-teil3/

Läuft bestens. Alle Geräte im LAN oder WLAN laufen über Pihole und der externe Zugriff klappt perfekt mit PiVPN und das auch mit Pihole.

 

[Reflexion]

Danke euch, das es läuft, zumindest mit UDP /(Ich weiß leider nicht genau wie ich TCP/UDP zusammen getunnelt bekomme), ist klar, Anleitungen gibt es genug nur was den Durchsatz anbelangt werde ich nicht wirklich schlau draus, darum die Frage. Wie man WireGuard einrichtet ist mir noch nicht bekannt, soll aber weniger OH verursachen. Auf dem unRAID Server als Docker habe ich z.Z dann ZeroTier am laufen, läuft recht gut bekomme so 36MBits durch, nur ist das nix wenn man mit seinem smartphone bspw. sicher am Hotspot surfen möchte denn Anfragen werden nicht von der Heimnetz bezogen, Sprich, man hat bei myip.is weiterhin seine mobile ip.. nicht die öffentliche vom router@ home.

 

[error]

Danke euch, das es läuft, zumindest mit UDP /(Ich weiß leider nicht genau wie ich TCP/UDP zusammen getunnelt bekomme), ist klar, Anleitungen gibt es genug nur was den Durchsatz anbelangt werde ich nicht wirklich schlau draus, darum die Frage.

Öhm,
dein VPN tunnelt alles. Egal ob es TCP oder UDP ist. Wie gesagt ist der Durchsatz mit den Raspi auf ca. 10 Mbit/s beschränkt. Abhängig was sonst noch so am Laufen ist.

Wie man WireGuard einrichtet ist mir noch nicht bekannt, soll aber weniger OH verursachen.

Wenn ich davon ausgehe, dass du Raspian nutzt, dann musst du Wireguard dafür aus Git klonen, bauen und installieren. Es gibt noch kein paket für Raspian.

Auf dem unRAID Server als Docker habe ich z.Z dann ZeroTier am laufen, läuft recht gut bekomme so 36MBits durch, nur ist das nix wenn man mit seinem smartphone bspw. sicher am Hotspot surfen möchte denn Anfragen werden nicht von der Heimnetz bezogen, Sprich, man hat bei myip.is weiterhin seine mobile ip.. nicht die öffentliche vom router@ home.

Öhm,

mir ist für das Handy keine sinvolle Anwendung bekannt die mehr als 10 Mbit/s auf Dauer benötigt. Ich kann über OpenVPN am Handy in aller Ruhe HD streamen. Netflix und Amazon gehen auch noch, wenn sie keine volle HD-Auflösung hinbekommen. Das ist bei dem kleinen Bildschrim auch mMn nicht so wichtig.


Genrell solltest du bei VPN übers Handy keine Wunder erwarten. Es ist halt nur dazu da, dass du sicher surfen kannst..

gruß

 

[Reflexion]

Öhm,
dein VPN tunnelt alles. Egal ob es TCP oder UDP ist. Wie gesagt ist der Durchsatz mit den Raspi auf ca. 10 Mbit/s beschränkt. Abhängig was sonst noch so am Laufen ist.


Wenn ich davon ausgehe, dass du Raspian nutzt, dann musst du Wireguard dafür aus Git klonen, bauen und installieren. Es gibt noch kein paket für Raspian.


Öhm,

mir ist für das Handy keine sinvolle Anwendung bekannt die mehr als 10 Mbit/s auf Dauer benötigt. Ich kann über OpenVPN am Handy in aller Ruhe HD streamen. Netflix und Amazon gehen auch noch, wenn sie keine volle HD-Auflösung hinbekommen. Das ist bei dem kleinen Bildschrim auch mMn nicht so wichtig.


Genrell solltest du bei VPN übers Handy keine Wunder erwarten. Es ist halt nur dazu da, dass du sicher surfen kannst..

gruß

....ich meinte TCP/UDP über einen Tunnel. So dass ich beim Telekom Hotspot auf TCP auch kann, und ansonsten Unitymedia Hotspot zbs. UDP. Klar reichen 10Mbits fürs Googlen, aber schau Mal in 1080p Yt mir OpenVPN unterwegs, wirklich gut läuft das nicht, auch weil Yt weniger gut scalliert wie Netflix/Prime Video, 720p sind jetzt auf'n Tablet/Smartphone jetzt auch nicht so der Hit. Ich habe Mal meinen RPi2 ein bissl getestet, UDP; ~16Mbits gehen dadurch. Bin gespannt ob der Pi 3 B+ mehr packt, er hat AES in der HW, und eben 300Mbits LAN..

 

[Raijin]

ich meinte TCP/UDP über einen Tunnel

Hä? Irgendwie wird hier aneinander vorbeigeredet.

Ein VPN kann selbst entweder auf UDP oder auf TCP laufen. Das heißt, dass die VPN-Pakete mittels UDP bzw. TCP transportiert werden.

Anwendungen, die über das VPN kommunizieren, tun dies weiterhin mit ihrem eigenen Protokoll, sei es UDP oder eben TCP. Eine http(s)-Seite, die man aufruft, wird also nach wie vor über TCP transportiert, aber in ein VPN-Paket vergepackt.

Ein VPN, das selbst sowohl über TCP als auch über UDP kommuniziert gibt es nicht. Eine Anwendung kann sich nicht aussuchen, Pakete mal so und mal so zu schicken. Man kann jedoch zwei parallele VPN-Instanzen erstellen, die jeweils auf einem anderen Port bzw. Protokoll laufen.

 

[Reflexion]

...ich möchte gerne wahlweise unterwegs mich mit UDP oder TCP einloggen, nutzen, nur Zeit ist es leider so dass ich entweder die Freigabe für UDP oder TCP nutzen konnte. Ich kann aber leider keine 2 Freigaben [ UDP/TCP] an den RPi2 (PiVPN Server) weiterleiten, entweder ich setze port forwarding für TCP oder UDP. ..muss mit dazu ein paar skills anschaffen... und die Protokolls abändern.

 

[Raijin]

Ich kann aber leider keine 2 Freigaben [ UDP/TCP] an den RPi2 (PiVPN Server) weiterleiten

Natürlich kannst du das. OpenVPN muss allerdings in 2 Instanzen mit eigener Konfiguration laufen, eine zB auf TCP 53 und die andere auf UDP 53. Dazu müssen einfach im Verzeichnis \etc\openvpn zwei conf-Dateien liegen, zB server-tcp.conf und server-udp.conf. Darin sind dann natürlich jeweils die passenden Ports nebst Protokoll konfiguriert.
Beim Start des OpenVPN Service werden automatisch alle .confs in einer eigenen Instanz gestartet, seien es Server- oder Client-Konfigurationen.

 

[Datax]

Wenn du trotzdem aus unerfindlichen Gründen auch innerhalb deines Heimnetzwerks das VPN nutzen willst - das VPN, das dann 5m WLAN-Verbindung tunnelt - dann musst du dafür sorgen, dass der DNS im Heimnetzwerk deine DDNS-Domain lokal auflöst. Das kann zB ganz banal über einen hosts-Eintrag am DNS-Server passieren oder besser über das Interface des DNS als Ausnahme hinzufügen.

Woran liegt es eigentlich letztlich, dass die Nutzung des Pi-Hole aus dem LAN heraus nicht funktioniert,
wenn man die VPN-Verbindung zum DynDNS-Hostnamen aufbaut?

Der DynDNS-Hostname gibt ja in diesem Fall die öffentliche IP-Adresse des Routers zurück,
über den das LAN den Internetzugang bekommt.

Wenn die VPN-Verbindung zum DynDNS-Hostnamen hergestellt wird (was ja funktioniert),
was ist dann anders als wenn man die VPN-Verbindung zur lokalen IP-Adresse des Pi-Hole aufbaut?

Frage mich gerade, woran es also technisch liegt, dass es aus dem LAN heraus nicht funktioniert den Pi-Hole als DNS-Server zu nutzen, wenn man wie gesagt aus dem LAN heraus die VPN-Verbindung zum
DynDNS-Hostnamen aufbaut.

Entsteht dadurch ein Problem mit dem Routing!?

Würde mich über eine Erklärung sehr freuen.

Gruß, Datax

 

[error]

Woran liegt es eigentlich letztlich, dass die Nutzung des Pi-Hole aus dem LAN heraus nicht funktioniert,
wenn man die VPN-Verbindung zum DynDNS-Hostnamen aufbaut?

[...]
Würde mich über eine Erklärung sehr freuen.

Gruß, Datax

Moin,

die Daten wandern in diesem Fall nicht über das externe Interfaces des Routers sondern bleiben "intern". Kommt von Intern, will aber zum externen Interface des Routers, also zum Router. Der Router erkennt dass er selbst das Ziel ist. Dadurch greifen auch nicht die Forwardings am Router. Und ohne das Forwarding kommt das Paket nicht zum VPN-Server.
Die Krux hier ist, dass die Forwardings/Regeln, etc. nur angewendet werden, wenn sie explizit über das externe Interface kommen. Wenn es von Intern kommt, dann klappt das nicht.

gruß

 

[Raijin]

Wenn du aus dem lokalen Netzwerk heraus die öffentliche IP des Routers ansteuerst, merkt der Router das quasi im letzten Moment, kurz bevor er den Traffic an das Provider-Gateway übergibt. Wenn er nun eben diese Verbindung quasi umkehrt, nennt sich das NAT loopback bzw NAT hairpin. Der Router muss diese Funktion explizit unterstützten und evtl. muss man sie in der GUI auch erstmal einschalten.

Das Problem dabei sind die ersten 3 Buchstaben: NAT. Der Router dreht die Verbindung nämlich wirklich im letzten Moment, die Pakete haben das lokale Netzwerk also schon verlassen, sind aber noch im Router am WAN-Port. Macht der Traffic nu eine 180° Wende, muss er auch durch die komplette NAT-Pipeline, inkl. Portweiterleitungen. Das merkt man zB dann, wenn man lokale Dienste über DDNS nutzen möchte, die man nicht von außen weiterleitet oder wenn man diese Portweiterleitung beispielsweise explizit auf eine Quell-IP (zB Firma) einschränkt.

Hat man NAT loopback/hairpin aktiviert und dafür gesorgt, dass alle nötigen Portweiterleitungen vorhanden sind, kommt aber das nächste Problem: NAT-Durchsatz des Routers. Im lokalen Netzwerk läuft über die Kabel 1 Gbit/s. Zwischen WAN und LAN sitzt aber das NAT und die Firewall, die je nach Router eben nicht die vollen 1 Gbit/s leisten können. Ist der Router beispielsweise vom Hersteller nur mit 100 Mbit/ WAN spezifiziert, schneidet man sich selbst beide Arme und ein Bein ab obwohl man ja gefühlt nur innerhalb des LANs bleibt.

So, nu hat man einen Router, der am WAN auch 1 Gbit/s schafft, super! Oder nicht?
Nein. Hängen Server und Client am aaaaaaaaanderen Ende des Netzwerks gemeinsam an einem Switch, geht die Verbindung immer über den Router. Also einmal queeeer von Client zum Router und dann den gaaaanzen Weg wieder zurück zum Server - die Antwort nimmt natürlich den umgekehrten Weg.

Zum Vergleich: Wenn man am Client die lokale LAN-IP des Server eingibt, geht der Traffic direkt über den gemeinsamen Switch. Der Router bekommt davon dann gar nix mit.

Ergänzung (26. Dezember 2018)

Der Vollständigkeit halber : Unterstützt der Router kein NAT loopback/hairpin - wie zB die Speedports - oder es ist abgeschaltet, dann macht der Router schlichtweg nichts, wenn seine WAN-IP vom LAN aus aufgerufen wird.

Alles in allem ist NAT loopback eher eine Notlösung. Einfacher und schneller geht's mit einem lokalem DNS-Eintrag, der für blabla.ddns eben nicht die öffentliche IP des Routers ausspuckt, sondern die lokale IP des Servers. Bei Fritzboxxen und evtl auch einigen anderen Routern wird dies aber durch einen "DNS-Rebind-Schutz" verhindert und man muss explizit eine Ausnahme für die DDNS Domain eintragen. Vermeintlich öffentliche Domains, die auf lokale IPs verweisen, könnten nämlich auch von Schadsoftware stammen.

 

[Datax]

Wenn du aus dem lokalen Netzwerk heraus die öffentliche IP des Routers ansteuerst, merkt der Router das quasi im letzten Moment, kurz bevor er den Traffic an das Provider-Gateway übergibt. Wenn er nun eben diese Verbindung quasi umkehrt, nennt sich das NAT loopback bzw NAT hairpin. Der Router muss diese Funktion explizit unterstützten und evtl. muss man sie in der GUI auch erstmal einschalten.

Das Problem dabei sind die ersten 3 Buchstaben: NAT. Der Router dreht die Verbindung nämlich wirklich im letzten Moment, die Pakete haben das lokale Netzwerk also schon verlassen, sind aber noch im Router am WAN-Port. Macht der Traffic nu eine 180° Wende, muss er auch durch die komplette NAT-Pipeline, inkl. Portweiterleitungen. Das merkt man zB dann, wenn man lokale Dienste über DDNS nutzen möchte, die man nicht von außen weiterleitet oder wenn man diese Portweiterleitung beispielsweise explizit auf eine Quell-IP (zB Firma) einschränkt.

Hat man NAT loopback/hairpin aktiviert und dafür gesorgt, dass alle nötigen Portweiterleitungen vorhanden sind, kommt aber das nächste Problem: NAT-Durchsatz des Routers. Im lokalen Netzwerk läuft über die Kabel 1 Gbit/s. Zwischen WAN und LAN sitzt aber das NAT und die Firewall, die je nach Router eben nicht die vollen 1 Gbit/s leisten können. Ist der Router beispielsweise vom Hersteller nur mit 100 Mbit/ WAN spezifiziert, schneidet man sich selbst beide Arme und ein Bein ab obwohl man ja gefühlt nur innerhalb des LANs bleibt.

So, nu hat man einen Router, der am WAN auch 1 Gbit/s schafft, super! Oder nicht?
Nein. Hängen Server und Client am aaaaaaaaanderen Ende des Netzwerks gemeinsam an einem Switch, geht die Verbindung immer über den Router. Also einmal queeeer von Client zum Router und dann den gaaaanzen Weg wieder zurück zum Server - die Antwort nimmt natürlich den umgekehrten Weg.

Zum Vergleich: Wenn man am Client die lokale LAN-IP des Server eingibt, geht der Traffic direkt über den gemeinsamen Switch. Der Router bekommt davon dann gar nix mit.

Ergänzung (26. Dezember 2018)

Der Vollständigkeit halber : Unterstützt der Router kein NAT loopback/hairpin - wie zB die Speedports - oder es ist abgeschaltet, dann macht der Router schlichtweg nichts, wenn seine WAN-IP vom LAN aus aufgerufen wird.

Alles in allem ist NAT loopback eher eine Notlösung. Einfacher und schneller geht's mit einem lokalem DNS-Eintrag, der für blabla.ddns eben nicht die öffentliche IP des Routers ausspuckt, sondern die lokale IP des Servers. Bei Fritzboxxen und evtl auch einigen anderen Routern wird dies aber durch einen "DNS-Rebind-Schutz" verhindert und man muss explizit eine Ausnahme für die DDNS Domain eintragen. Vermeintlich öffentliche Domains, die auf lokale IPs verweisen, könnten nämlich auch von Schadsoftware stammen.

Ja, okay.

Sowas in der Richtung hatte ich schon vermutet,
wusste aber nicht, dass das Kind auch einen Namen hat (NAT-loopback, also eine spezielle NAT-Funktion von Routern).

Klar, wenn der betreffende Router diese Funktion nicht unterstützt,
dann muss ich per DNS auf die lokale IP-Adresse auflösen können (z.B. durch eine DNS-Ausnahme gelöst wie von dir beschrieben oder direkt durchs Betriebssystem mit Hilfe eines Eintrages in der hosts-Datei).

Der "DNS-Rebind-Schutz" der FritzBox(en) ist mir bekannt, welcher sicherheitstechnisch auch echt vorteilhaft ist (Schutz vor DNS-Rebind-Attacken halt ^^).

Bei Bedarf kann man ja wie du ja auch bereits beschrieben hast Ausnahmen wie beispielsweise für die interne Domäne einrichten.

Ist natürlich auch echter Blödsinn aus dem LAN heraus über die WAN-Schnittstelle des Routers hindurch eine Verbindung zu Systemen im LAN aufzubauen. Von hinten durch die Brust ins Auge mal von dem von dir angesprochenen Problem mit der Übertragungsrate (da WAN-Port in vielen Fällen kein GBit/s) mal abgesehen xD.

Das ist so wie wenn ich in ein Mikrofon rufe, das Audiosignal dann per Kabelverbindung übertragen und dann über einen Lautsprecher ausgegeben wird, der hinter der Person steht, mit der ich reden möchte, welche aber direkt vor mir steht .

Für Testzwecke, um zum Beispiel zu testen,
ob eine Portweiterleitung (DNAT-Regel) funktioniert finde ich diese NAT-loopback-Funktion wohl ganz sinnvoll.

Aber ansonsten sollte man doch besser eine direkte Verbindung zum Ziel-System aufbauen,
wenn es sowieso im LAN "hängt".

Danke für deine Erläuterung, Raijin.

Gruß, Datax