Reverse proxy clearnet zu Tor

Bei mir hat es jetzt auch endlich geklappt. Das Tutorial hat mir extrem dabei geholfen, vielen Dank dafür @surenic! :slight_smile:

Ein kleiner Nachtrag noch für Leute die den Raspibltz ab Version 1.8.0 mit LND benutzen: Man muss in der lnd.conf einiges ändern und vor allem das mit der LND-Backup File war ein bisschen kniffelig. Da hat mir das von Surenic eingangs im Tutorial erwähnte Tutorial von TrezorHannes dann weitergholfen. Evtl hilft dieser Hinweis ja noch jemandem der in Zukunft das Setup übernehmen möchte :slight_smile:

LND.conf adjustments, open with sudo nano /mnt/hdd/lnd/lnd.conf

[Application Options]

Command Description
externalip=207.154.241.101:9735 # to add your VPS Public-IP
nat=false # deactivate NAT

[tor]

Command Description
tor.active=true # ensure Tor is active
tor.v3=true # with the latest version. v2 is going to be deprecated this summer
tor.streamisolation=false # this needs to be false, otherwise hybrid mode doesn’t work
tor.skip-proxy-for-clearnet-targets=true # activate hybrid mode

CTRL-X => Yes => Enter to save

RASPIBLITZ LND-checkup FILE sudo nano /home/admin/config.scripts/lnd.check.sh since Raspiblitz has some LND pre-check scripts which otherwise overwrite your settings. Go to line 184 or search for enforce PublicIP if (if not running Tor). Uncomment those 5 lines indicated here:

#  if [ "${runBehindTor}" != "on" ]; then
#    setting ${lndConfFile} ${insertLine} "externalip" "${publicIP}:${lndPort}"
#  else
    # when running Tor a public ip can make startup problems - so remove
#    sed -i '/^externalip=*/d' ${lndConfFile}
#  fi

CTRL-X => Yes => Enter to save

LND Systemd Startup adjustment

Command Description
sudo systemctl restart lnd.service apply changes and restart your lnd.service. It will ask you to reload the systemd services, copy the command, and run it with sudo. This can take a while, depends how long your last restart was. Be patient.
sudo tail -n 30 -f /mnt/hdd/lnd/logs/bitcoin/mainnet/lnd.log to check whether LND is restarting properly
lncli getinfo to validate that your node is now online with two uris, your pub-id@VPS-IP and pub-id@Tor-onion
"03502e39bb6ebfacf4457da9ef84cf727fbfa37efc7cd255b088de426aa7ccb004@207.154.241.101:9736",
     "03502e39bb6ebfacf4457da9ef84cf727fbfa37efc7cd255b088de426aa7ccb004@vsryyejeizfx4vylexg3qvbtwlecbbtdgh6c

