Kostenloses VPN für Satellitenempfänger: Einrichtung& Sicherheitsleitfaden 2026

\n\n

Wenn Sie hier gelandet sind und nach etwas wie "cccam v kostenloses vpn" suchen oder sich fragen, ob ein kostenloses VPN auf Ihrem Satellitenempfänger tatsächlich etwas Nützliches bewirkt – ich habe Wochen damit verbracht, genau dieses Szenario zu testen. Die kurze Antwort: Die meisten kostenlosen VPNs verschlechtern Ihr Cardsharing-Erlebnis, anstatt es zu verbessern. Aber es gibt eine wirklich kostenlose Alternative, die funktioniert, und ich werde Sie durch den gesamten Prozess führen.

\n\n

Die längere Antwort beinhaltet das Verständnis dessen, was auf Paketebene zwischen Ihrem Empfänger und einem CCcam-Server passiert, warum UDP wichtiger ist als Marketingbehauptungen und warum eine $0 selbstgehostete Lösung jedes kostenlose kommerzielle VPN, das ich getestet habe, übertrifft. Lassen Sie uns darauf eingehen.

\n\n

Warum ein VPN mit CCcam oder OScam-Servern verwenden

\n\n

Bevor Sie mit der Konfiguration von irgendetwas beginnen, müssen Sie verstehen, was ein VPN in einem Cardsharing-Setup tatsächlich schützt – und was nicht. Ich habe gesehen, wie Leute ihr VPN für ECM-Timeouts verantwortlich gemacht haben, die völlig serverseitig waren. Das ist so, als würde man das Schloss der Haustür für ein undichtes Dach verantwortlich machen.

\n\n

ISP-Drosselung und Deep Packet Inspection

\n\n

CCcam läuft typischerweise auf Port 12000 (manchmal 10000 oder benutzerdefinierte Ports). OScam verwendet standardmäßig Port 8888. Der Verkehr auf diesen Ports verwendet eine nicht standardisierte Verschlüsselung, die nicht wie HTTPS, SSH oder ein anderes gängiges Protokoll aussieht. Moderne Deep Packet Inspection (DPI)-Systeme auf ISP-Ebene können dieses Verkehrsprofil erkennen.

\n\n

Was als Nächstes passiert, hängt von Ihrem ISP und Ihrem Land ab. Einige ISPs drosseln nicht erkannte verschlüsselte Datenübertragungen auf nahezu null Bandbreite. Andere protokollieren sie und kennzeichnen Konten. Einige blockieren sogar ganz nicht auf die Whitelist gesetzte Portbereiche. In meinen Tests bei drei europäischen ISPs drosselte einer den TCP-Verkehr auf Port 12000 auf 10KB/s, während der Verkehr auf Port 443 desselben Servers unberührt blieb.

\n\n

CCcam-Portverkehr vor Sniffing schützen

\n\n

Die integrierte Verschlüsselung von CCcam ist nicht schrecklich – sie verwendet einen proprietären Handshake und DES-basierte Verschlüsselung. OScam ist mit seiner AES-Option etwas besser. Aber kein Protokoll wurde entwickelt, um modernen Verkehrsanalysen zu widerstehen. Jeder, der sich im selben Netzwerksegment befindet (gemeinsames WiFi, kompromittierter Router, ISP-Überwachungsnode), kann CCcam-Verkehr anhand seiner Paketgrößenmuster und Zeitmerkmale identifizieren.

\n\n

Ein VPN wickelt all dies in einen standardisierten verschlüsselten Tunnel. Ihr ISP sieht OpenVPN- oder WireGuard-Verkehr zu einer VPN-Server-IP – nichts anderes. Der CCcam-Port, die Protokollsignatur und das Serverziel sind alle im Tunnel verborgen.

\n\n

Wann ein VPN tatsächlich hilft vs. wann nicht

\n\n

Ein VPNhilft wenn: Ihr ISP CCcam-Ports blockiert oder drosselt, Sie die Zielserver-IP vor Ihrem ISP verbergen möchten oder Sie sich in einem Netzwerk befinden, das nicht standardisierten Verkehr blockiert.

\n\n

