Raspberry VPN Gateway aus anderem Netz nutzen

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Ich habe einen Rapsberry 4 im Einsatz und dort ein VPN Gateway installiert.


    Das Netz ist 192.168.178.1 , das VPN Gateway des Raspberry 192.168.178.5

    Wenn ich bei einem Rechner aus dem gleichen Netz (z.B. 192.168.178.45) das VPN Gateway als Gateway Adresse eintrage, funktioniert alles einwandfrei.

    Meine Frage betrifft ein mit dem 192.168.178.1 über openvpn konstant verbundenes Netzwerk 192.168.2.1

    Wenn ich dort bei einem Rechner (z.b. 192.168.2.20) als Gatewayadresse die o.g. 192.168.178.5 eintrage, kommt keine Verbindung zustande. Ich kann zwar mit Ping problemlos von dem Rechner 192.168.2.20 das VPN Gateway anpingen, dennoch wird der Traffic nicht über das VPN Gateway geroutet.

    Welche Einstellung fehlt mir, damit das ganze funktioniert?

    Danke für eure Hilfe und viele Grüße

    Baybod

  • Wenn ich dort bei einem Rechner (z.b. 192.168.2.20) als Gatewayadresse die o.g. 192.168.178.5 eintrage, kommt keine Verbindung zustande. Ich kann zwar mit Ping problemlos von dem Rechner 192.168.2.20 das VPN Gateway anpingen, dennoch wird der Traffic nicht über das VPN Gateway geroutet.

    Für welchen Traffic soll die 192.168.178.5 das gateway auf der 192.168.2.20 sein?

    Welches OS hast Du auf der 192.168.2.20? Wenn es Linux ist, dann poste von dort, die Ausgaben von:

    Code
    ip r g 192.168.178.5
    ip a
    ip r
    sudo iptables -nvx -L -t nat

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Der 192.168.2.20 ist eine Linux Sat Receiver - VU Uno 4k SE


    ip r g 192.168.178.5

    192.168.178.5 via 192.168.2.1 dev eth0 src 192.168.2.20

    ---------

    ip a

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

    valid_lft forever preferred_lft forever

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000

    link/ether 00:1d:ec:15:c8:9e brd ff:ff:ff:ff:ff:ff

    inet 192.168.2.20/24 scope global eth0

    valid_lft forever preferred_lft forever

    inet6 fe80::21d:xxxx:xxxx:c89e/64 scope link

    valid_lft forever preferred_lft forever

    -----------

    ip r

    default via 192.168.2.1 dev eth0

    169.254.0.0/16 dev eth0

    192.168.2.0/24 dev eth0 src 192.168.2.20


    sudo iptables -nvx -L -t nat

    liefert keine Ergebnis (auch nicht ohne sudo)

    Die Rechner können sich gegenseitig anpingen, sobald ich das Gateway im 192.168.2.20 auf 192.168.178.5 stelle, bekommt der 192.168.2.20 keine internetverbindung mehr. Bin für die Hilfe sehr dankbar

    es geht um den gesamten Internettraffic des 192.168.2.20

  • ..., sobald ich das Gateway im 192.168.2.20 auf 192.168.178.5 stelle, bekommt der 192.168.2.20 keine internetverbindung mehr.

    Dann poste vom 192.168.2.20, die Ausgaben von:

    Code
    ip r
    ip r g 1.1.1.1
    arp -av
    ping -c 3 1.1.1.1
    host -t a heise.de 1.1.1.1

    , wenn Du im 192.168.2.20, das Gateway auf 192.168.178.5 gestellt hast.

    ... und vom PI (192.168.178.5) die Ausgaben von:

    Code
    ip a
    ip r
    arp -av
    sudo iptables -nvx -L -t nat
    sysctl net.ipv4.ip_forward 

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • ich Stelle gerade fest, dass wenn ich auf dem 192.168.2.20 das gateway 192.168.178.5 aktiveren moechte, so wird das nicht gespeichert und das gateway deaktivert.

    an dem gleichen receiver im netz 192.168.178.x kann ich das gleiche gateway 192.168.178.5 prolemlos aktivieren und es geht auch. Woran könnte das liegen?

    Soll ich dennoch die Ausgaben posten?

    Dann poste vom 192.168.2.20, die Ausgaben von:

    Code
    ip r
    ip r g 1.1.1.1
    arp -av
    ping -c 3 1.1.1.1
    host -t a heise.de 1.1.1.1

    , wenn Du im 192.168.2.20, das Gateway auf 192.168.178.5 gestellt hast.

    ... und vom PI (192.168.178.5) die Ausgaben von:

    Code
    ip a
    ip r
    arp -av
    sudo iptables -nvx -L -t nat
    sysctl net.ipv4.ip_forward 
  • ich Stelle gerade fest, dass wenn ich auf dem 192.168.2.20 das gateway 192.168.178.5 aktiveren moechte, so wird das nicht gespeichert und das gateway deaktivert.

    .... Woran könnte das liegen?

    Das liegt daran, dass Du auf diesem Gerät wenn es im Subnetz 192.168.2.0/24 ist, keine definierte Route zum Gerät mit der IP 192.168.178.5 hast, und diese IP nur über die jetzige default route (mit dem gateway 192.168.2.1) erreichen kannst.

    Machst Du die Konfiguration auf dem receiver über ein Web-Interface oder gibt es dort auch eine Kommandozeile?

    Hat der receiver auch einen USB-Anschluss, so dass Du eine 2. NIC (via USB) dort benutzen könntest?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Du musst die entfernten Netze in deinen Routern ( Default Gateways) bekannt machen.

    >>Das Netz ist 192.168.178.1 , das VPN Gateway des Raspberry 192.168.178.5

    In der FB 192.168.178.1 eine Route zu 192.168.2.0/24 mit dem nächsten Hop 192.168.178.5 (VPN Gateway) eintragen.

    In dem Router 192.168.2.1 eine Route zu 192.168.178.0/24 mit dem nächsten Hop 192.168.2.20 (VPN Gateway)

    Beide Router müssen wissen wo sie die Pakete für das Unbekannte Netz hinschicken sollen, ist da kein Eintrag für da geht es zur Default Route, ins Internet.


    Ich hatte hier vor Ewigen Zeiten mal einen Post eingestellt wie man richtig routet, finde den aber nicht mehr.
    Ist wohl verschollen gegangen.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Du musst die entfernten Netze in deinen Routern ( Default Gateways) bekannt machen.

    Das hat er lt. seinen Beiträgen auch schon gemacht und es funktioniert auch:

    Code
    Der 192.168.2.20 ist eine Linux Sat Receiver - VU Uno 4k SE
    
    ip r g 192.168.178.5
    192.168.178.5 via 192.168.2.1 dev eth0 src 192.168.2.20
    Zitat

    Ich kann zwar mit Ping problemlos von dem Rechner 192.168.2.20 das VPN Gateway anpingen, ...

    Zitat

    Die Rechner können sich gegenseitig anpingen, ...

    Er will auf dem 192.168.2.20, den Internet-Traffic nicht über 192.168.2.1, sondern über 192.168.178.5 routen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Er will auf dem 192.168.2.20, den Internet-Traffic nicht über 192.168.2.1, sondern über 192.168.178.5 routen.

    Dann einfach statische Routen in den PI 192.168.2.20


    /etc/dhcpcd.conf

    Code
    static routers=192.168.2.1

    Auskommentieren

    Dann in die

    /lib/dhcpcd/dhcpcd-hooks/40-route

    Code
    ip route add 192.168.178.0/24 via <VPNIP>
    ip route add 192.168.2.0/24 via 192.168.2.1
    ip route add 0.0.0.0/0 via 192.168.178.1

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Dann einfach statische Routen in den PI 192.168.2.20

    /etc/dhcpcd.conf

    Auskommentieren

    BTW: Die 192.168.2.20 ist nicht der PI. Siehe oben:

    Zitat

    Der 192.168.2.20 ist eine Linux Sat Receiver - VU Uno 4k SE

    ... und ob die einen dhcpcd hat?

    Die 192.168.2.20 (Linux Sat Receiver) hat auch keine <VPNIP>, sondern erreicht das VPN-Subnetz/gateway, via ihre default route mit dem gateway/Router 192.168.2.1 (siehe oben):

    Zitat

    Ich habe einen Rapsberry 4 im Einsatz und dort ein VPN Gateway installiert.

    Das Netz ist 192.168.178.1 , das VPN Gateway des Raspberry 192.168.178.5

    EDIT:

    @TE:

    Zitat


    Meine Frage betrifft ein mit dem 192.168.178.1 über openvpn konstant verbundenes Netzwerk 192.168.2.1

    BTW: Die 192.168.178.1 wird eine FritzBox sein, oder? ... und was ist die 192.168.2.1 für ein Router? Hast Du auf der 192.168.2.1, den OpenVPN-Client installiert/konfiguriert?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (10. August 2022 um 11:49)

  • Zitat

    Meine Frage betrifft ein mit dem 192.168.178.1 über openvpn konstant verbundenes Netzwerk 192.168.2.1

    Wenn ich dort bei einem Rechner (z.b. 192.168.2.20) als Gatewayadresse die o.g. 192.168.178.5 eintrage, kommt keine Verbindung zustande. Ich kann zwar mit Ping problemlos von dem Rechner 192.168.2.20 das VPN Gateway anpingen, dennoch wird der Traffic nicht über das VPN Gateway geroutet.

    Im Moment macht er Split Tunneling.
    Um das zu ändern, dass die Box ( 192.168.2.20 ) allen Traffic in den Tunnel schickt, muss entweder der Router oder die VPN Box allen Traffic über den Tunnel routen. Dafür muss das Default Gateway dann geändert werden, und der Tunnel so konfiguriert das alles von Rechts nach Links geroutet wird.

    Macht man meistens um Ländersperren zu umgehen.

    Ist so nicht ganz trivial zu lösen, da beide PI ja weiterhin alles zum Router routen müssen um den Tunnel aufzubauen.
    Heißt, der Client bekommt den VPN PI als Default Gateway und der Tunnel ist mit einem Redirect Def-Gateway konfiguriert.

    Wenn es mir nur darum geht aus dem "Linken Netz" in das "Rechte Netz" und vice versa zu kommen, dann ist es eine Routing Kiste auf dem Router und den VPN Kisten.
    Der Router des "rechten Netz" muss alle IP Adressen des "linken Netz" zum VPN PI Routen.
    Der Router des "linken Netz" alle IP des "rechten Netz" zu seinem VPN PI routen.

    Auf jeden Fall müssen BEIDE Router Kenntnis darüber haben wo sie die jeweiligen Netze des anderen Standort finden.

    Alternativ kann ein Host den VPN PI als Gateway eingetragen haben und dieser PI routet alles darüber.
    Dann muss allerdings die Config des Tunnels entsprechend sein.

    Dass das ganze Routing nicht sauber ist zeigt diese Aussage :

    Zitat
    Das Netz ist 192.168.178.1 , das VPN Gateway des Raspberry 192.168.178.5
    Wenn ich bei einem Rechner aus dem gleichen Netz (z.B. 192.168.178.45) das VPN Gateway als Gateway Adresse eintrage, funktioniert alles einwandfrei.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?

    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Dass das ganze Routing nicht sauber ist zeigt diese Aussage :

    Sagen wir mal so, diese Aussage des TE (... betr. 2. Zitat im Beitrag #12), hilft nicht weiter bzw. ist nicht zielführend für sein Anliegen ... und hat auch einen kleinen Schönheitsfehler. Aber wir wissen doch, dass mit "Das Netz ist 192.168.178.1", das "192.168.178.0/24" gemeint ist.

    Ob das Routing "bei dem Rechner aus dem gleichen Netz" sauber oder nicht sauber ist, wissen wir (noch) nicht, ... weil es für das was der TE will, auch nicht relevant war bzw. nicht relevant ist.

    Wenn wir das trotzdem wissen wollen, müsste der TE uns vom PI und vom "Rechner aus dem gleichen Netz" (mit und ohne VPN-gateway), die entsprechenden/erforderlichen Informationen liefern. Z. B.:

    Code
    ip a
    ip r
    arp -av
    ip r g 1.1.1.1
    mtr -4nr -c 1 1.1.1.1

    Mehr sage bzw. schreibe ich zu deinem Beitrag #12, jetzt nicht. ;)

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Danke für die Beiträge. Ich kann auch auf der VUPlus Box in ein Command fenster, vermutlich mit reduziertem Befehlssatz. Fände es toll, wenn ich eine Lösung finden würde.

    Hier schon einmal die Befehle von 192.168.178.5 , dem VPN Gateway

    ip a

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether dc:xx:22:22:5c:f9 brd ff:ff:ff:ff:ff:ff

    inet 192.168.178.5/24 brd 192.168.178.255 scope global noprefixroute eth0

    valid_lft forever preferred_lft forever

    3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

    link/ether dc:a6:32:22:5c:fa brd ff:ff:ff:ff:ff:ff

    4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100

    link/none

    inet 10.99.24.33/24 brd 10.99.24.255 scope global tun0

    valid_lft forever preferred_lft forever

    ip r

    0.0.0.0/1 via 10.99.24.1 dev tun0

    default via 192.168.178.1 dev eth0 src 192.168.178.5 metric 202

    10.31.24.0/24 dev tun0 proto kernel scope link src 10.99.24.33

    128.0.0.0/1 via 10.99.24.1 dev tun0

    192.168.2.0/24 via 192.168.178.1 dev eth0

    192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.5 metric 202

    214.222.161.137 via 192.168.178.1 dev eth0


    arp -av

    ? (192.168.178.211) auf <unvollständig> auf eth0

    ? (192.168.178.73) auf 48:2a:e3:40:bf:50 [ether] auf eth0

    ? (192.168.178.209) auf 74:42:7f:a4:0a:c2 [ether] auf eth0

    ? (192.168.178.21) auf 00:1d:ec:15:c8:aa [ether] auf eth0

    ? (192.168.178.39) auf 00:17:88:63:8d:6a [ether] auf eth0

    ? (192.168.178.94) auf bc:8c:cd:e3:c5:26 [ether] auf eth0

    ? (192.168.178.25) auf 00:11:32:62:e6:d7 [ether] auf eth0

    ? (192.168.178.37) auf b4:d5:bd:b8:3d:37 [ether] auf eth0

    ? (192.168.178.1) auf 74:42:7f:a4:0a:c2 [ether] auf eth0

    ? (192.168.178.52) auf 20:17:42:04:08:84 [ether] auf eth0

    ? (192.168.178.75) auf 44:4e:6d:61:c1:35 [ether] auf eth0

    ? (192.168.178.72) auf 48:2a:e3:40:bf:50 [ether] auf eth0

    ip r g 1.1.1.1

    1.1.1.1 via 10.99.24.1 dev tun0 src 10.99.24.33 uid 1000

    cache

    mtr -4nr -c 1 1.1.1.1

    Befehl nicht gefunden


    Sagen wir mal so, diese Aussage des TE (... betr. 2. Zitat im Beitrag #12), hilft nicht weiter bzw. ist nicht zielführend für sein Anliegen ... und hat auch einen kleinen Schönheitsfehler. Aber wir wissen doch, dass mit "Das Netz ist 192.168.178.1", das "192.168.178.0/24" gemeint ist.

    Ob das Routing "bei dem Rechner aus dem gleichen Netz" sauber oder nicht sauber ist, wissen wir (noch) nicht, ... weil es für das was der TE will, auch nicht relevant war bzw. nicht relevant ist.

    Wenn wir das trotzdem wissen wollen, müsste der TE uns vom PI und vom "Rechner aus dem gleichen Netz" (mit und ohne VPN-gateway), die entsprechenden/erforderlichen Informationen liefern. Z. B.:

    Code
    ip a
    ip r
    arp -av
    ip r g 1.1.1.1
    mtr -4nr -c 1 1.1.1.1

    Mehr sage bzw. schreibe ich zu deinem Beitrag #12, jetzt nicht. ;)

  • hier die Ergebnisse vom der VU Plus Box 192.168.2.20

    ip a

    root@vuuno4kse:~# ip a

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

    valid_lft forever preferred_lft forever

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000

    link/ether 00:xx:xx:15:c8:9e brd ff:ff:ff:ff:ff:ff

    inet 192.168.2.20/24 scope global eth0

    valid_lft forever preferred_lft forever

    inet6 fexx::2xx:ecff:fe15:c89e/64 scope link

    valid_lft forever preferred_lft forever

    root@vuuno4kse:~#


    ip r

    default via 192.168.2.1 dev eth0

    169.251.0.0/16 dev eth0

    192.168.2.0/24 dev eth0 src 192.168.2.20

    arp -av

    ? (192.168.2.37) at xx:ax:be:09:b5:f4 [ether] on eth0

    ? (192.168.2.21) at 00:xx:xx:4f:1f:23 [ether] on eth0

    ? (192.168.2.1) at cc:ce:xx:35:98:64 [ether] on eth0

    ? (192.168.2.30) at 40:6c:xx:yy:be:39 [ether] on eth0

    ip r g 1.1.1.1

    1.1.1.1 via 192.168.2.1 dev eth0 src 192.168.2.20

    mtr -4nr -c 1 1.1.1.1

    -sh: mtr: command not found

  • Das ist ein sehr sauberes Routing (auf der 192.168.2.20), aber nicht das was Du willst.

    Nach dem Du die jetzige default route:

    Code
    default via 192.168.2.1 dev eth0

    gelöscht hast, konfiguriere dort mal:

    Code
    ip route add 192.168.178.5 via 192.168.2.1
    ip route add 0.0.0.0/0 via 192.168.178.5

    Dann hast Du eine definierte Route zum VPN-Gateway 192.168.178.5, via den Router 192.168.2.1 und eine default route mit dem (VPN-)gateway 192.168.178.5.

    Konfiguriere noch auf dem PI, das source-NAT (MASQUERADE, in der POSTROUTING chain und nat table) für die Interfaces eth0 und tun0 (bzw. das forwarding sollte auf dem PI schon konfiguriert sein).

    Danach vom Receiver die Ausgaben von:

    Code
    ip r
    ip r g 1.1.1.1

    posten.

    EDIT:

    BTW: Für mtr kannst Du mtr-tiny installieren:

    Code
    sudo apt install mtr-tiny

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Danke Dir sehr rpi444

    Kannst Du mir evtl. den Befehl für den RPI also 192.168.178.5 sagen, ich habe danach gesucht, bin aber nicht sicher, was ich dort eingeben muss. Ich meine zu dem Absatz von Dir:

    !Konfiguriere noch auf dem PI, das source-NAT (MASQUERADE, in der POSTROUTING chain und nat table) für die Interfaces eth0 und tun0 (bzw. das forwarding sollte auf dem PI schon konfiguriert sein)."

    Danke Dir sehr!!!

  • Ich meine zu dem Absatz von Dir:

    Code
    sudo iptables -t nat -I POSTROUTING 1 -o eth0 -j MASQUERADE
    sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE

    Wie ist auf dem PI (gateway) die Ausgabe von:

    Code
    sysctl net.ipv4.ip_forward

    ?

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Code
    sudo iptables -t nat -I POSTROUTING 1 -o eth0 -j MASQUERADE
    sudo iptables -t nat -I POSTROUTING 2 -o tun0 -j MASQUERADE

    Wie ist auf dem PI (gateway) die Ausgabe von:

    Code
    sysctl net.ipv4.ip_forward

    Habe ich gerade ausgeführt inkl. der o.g. Befehle bzgl POSTRouting

    Die Ausgabe ist:

    net.ipv4.ip_forward = 1

  • […]

    Die Ausgabe ist:

    net.ipv4.ip_forward = 1

    OK, das passt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!