Auch von mir vielen Dank an @surenic für die ausführliche Beschreibung. Ich habe allerdings ein paar Fragen und würde mich freuen, wenn mir jemand helfen kann :slight_smile:

  1. Wieso wird resolvconf auf dem Pi installiert?
    Im Tutorial von TrezorHannes wird gesagt, dass das benötigt wird, um DNS requests durch den VPN zu tunneln. Mich würde interessieren, was hier genau passiert und was resolvconf hier tut? Es wird ja einfach nur installiert und nicht in irgendeiner Form angepasst/konfiguriert. Wireguard wird der VPS DNS ja in der wg0.conf mitgeteilt, wieso reicht das nicht?
  2. Wieso ist in deiner Beschreibung @surenic der Teil mit der LND-checkup FILE weg? (im Tutorial von TrezorHannes zu finden unter „Click here to expand Raspiblitz 1.8.x settings“ relativ weit unten)
  3. Auf dem VPS in der wg0.conf wird der forward proxy eingerichtet. Unter anderem wird das gemacht:
    PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
    Besser ist folgendes (sofern man eine statische public IP hat, wovon auszugehen ist):
    PostUp = iptables -t nat -I POSTROUTING -o eth0 -j SNAT --to-source VPS-PUBLIC-IP
    Grund: SNAT ist etwas schneller (mit MASQUERADE wird jedes mal geprüft, welche IP das Interface hat) und SNAT funktioniert auch dann weiter, wenn zwischendurch das Interface mal kurz down war (auch wenn das unwahrscheinlich ist, wieso den Vorteil nicht mitnehmen?), siehe hier: iptables - Difference between SNAT and Masquerade - Unix & Linux Stack Exchange
  4. Wenn ich dieser Beschreibung strikt folge, wie verhält sich der Pi nun genau?
    Sofern VPS und VPN-Tunnel laufen, wird sämtlicher ausgehender Traffic über den VPS geroutet, richtig? Tor auch?
    Sofern der VPS oder VPN-Tunnel ausfällt, geht dann
    a) gar nichts mehr oder
    b) funktioniert nur noch Tor über die Route Heimrouter->Internet oder
    c) weiterhin clearnet und Tor, aber beides jetzt über die Route Heimrouter->Internet?

a) wäre suboptimal, weil man dann keinen Fallback auf Tor hätte.
b) wäre exakt so, wie ich es gerne hätte.
c) wäre schlecht, weil man dann seine Home public IP preisgibt.

Moin mxm,

danke für deine Rückmeldung! Ich versuch deine Fragen mal so gut ich kann zu beantworten. Vorab: Ich bin noch nicht lang im Spiel, wahrlich noch kein Linux-Experte und noch am Lernen. Die Intention meines Tutorials war im Grunde, TrezorHannes’ Guide zum Einen auf deutsch zu übersetzen und vor allem den kostenlosen VPS von Oracle aufzusetzen. Daher gleicht sich ganz einfach vieles im Tutorial, ohne dass dir da genauere Auskunft geben kann.

Kann ich direkt nicht beantworten, ich hielt es für notwendig und hab es einfach gemacht. Freu mich, dass du das so hinterfragst. Dann hab ich nämlich jetzt den Ansporn, mir das mal generell genauer anzuschauen.

Der Teil fehlt, weil das seit 1.8 neu ist, weil sich im LND Install Skript etwas getan hat. Ich benutze kein LND, sondern ausschließlich CLN und kann das alles nicht testen. Daher ist das Tutorial outdatet und ich muss das entweder von TrezorHannes kopieren oder darauf hinweisen.

Danke für den Input! Am Lernen und verstehen von iptables bin ich gerade dran. Auch hier hab ich stupide copy paste betrieben und blicke da langsam erst durch.

Das kann ich dir leider auch tatsächlich nicht beantworten. Der Oracle Server lief/läuft monatelang ausfallfrei rund und ich habe keines der Szenarien testen können. Da du in der LND und CLN conf ja die Server IP angibst und diese ans Netzwerk gesandt wird, würde ich vermuten, dass deine Heim-IP beim Ausfall des Wireguards aber nicht preisgegeben wird. Ist aber nur eine Vermutung.

Ich persönlich hab die Node-Verbindung zu Tor komplett deaktiviert und fungiere als Clearnet-Only, da Tor einfach zu langsam ist und teilweise weiterhin als präferierte Verbindung zu den Peers genutzt wird. Zahlungen dauern dann trotzdem gefühlt länger, was mich gestört hat.

Ich hoffe, dass noch weitere Antworten kommen, die technisch auch für mich noch mehr Licht ins Dunkle bringen können!

1 „Gefällt mir“

Ein paar Ergänzungen zu surenic’s Beitrag:
zu 1) resolvconf wird verwendet, um DNS Requests über den Tunnel laufen zu lassen, d.h. den DNS Resolver des VPS zu verwenden anstatt den eigenen (siehe auch How To Set Up WireGuard on Ubuntu 20.04 | DigitalOcean)