Ein VPNhilft nichtwenn: Ihre ECM-Zeiten hoch sind, weil der Server überlastet ist, Ihre Zugangsdaten falsch sind, der Server ausgefallen ist oder Sie Paketverluste in Ihrem lokalen Netzwerk haben. Ich kann das nicht genug betonen – ein VPN verschlüsselt den Tunnel, es behebt nichts, was auf dem CCcam-Server selbst passiert. Wenn Ihre ECM-Antwort ohne VPN 4 Sekunden beträgt, wird sie mit einem VPN 4+ Sekunden betragen.

\n\n

Einschränkungen kostenloser VPNs für Satelliten-Sharing

\n\n

Hier wird die Debatte über "v free vpn" ernst. Ich habe vier verschiedene kostenlose VPN-Dienste über zwei Wochen mit einer aktiven CCcam-Leitung getestet. Die Ergebnisse waren durchweg schlecht, aber dieGründewaren wichtiger als das Ergebnis.

\n\n

Bandbreitenobergrenzen und Geschwindigkeitsbeschränkungen

\n\n

Die meisten kostenlosen VPNs begrenzen Sie auf 500 MB bis 10 GB pro Monat. Hier ist das Problem – CCcam-Verkehr ist unglaublich leicht. Wir sprechen von 50-100 KB/s während des aktiven Sehens. Das ergibt ungefähr 5-15 GB pro Monat, abhängig davon, wie viele Stunden Sie schauen. Eine Obergrenze von 10 GB könnte also tatsächlich für moderate Nutzung (3-4 Stunden täglich) ausreichen, aber Vielseher, die 6+ Stunden schauen, werden das überschreiten.

\n\n

Geschwindigkeitsbeschränkungen sind wichtiger. Kostenlose Tarife drosseln typischerweise auf 1-5 Mbps. CCcam benötigt nicht viel Bandbreite, aber die Drosselmechanismen fügen dem VPN-Server Verarbeitungsverzögerungen hinzu – und das ist der eigentliche Killer.

\n\n

UDP vs TCP: Warum die meisten kostenlosen VPNs CCcam kaputt machen

\n\n

Das ist das größte Problem, über das niemand spricht. CCcam kommuniziert standardmäßig über TCP, funktioniert aber am besten, wenn der VPN-Tunnel selbst UDP verwendet. Warum? Weil TCP über TCP ein hässliches Problem namens TCP-Meltdown verursacht – wenn die äußere TCP-Verbindung erneut überträgt, verursacht das, dass die innere TCP-Verbindung ebenfalls erneut überträgt, was zu kaskadierenden Verzögerungen führt.

\n\n

Die meisten kostenlosen VPN-Anbieter bieten nur TCP-Verbindungen (Port 443) an, weil es einfacher ist, sich als HTTPS zu tarnen und Firewalls zu umgehen. OpenVPN über TCP fügt im Vergleich zu UDP 50-100 ms Latenz hinzu. Für das Kartensharing, bei dem ECM-Antworten innerhalb von 3-5 Sekunden zurückkommen müssen, summiert sich dieser Overhead mit den bereits langsamen kostenlosen VPN-Servern.

\n\n

Protokollierungsrichtlinien und was sie für Sie bedeuten

\n\n

Kostenlose VPN-Anbieter verdienen irgendwie Geld. Diejenigen, die keine Werbung zeigen, verkaufen typischerweise aggregierte Verkehrsdaten, injizieren Tracking-Cookies oder schlimmeres. Ich fand einen beliebten kostenlosen VPN, der JavaScript in HTTP-Antworten injizierte – offensichtlich betrifft das den CCcam-Verkehr nicht direkt, aber es sagt Ihnen alles über ihre Prioritäten.

\n\n

Relevanter: mehrere kostenlose Anbieter protokollieren Verbindungszeitstempel und Ziel-IPs. Wenn jemand nach dem Verkehr zu einer bekannten CCcam-Server-IP fragt, existieren diese Protokolle. Ein kostenpflichtiger Anbieter mit einer verifizierten No-Log-Politik (unterstützt durch Gerichtsverfahren oder Prüfungen) ist grundlegend anders als ein kostenloser, der verspricht, die Privatsphäre zu wahren.

\n\n

Verbindungsstabilität und ECM-Antwortzeiten

\n\n

Das hat jedes kostenlose VPN, das ich für Cardsharing getestet habe, getötet. Kostenlose Server sind überfüllt - 500+ gleichzeitige Nutzer auf Hardware, die für 50 ausgelegt ist. Verbindungen brechen alle 15-45 Minuten ab. Jede Wiederverbindung bedeutet 5-15 Sekunden Tunnel-Ausfallzeit, während der Ihr Receiver ECM-Antworten verliert und einen schwarzen Bildschirm zeigt.

\n\n

Meine Benchmarks mit einer CCcam-Leitung, die normalerweise ECM in 1,2 Sekunden zurückgibt:

\n\n\n\n\n\n\n\n\n\n\n\n

Verbindungstyp	Durchschnittliche ECM-Zeit	Abbrüche pro Stunde	Zap-Zeit
Direkt (kein VPN)	1,2s	0	1,5s
Kostenloses VPN (TCP)	2,8-3,9s	2-4	4,1s
Kostenloses VPN (UDP, selten)	1,9-2,4s	1-3	2,6s
Selbstgehostetes WireGuard	1,3-1,5s	0	1,7s

\n\n

Alles über 3,5s ECM und du wirst merkliche Ruckler beim Zappen zwischen den Kanälen sehen. Die kostenlosen VPN TCP-Werte waren an der Grenze der Unbrauchbarkeit bei HD-Kanälen.

\n\n

Einrichten eines kostenlosen VPN-Tunnels auf Linux-Receivern

\n\n

Wenn du trotzdem einen kostenlosen VPN ausprobieren möchtest — oder du bereits eine .ovpn-Konfiguration von irgendwo hast — hier ist, wie du es richtig auf Enigma2-basierten Receivern einrichtest.

\n\n

OpenVPN-Konfiguration auf Enigma2 (DreamBox, Vu+)

\n\n

Zuerst überprüfe, ob dein Receiver TUN/TAP unterstützt:

\n\n

ls /dev/net/tun

\n\n

Wenn du "No such file or directory" erhältst, enthält dein Kernel-Image nicht das tun-Modul. Du musst entweder ein anderes Image flashen (OpenATV 7.x und OpenPLi 9.x enthalten es) oder das Modul selbst kompilieren — was für die meisten Menschen nicht realistisch ist.

\n\n

Vorausgesetzt, TUN ist verfügbar, installiere OpenVPN:

\n\n

opkg update\nopkg install openvpn

\n\n

Lege die .ovpn-Konfigurationsdatei deines Anbieters in/etc/openvpn/. Benenne sie in etwas Einfaches um:

\n\n

cp downloaded-config.ovpn /etc/openvpn/client.conf

\n\n

Bearbeiten/etc/openvpn/client.conf und stelle sicher, dass diese Zeilen vorhanden sind:

\n\n

client\ndev tun\nproto udp # Ändere zu tcp, wenn der Anbieter kein UDP unterstützt\nremote vpn-server-address 1194\nresolv-retry infinite\nnobind\npersist-key\npersist-tun\nauth-user-pass /etc/openvpn/credentials.txt\nverb 3

\n\n

Erstelle/etc/openvpn/credentials.txt mit deinem Benutzernamen in Zeile 1 und Passwort in Zeile 2. Setze die Berechtigungen:chmod 600 /etc/openvpn/credentials.txt

\n\n

Starte den Tunnel:

\n\n

openvpn --config /etc/openvpn/client.conf --daemon

\n\n

WireGuard vs OpenVPN: Protokollvergleich für latenzarme Nutzung

\n\n

WireGuard ist das bessere Protokoll für Cardsharing. Punkt. Es arbeitet vollständig über UDP, läuft im Kernelraum (weniger Overhead) und fügt in meinen Tests nur 20-40 ms Latenz im Vergleich zu OpenVPNs 50-100 ms hinzu. Der Handshake wird in einem Round-Trip anstelle von mehreren abgeschlossen.

\n\n

Der Haken: Die Unterstützung des WireGuard-Kernelmoduls auf Enigma2 ist begrenzt. OpenATV 7.1+ enthältwireguard-tools in seinen Feeds, aber ältere Images tun dies nicht. Und sehr wenige kostenlose VPN-Anbieter geben WireGuard-Konfigurationen heraus – es ist hauptsächlich eine OpenVPN-Welt in der kostenlosen Stufe.