zu 4) Ja, das ist Tor-over-VPN. Split-tunneling wird hier nicht eingesetzt. Eine Lösungsmöglichkeit wäre diese: GitHub - Tunnelsats/tunnelsats: Tunnel⚡Sats: Pre-configured VPN for Lightning Nodes. Hier wird alleine der Lightning Traffic markiert und getunnelt (das Setup-Skript zeigt dir beispielhaft wie es gemacht werden könnte, siehe auch Tunnel⚡️Sats | RaspiBolt). Andersherum wäre es auch möglich: kompletten Traffic der Node tunneln, aber Tor-Prozesse markieren und vom Tunnel trennen.

2 „Gefällt mir“

zu 1)
Grundlegend klar, aber was hier technisch passiert, würde mich eben sehr interessieren.
Also es ist ja so: Ohne VPN-Tunnel wird der Pi sein Betriebssystem fragen, welchen DNS er benutzen soll. Das Betriebssystem wird ihm dann sagen: Nimm dafür die lokale IP-Adresse vom Heimrouter. Das funktioniert, weil der Heimrouter die DNS-Anfrage („Moin Router, was ist die IP von blocktrainer.de?“) entgegennimmt, dann einen richtigen DNS-Server fragt (richtige DNS-IP wird vom Internet-Provider zugewiesen oder manuell im Router konfiguriert) und die Antwort an den Pi weiterleitet. Wenn jetzt ein VPN-Tunnel aufgebaut wird, fließt sämtlicher Traffic (auch DNS-Anfragen!) zur Tunnel-Gegenstelle (hier ein VPS). Wenn man keine weiteren Maßnahmen trifft, wird der Pi also weiterhin die lokale IP-Adresse des Heimrouters als DNS versuchen, was dazu führt, dass auch eben dieser Datenverkehr (DNS-Anfrage an lokale Heimrouter-IP) dumm an den VPS weitergeleitet wird und somit der VPS(!) diese Heimrouter-IP versuchen wird anzufragen, um die IP-Adresse zu bekommen. Natürlich kommt keine Antwort, weil der VPS nicht im lokalen Netzwerk des Heimrouters ist und daher unerreichbar ist => Der Pi ist also nicht offline, aber er kann keine Domainnamen mehr auflösen.
Jetzt teilt man ja aber in der Wireguard wg0.conf-Datei auf dem Pi die neue DNS-IP mit (eine, die vom VPS aus erreichbar ist). Wireguard wird mit dieser Info aus der wg0.conf-Datei irgendwas machen (was?), aber anscheinend ist Wireguard dazu nicht in der Lage, wenn nicht resolvconf auf dem Pi-System installiert ist. Wieso? :rabbit2::hole:

zu 2)
Ich versuche auch mal es weiter zu verstehen und gebe hier eine Rückmeldung, falls ich was herausfinde.

zu 4)
@surenic Das Mitteilen der VPS-PUBLIC-IP in der lnd.conf dient meines Wissens nach dazu, dass sich die Node im Lightning P2P Netzwerk mit dieser IP bekannt macht, daher wird diese IP dann auch in den entsprechenden Lightning Explorern angezeigt (auch dann, wenn der VPS down ist). Technisch gesehen ist es ein ganz anderer Schritt, dass der Pi auch tatsächlich den VPS als Proxy benutzt, um nach außen zu kommunizieren. Auch mit entsprechend eingetragener VPS-PUBLIC-IP könnte er theoretisch über den Heimrouter (ohne VPS) nach außen kommunizieren (womit man die HOME-PUBLIC-IP doxen würde, was man eben in der Regel NICHT möchte), aber diese HOME-PUBLIC-IP würde weiterin dann nicht in den Lightning Explorern auftauchen, sondern alle Nodes, mit denen dein Pi labert, bekommen die HOME-PUBLIC-IP. Das möchte ich defintiv verhindern, deshalb frage ich.
@osito Stimmt, „split tunneling“ ist das Stichwort, das ich in dem Kontext auch schon gehört habe. Ist wohl relativ kompliziert, daher traue ich mich da auch erstmal nicht ran (aber danke für den verlinkten guide, der mir zumindest ein bisschen näherbringen konnte, was da so grob passiert).
Ich wäre (zumindest erstmal) auch vollkommen zufrieden damit, wenn es keinen Fallback auf Tor über den Heimrouter gibt (also dass bei einem VPS-Ausfall trotzdem über Tor alles (bitcoind+LND in meinem Fall) weiterläuft). Wie erwähnt, sind die meisten VPS-Provider ziemlich zuverlässig, sodass man sich hier keine ernsthaften Sorgen machen muss, dass an der Supermarktkasse die LN-Zahlung nicht durch geht :slight_smile:

Es gibt auch einfache Alternativen (z.B. mullvad). mullvad bietet einen linux client, der split-tunneling per app oder console kann:

mullvad split-tunnel pid add $(pgrep -x tor)

Damit bspw. ließen sich alle Tor-Prozesse vom VPN-Tunnel ausklammern. Dies muss bei jedem Tor-Neustart geschehen, um jeweils die neusten PIDs zu catchen.

Weitere Dokumentation: GitHub - blckbx/lnd-hybrid-mode: ⚡ Guide: How to set up hybrid-mode (clearnet & Tor) on LND

1 „Gefällt mir“

Vielen Dank, das ist guter Stoff für später, wenn VPN, forward und reverse proxy läuft :slight_smile:

Aber zur Klarstellung: Mit dem jetzigen Setup (Beschreibung von @surenic ohne split tunneling), gibt es KEIN Risiko, dass der Pi die HOME-PUBLIC-IP preisgibt, falls der VPS down ist, korrekt?

Ich glaube schon und zwar in dem Fall, wenn der LND Service gestartet ist und Wireguard (aus welchem Grund auch immer) nicht. Peers könnten ausgehende Clearnet-Verbindungen mit der realen IP bekommen. Ein möglicher KillSwitch wäre, wenn in der lnd.service eine Abhängigkeit zum Wireguard-Service hergestellt wird, sprich: „Starte LND nicht, wenn Wireguard nicht gestartet ist.“, mittels after und requires.

Wenn der VPN-Server während der aktiven Verbindung ausfällt, sollten die IPTable-Rules den Traffic weiterhin in das VPN-Interface lenken, der dann ins Leere läuft.

2 „Gefällt mir“

Danke, das muss ich mir definitiv genauer angucken und falls es wirklich so ist, wie du beschreibst, wäre es cool, wenn @surenic im Tutorial darauf hinweist und auch die Lösungsmöglichkeit beschreibt.

Edit:
Soeben getestet, du hast recht. Wenn der VPS ausfällt während der Tunnel schon etabliert war, ist die Node einfach komplett offline. :+1:

Und deine Idee für den KillSwitch ist denke ich super. Habe mir das angeguckt und so geht es genau:

# LND service unit Datei zum Editieren öffnen
sudo systemctl edit --full lnd.service
# in der [Unit] section "wg-quick@wg0.service" an die beiden zeilen anhängen
Requires=bitcoind.service wg-quick@wg0.service
After=bitcoind.service wg-quick@wg0.service

Das könnte dann also jetzt so ins Tutorial @surenic :slight_smile:

2 „Gefällt mir“

zu 2)
Dieser Teil des Skriptes „/home/admin/config.scripts/lnd.check.sh“ prüft, ob „runBehindTor“ auf „on“ steht. Falls ja, löscht es in der lnd.conf die Zeile, die mit „externalip=“ startet.
Da das Skript immer ausgeführt wird, wenn der Pi neugestartetet wurde, würde man nach jedem reboot die gesetzte VPS-PUBLIC-IP in der lnd.conf verlieren. Ich vermute, dass der Hintergrund ist, dass LND früher keinen Hybrid-Modus konnte und daher im Fall von aktivem Tor die externalip gelöscht wird. Warum bei Raspiblitz das lnd.check.sh-Skript noch so aussieht, weiß ich nicht.