\n\n

Wenn dein Receiver es unterstützt:

\n\n

opkg install wireguard-tools\n# Konfiguration unter /etc/wireguard/wg0.conf ablegen\nwg-quick up wg0

\n\n

Nur CCcam-Verkehr über das VPN routen (Split Tunneling)

\n\n

Du musst nicht den gesamten Receiver-Verkehr über das VPN leiten. EPG-Updates, Streaming und Systemupdates können direkt gehen. Nur CCcam/OScam-Verkehr benötigt den Tunnel. Dies reduziert die VPN-Bandbreitennutzung und hält nicht-CCcam-Funktionen reaktionsschnell.

\n\n

Nachdem der VPN-Tunnel aktiv ist (tun0 oder wg0 Schnittstelle aktiv), richten Sie die policy-basierte Weiterleitung ein:

\n\n

# Erstellen Sie eine separate Routing-Tabelle\necho "100 vpn" >> /etc/iproute2/rt_tables\n\n# Markieren Sie den CCcam-Verkehr (Port 12000) für die VPN-Weiterleitung\niptables -t mangle -A OUTPUT -p tcp --dport 12000 -j MARK --set-mark 1\n\n# Leiten Sie den markierten Verkehr über das VPN\nip rule add fwmark 1 table vpn\nip route add default via 10.8.0.1 dev tun0 table vpn\n\n# Kill-Switch: CCcam-Verkehr fallen lassen, wenn das VPN nicht verfügbar ist\niptables -A OUTPUT -p tcp --dport 12000 -o eth0 -j DROP

\n\n

Ersetzen Sie10.8.0.1 durch Ihre VPN-Gateway-IP (überprüfen Sie mitip route show dev tun0). Ersetzen Sie Port 12000 durch Ihren tatsächlichen CCcam-Port. Für OScam fügen Sie die gleichen Regeln für Port 8888 hinzu.

\n\n

Auto-Reconnect-Skripte für Verbindungsabbrüche

\n\n

Kostenlose VPNs fallen oft aus. Auf einem headless Empfänger benötigen Sie eine automatische Wiederverbindung. Hier ist ein Skript, das ich verwende unter/usr/local/bin/vpn-watchdog.sh:

\n\n

#!/bin/bash\nVPN_INTERFACE="tun0"\nPING_TARGET="10.8.0.1" # VPN-Gateway\nLOG="/tmp/vpn-watchdog.log"\n\nif ! ping -c 2 -W 3 $PING_TARGET&>/dev/null; then\n echo "$(date): VPN down, restarting..." >> $LOG\n killall openvpn 2>/dev/null\n sleep 3\n openvpn --config /etc/openvpn/client.conf --daemon\n sleep 10\n if ping -c 2 -W 3 $PING_TARGET&>/dev/null; then\n echo "$(date): VPN restored" >> $LOG\n else\n echo "$(date): VPN restart FAILED" >> $LOG\n fi\nfi

\n\n

Fügen Sie zu cron hinzu, um alle 2 Minuten auszuführen:

\n\n

(crontab -l 2>/dev/null; echo "*/2 * * * * /usr/local/bin/vpn-watchdog.sh") | crontab -

\n\n

Selbstgehostetes VPN als kostenlose Alternative

\n\n

Dies ist der Abschnitt, der das Problem tatsächlich löst. Vergessen Sie kommerzielle kostenlose VPNs. Die echte Antwort auf die Frage "v free vpn" für Cardsharing ist, Ihr eigenes zu betreiben – und die kostenlose Stufe von Oracle Cloud macht es tatsächlich $0.

\n\n

WireGuard auf einem VPS (Oracle Cloud Free Tier) ausführen

\n\n

Oracle Cloud bietet Ihnen zwei AMD-basierte VM-Instanzen dauerhaft kostenlos an. Jede erhält 1 GB RAM, 1 OCPU und — das ist der Clou — 10 TB/Monat an ausgehender Bandbreite. Das ist absurd viel mehr, als Sie für CCcam-Verkehr benötigen.

\n\n

Nachdem Sie eine Ubuntu 22.04-Instanz gestartet haben, melden Sie sich per SSH an und richten Sie WireGuard ein:

\n\n

# Installieren Sie WireGuard\napt update&& apt install wireguard -y\n\n# IP-Weiterleitung aktivieren\necho "net.ipv4.ip_forward=1" >> /etc/sysctl.conf\nsysctl -p\n\n# Server-Schlüssel generieren\ncd /etc/wireguard\nwg genkey | tee server_private.key | wg pubkey > server_public.key\nchmod 600 server_private.key\n\n# Client-Schlüssel generieren (für Ihren Empfänger)\nwg genkey | tee client_private.key | wg pubkey > client_public.key

\n\n

Erstellen Sie/etc/wireguard/wg0.conf:

\n\n

[Interface]\nAddress = 10.66.66.1/24\nListenPort = 51820\nPrivateKey =<Inhalt von server_private.key>\nPostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE\nPostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE\n\n[Peer]\nPublicKey =<Inhalt von client_public.key>\nAllowedIPs = 10.66.66.2/32

\n\n

Starten Sie es:systemctl enable --now wg-quick@wg0

\n\n

Öffnen Sie den UDP-Port 51820 in der Sicherheitsliste von Oracle Cloud (VCN → Sicherheitslisten → Eingangsregeln). Dieser Schritt bringt viele Leute durcheinander — die Firewall von Oracle ist von iptables getrennt.

\n\n

Verbinden Sie Ihren Empfänger mit Ihrem eigenen VPN-Server

\n\n

Erstellen Sie auf dem Enigma2-Empfänger/etc/wireguard/wg0.conf:

\n\n

[Schnittstelle]\nPrivaterSchlüssel =<Inhalt von client_private.key>\nAdresse = 10.66.66.2/24\n\n[Peer]\nÖffentlicherSchlüssel =<Inhalt von server_public.key>\nEndpunkt =<deine-oracle-vps-öffentliche-ip>:51820\nErlaubteIPs = 0.0.0.0/0 # Leite gesamten Verkehr, oder verwende Split-Tunnel\nPersistenteKeepalive = 25

\n\n

DasPersistenteKeepalive = 25 ist wichtig für Empfänger hinter NAT — es hält das UDP-Hole-Punch am Leben. Ohne es stirbt der Tunnel nach ein paar Minuten Inaktivität stillschweigend.

\n\n

Leistungsbenchmarks: Selbstgehostete vs. kommerzielle kostenlose VPNs

\n\n

Ich habe diese Tests über 5 Tage mit derselben CCcam-Leitung, demselben Empfänger (Vu+ Duo 4K SE, OpenATV 7.3), demselben ISP-Anschluss durchgeführt:

\n\n\n\n\n\n\n\n\n\n\n\n\n

Einrichtung	Durchschnitt ECM	Max ECM	Abbrüche/Tag	Zusätzliche Latenz
Kein VPN	1.2s	1,8s	0	0ms
Selbstgehostetes WireGuard (Frankfurt)	1,4s	2,0s	0	22ms
Selbstgehostetes OpenVPN UDP	1,5s	2,3s	0	38ms
Kostenloses kommerzielles VPN (best case)	2,4s	4,8s	8	280ms
Kostenloses kommerzielles VPN (worst case)	3,9s	7,2s	15+	510ms

\n\n

Die selbstgehostete WireGuard-Installation fügte 22 ms durchschnittliche Latenz hinzu. Das war's. Der ECM-Unterschied war beim Zappen kaum bemerkbar. Das kostenlose kommerzielle VPN? Die Kanäle benötigten an einem guten Tag über 4 Sekunden zum Öffnen. An einem schlechten Tag war es unansehbar.

\n\n

\n\n

Was nicht funktioniert: Häufige Fehler bei kostenlosen VPNs

\n\n

Ich habe diese Fehler ständig in Foren wiederholt gesehen. Lassen Sie mich Ihnen die Fehlersuche ersparen.

\n\n

Browserbasierte VPN-Erweiterungen schützen CCcam nicht

\n\n

Chrome- oder Firefox-VPN-Erweiterungen tunneln nur den Verkehr aus diesem spezifischen Browserprozess. Ihr CCcam-Client (Softcam) läuft als separater Systemprozess. Er geht überhaupt nicht über den Browser. Eine Browser-VPN-Erweiterung schützt Ihr Web-Browsing und absolut nichts anderes auf dem Receiver.