=> Es muss aber definitiv auskommentiert werden, sonst wird die VPS-PUBLIC-IP nicht zur Bekanntmachung des Lightning-Knotens verwendet.

1 „Gefällt mir“

zu 1)
Wireguard setzt ganz einfach resolvconf voraus (obwohl zB Ubuntu seit 18.04 systemd-resolvd standardmäßig nutzt). Hier die entsprechende Doku:
„DNS — a comma-separated list of IP (v4 or v6) addresses to be set as the interface’s DNS servers, or non-IP hostnames to be set as the interface’s DNS search domains. May be specified multiple times. Upon bringing the interface up, this runs ‘resolvconf -a tun.INTERFACE -m 0 -x‘ and upon bringing it down, this runs ‘resolvconf -d tun.INTERFACE‘. If these particular invocations of resolvconf(8) are undesirable, the PostUp and PostDown keys below may be used instead.“
https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8

1 „Gefällt mir“

Hinweis:

Oracle hat gerade meine Server gestoppt, weil sie 7 Tage lang „idle“ waren und die Ressourcen daher freigegeben werden mussten. Kostenlos hat seinen Preis :wink: Entweder regelmäßig auf dem Dashboard einloggen oder, so wie ich es vor zwei Wochen getan habe, überlegen, ob sich ein bezahlter vServer vielleicht doch lohnt.

Ich füg die Infos (auch die von oben) sobald ich kann in das Tutorial ein.

1 „Gefällt mir“

Ich habe einen PR für dein Tutorial eingereicht :slight_smile:

1 „Gefällt mir“

Das war bei mir letzte Woche auch der Fall. Deswegen kann ich auch das hier nochmal bestätigen:

Meine Node war dann auch einfach offline. Ist natürlich nicht optimal, vor allem für jemanden, der öfter mal länger als ne Woche unterwegs ist. Werde das Setup früher oder später wohl auch wieder umbauen müssen… War mit dem gratis VPS bei mir aber sowieso nur zum Ausprobieren und Rumspielen gedacht :slight_smile:

1 „Gefällt mir“

Da split-tunneling aber wirklich nicht so easy aufzusetzen ist, verzichte ich (vorerst) darauf. Ich habe einen VPS für 2,99 € pro Monat gemietet, glaube der ist eh verlässlicher als mein privater ISP :smiley:

1 „Gefällt mir“

Oh, ein VPS für 2,99 € pro Monat klingt echt gut. Kannst du mir dazu bitte eine PM schicken?

Ach darf ich bestimmt auch hier posten, ansonsten sorry @ moderator

Paket „VPS-NVME S (Aktion 2023)“:
https://my.1fire.host/order/main/packages/nvme-vserver/?group_id=25

1 „Gefällt mir“

Hallo @Achse und @surenic,

ich bin was das Thema Linux, Reverse proxy usw. angeht der absolute Laie. Aber ich bin lernfähig und habe mir vor einigen Wochen eine eigene Node zusammen gebastelt. Auf einem Rasperberry Pi 4 mit 8 GB Ram und einer 1 TB SSD Festplatte. Das ganze in dem schicken Argon One Gehäuse mit Festplattenfach. Angeschlossen ist es per LAN Kabel an meine Fritz.Box 6490 Cabel und der Zugriff erfolgt über den Brav Browser meines Windows 10 Laptops.

Installiert habe ich die Apps: Bitcoin Node - voll Synchronisiert, BTC RPC Explorer, mempool, Electrs, Lightning Node und seit neuestem die App BTCPay Server, welche ich mit meinem WordPress (Woocommerce) Shop verbinden möchte. Auf dem Umbrel habe ich die Grundeinstellungen des BTCPay Servers vorgenommen und abgespeichert. Unter WordPress - bzw. Woocommerce habe ich das Plugin BTCPay For Woocommerce V2 installiert und gestartet. Anschließend wollte ich unter den Settings die Verbindung zu meiner Node - bzw. zum BTCPay Server einrichten. Also habe ich meine Adresse kopiert: http://umbrel:3003 und bei BTCPay API Key auf den Link: „click here to generate API key“ geklickt. Die Seite wechselte auf die BTCPay Authorize WooCommerce Seite. Ich wählte meinen erstellten Shop aus und drückte auf den Button „Continue“ und die Seite wechselte auf weiter Einstellungen. Dort fiel mir bereits folgender Satz auf: „If authorized, the generated API key will be provided to https://www.meinedomain.de/?btcpay-settings-callback auf, die ich aber anfangs nicht weiter beachtete. Da laut meiner Anleitung alle Unterpunkte aktiviert sein sollten, klickte ich anschließend auf den Button „Autorized APP“ un die Seite wechselte wieder zu meiner Setting Seite unter Woocommerce. Im Feld BTCPay API Key stand jetzt eine Zahlenreihe - also der API Key. Nach dem Abspeichern unter Woocommerce sollte ich jetzt eigentlich eine Meldung erhalten, das die Verbindung Erfolgreich war. Statt dessen erhielt ich aber diese Meldung: " BTCPay Server: Error fetching data for this API key from server. Please check if the key is valid. Error: Could not resolve host: umbrel; Name or service not known“

Dann fiel es mir wie Schuppen von den Augen und mir wurde klar, das meine Node nicht über das Internet erreichbar ist. Seit dem suche ich eine Schritt für Schritt Anleitung, wie ich meine Node aus dem Internet zugänglich machen kann. Dabei fand ich inzwischen - neben euren - noch ein paar andere Anleitungen. Da ich - wie bereits gesagt - ein absoluter Laie auf dem Gebiet bin, habe ich zuerst versucht alle Schritte - trocken - also ohne etwas zu ändern durchzugehen. Einfach nur, um zu sehen, ob ich überhaupt alle Einstellungen finde usw. Dabei stieß ich auf ein Problem, welches ich leider nicht lösen kann und auch keine Lösung im Internet gefunden haben.

Wie gesagt - ich habe meine Node selber aufgesetzt. Und weil ich die Komponenten gebraucht gekauft habe, musste ich alles neu aufsetzten. Dabei habe ich beim Raspberry PI unter anderem auch die SSH Funktion aktivieren müssen, weil der Vorbesitzer die SSD mit einer Partition versehen hatte, die ich erst mal aufheben musste. Ich habe weder den Standard Username noch das Standardpasswort geändert. Nachdem ich Umbrel installiert hatte, wurde ich natürlich nach einem Usernamen und ein Passwort gefragt, welches ich seit dem für meinen Zugang über den Webbrowser verwende und welches auch tadellos funktioniert.

Also bin ich über PuTTY (gestartet als Admin) und dem Host Namen „Umbrel“ Port 22 auf die Node gegangen. Dort wurde ich nach dem Usernamen gefragt, den ich aus dem Webbrowser übernommen haben, nach dem Enter kam die Abfrage nach dem Passwort, welches ich ebenfalls aus dem Webbrowser genommen habe. Und was passiert…? Nichts! Die Anfrage nach dem Passwort kommt immer wieder. Ich erhalte keinen Zugang via SSH auf meine Node. Ich habe dann versucht statt Username die IP zu verwenden. Das Passwort habe ich dieses mal händig eingegeben - vorher kopiert und mit rechtsklick eingefügt und mit Enter bestätigt. Wieder nichts. Keine Chance - ich komme einfach nicht per SSH auf meine Node.