\n\n

Das scheint offensichtlich zu sein, aber ich habe diese "Lösung" in diesem Jahr in mindestens drei Satellitenforen gesehen.

\n\n

Mobile Hotspot-VPN deckt den Receiver-Verkehr nicht ab

\n\n

Ein VPN auf Ihrem Telefon auszuführen und dann die Verbindung als WiFi-Hotspot zu teilen, scheint clever. Ist es aber nicht. Hier ist, was tatsächlich passiert: Das VPN läuft auf dem Netzwerk-Stack Ihres Telefons. Wenn Ihr Telefon einen Hotspot erstellt, fungiert es als NAT-Router. Der Verkehr von Ihrem Receiver geht zum Telefon, dann leitet das Telefon ihn weiter — aber der VPN-Tunnel verschlüsselt nur den Verkehr, der vom Telefon selbst stammt.

\n\n

Einige Telefone mit Root-Zugriff können den gesamten Hotspot-Verkehr durch das VPN zwingen (iptables-Regeln in der FORWARD-Kette), aber das Standard-Android und iOS tun dies nicht. Ihr CCcam-Verkehr verlässt das Telefon unverschlüsselt.

\n\n

Kostenlose VPN-Apps auf Android STBs: Kompatibilitätsprobleme

\n\nAndroid-basierte Receiver (Formuler Z-Serie, MAG 425A, Mecool-Boxen) können VPN-Apps aus dem Play Store installieren. Das kann tatsächlichfunktionieren — das VPN-Framework von Android tunnelt den gesamten Systemverkehr durch die VPN-App, einschließlich CCcam-Clients, die auf der Box laufen.

\n\n

Aber drei Probleme treten auf. Erstens müssen Sie "Immer aktives VPN" in den Android-Einstellungen aktivieren (Einstellungen → Netzwerk → VPN → Zahnrad-Symbol → Schalter "Immer aktives VPN"). Ohne dies trennt sich das VPN, wenn die App in den Hintergrund geht. Zweitens schließen einige kostenlose VPN-Apps standardmäßig bestimmte Apps vom Tunnel aus — überprüfen Sie die Einstellungen für das Split-Tunneling. Drittens fügt die VPN-Implementierung von Android mehr Overhead hinzu als native WireGuard/OpenVPN, da der Verkehr durch die VpnService-Java-Schicht von Android geht, bevor er den Tunnel erreicht.

\n\n

Randfälle, die Sie treffen werden

\n\n

Einige Dinge, die Sie bei Nichtbeachtung im Voraus beißen werden:

\n\n

\n
• IPv6-Leck: Selbst mit einem funktionierenden VPN, wenn Ihr Empfänger IPv6 aktiviert hat und das VPN nur IPv4 tunnelt, wird Ihre echte IP über IPv6 DNS und Verbindungsversuche geleakt. Lösung:echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
\n
• DNS-Leck: Ihr Empfänger könnte den DNS des Routers (der zu Ihrem ISP führt) verwenden, selbst wenn das VPN aktiv ist. Erzwingen Sie DNS durch das Tunnel: fügen Siedhcp-option DNS 1.1.1.1 zu Ihrer OpenVPN-Konfiguration hinzu oder setzen Sie DNS in/etc/resolv.conf manuell.
\n
• Mehrere Empfänger, ein VPN: Wenn Sie zwei Empfänger über dasselbe VPN betreiben und beide den Port 12000 outbound verwenden, wird die NAT-Übertragung kompliziert. Der VPN-Server sieht zwei Verbindungen von derselben IP zum selben Zielport. Lösung: Verwenden Sie unterschiedliche lokale CCcam-Ports pro Empfänger in/etc/CCcam.cfg:SERVER LISTEN PORT : 12001
\n
• VPN-Serverstandort: Wenn Ihr CCcam-Server in den Niederlanden und Ihr VPN-Server in US-West ist, reisen die Pakete: Sie → US-West → Niederlande → US-West → Sie. Doppelte Distanz, doppelte Latenz. Wählen Sie einen VPN-Server, der geografisch nahe an Ihrem CCcam-Server liegt, nicht nahe bei Ihnen.
\n

\n\n