Ich bin inzwischen mit meinem Latein am Ende und weiß echt nicht mehr weiter. Vielleicht kann mir einer von euch helfen. Ich könnte zwar über den Webbrowser unter Umbrel mein Passwort ändern, befürchte aber, das ich dann weder über Browser noch über SSH auf meine Node komme. Habt Ihr vielleicht eine Idee? Und wenn es uns gemeinsam gelingt das ich wieder mit SSH auf meine Node komme, könnt ihr mir dann helfen meine Node übers Internet zugänglich zu machen? Vielen Dank schon mal im Voraus…!

Hey @Aragon , was die Technik angeht, bin ich leider selbst nur ein Noob, der Hilfe aus diesem Forum bekam. Viel Glück.

Hey @Aragon,

da hast du leider ein paar Baustellen auf einmal.

Leider kenne ich mich mit umbrel nicht gut aus und empfehle aus diversen Gründen auch den Umstieg auf RaspiBlitz (FOSS, keine Bloatware, Bitcoin-Ethos pipapo). Ich weiß nun natürlich nicht, was der umbrel ssh username und Passwort sind und gehe davon aus, dass hier irgendwo der Knackpunkt ist, aber wie gesagt kann ich dir da leider nicht helfen.

Zum BTCPayServer-Problem: du hast ganz richtig erkannt, dass du via umbrel:3003 natürlich nicht auf deine Heimnode kommst. Hier musst du Node und Port von außen erreichbar machen. Viele Wege führen hierbei nach Rom. Solltest du einer der wenigen Glücklichen sein, die über den Heimschluss noch eine eigene erreichbare IPv4 verfügen und sollte dir der Datenschutz nur semi-wichtig sein, wäre der einfachste Weg die Portweiterleitung über die Fritzbox. Da du aber von Fritzbox Cable sprichst, wirst du sicherlich einen DS Lite Anschluss besitzen. Dann bleibt dir nur der Weg über ein VPN.

Dabei setzt du bei einem Provider deiner Wahl einen kleinen 24/7 Linux Server auf, der als z.B. Wireguard VPN Host läuft, installierst auf der Node den Wireguard Client und verbindest die beiden. Deine Node funkt von da an mit der IPv4 des Servers nach außen. Über Portfreigaben und einen installierten Webproxy auf dem Server kannst du nun diverse Dienste der Node freigeben. Das alles benötigt etwas tiefere Kenntnisse, die man sich aber, je nach Interesse auch aneignen kann. Erster Schritt sollte dabei sein, deine Node (LND) ins Clearnet zu stemmen.

Ich empfehle dafür die Anleitung von HODLmetight. Hier ist alles sehr genau und verständlich geschrieben.

Für die Installation von LNbits auf dem Server und der Connection zur Node hat er auch eine Anleitung parat. Hier geht er auf den Webproxy „Caddy“ ein, der sehr zu empfehlen ist. Damit kannst du kinderleicht eine eigene Domain/subdomain (bspw. btcpay.aragon-lernt-web-services.de) an deine Node/Port3003 weiterleiten, so dass dieser Service dann via clearnet erreichbar ist.

Wenn du dich da einliest und mit der Thematik befasst, kommst du hier zum Ziel.

Ich selbst habe einen VPN bei IONOS laufen, betreibe dort den winzigen VPS S für 2€/Monat. Der reicht völlig für Wireguard und LNbits. Gibt aber auch genug andere. Wenn du HODLmetights Anleitung exakt befolgst und den empfohlenen Service dort nimmst, klappt seine Anleitung vermutlich problemfrei. Bei mir musste ich bisschen basteln und diverse/andere/ähnliche Settings anpassen, damit alles klappt.

Man lernt aber Unmengen über ssh, Kommandozeilen, Sicherheit, Firewalls, Portfreigaben usw.

Wünsche vorab schonmal viel Spaß! Bei Fragen frag :wink: