OpenVPN Zugriffe

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    ich habe mir einen OpenVPN Server auf den Pi gesetzt. Pi ist die 192.168.2.2 (DHCP und DNS Server hier), Router ist die 2.1 an diesem kann ich aber kaum Einstellungen vornehmen (wie stat. routen). Das VPN Subnetz ist die 10.8.0.0

    Eine Verbindung vom client läuft.
    Ich kann vom client auf den Raspi zugreifen, mit hostnamen (interessanterweise) und anpingen über ips 10.8.0.1, 192.168.2.2
    Niemanden aus dem server-subnetz

    Der Raspi kann aber nur sich selbst anpingen, nicht den client (10.8.0.6) - strange?

    Im 1. Schritt möchte ich, dass clients auf das Subnetz hinter dem VPN Server zugreifen können. Dazu muss ich laut OpenVPN-Howto in der Server config
    'push route SERVER-SUBNET SUBNETMASK' (erledigt) - außerdem müssen das Server-Subnet wissen, dass es über den VPN-Server routet.
    Das würde sich über eine statische Route im Router lösen lassen - kann ich aber nicht machen, da der Speedport hier zu beschränkt ist.

    Ich hab Hinweise gesehen, dass es über IPtables und MASQERADE funktioniert - da bin ich aber nicht durchgestiegen, und die einzelnen Szenarien, die ich gefunden haben , sind von meinen abgewichen. Ich wäre über eine Erklärung was genau mit welchem Befehl passiert sehr dankbar!

    Im 2. Schritt möchte ich die Clientconfig (von client1) auf einen DD-WRT Router in einem anderen Netzwerk stellen. Dort ist er aber auch nur als Hub / WLAN-AP zuständig.
    Dafür ist dort der Router eine Fritzbox, lässt also mehr Konfiguration zu.
    Dann sollen Maschinen aus Clientsubnetz auf Serversubnetz Zugriff haben und andersrum.

    Im 3. Schritt sollen die Zugriffe dann auch noch per hostnamen funktionieren. Ich bin mir nicht ganz sicher wie das zu bewerkstelligen ist. Im Server-Netz habe ich einen DNS Server, der das dort übernimmt. Den könnte ich pushen. Aber würden dann nicht alle DNS Anfragen vom Client übers VPN gehen? Und wie bringe ich das den "Client-Nachbarn" bei? - Ganz zu schweigen von Hosts im Clientnetz (feste könnte ich im DNS eintragen, solange die VPN-Verbindung und das Subnetz geroutet geht das evtl. Aber evtl. gibt elegantere Wege? . (und später 2. Clients die aufs Clientnetz wollen? - Würde per DNS im Servernetz auch gehen)

    Zusätzlich will ich noch andere Clients (Client2) haben, die sich per VPN einwählen, und idealerweise auf beide Subnetze Zugriff haben.
    (Wenn wir ganz fleißig sind überlegen wir auch noch wie man client3 nur Zugriff aufs Serversubnet und client4 nur Zugriff auf den Pi gewährt.)

    Hier meine server.conf (kommentierte sind teilweise schon Vorbereitung für Schritt 2 und weitere)

    und client1.ovpn

    Einmal editiert, zuletzt von dubidum (14. September 2016 um 07:15)


  • Der Raspi kann aber nur sich selbst anpingen, nicht den client (10.8.0.6) - strange?

    Wie ist auf deinem Raspi, die Ausgabe von:

    Code
    route -n


    ?

    Hast Du auf dem Client evtl. eine aktivierte Firewall? Welches OS ist auf dem Client (10.8.0.6)?

    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
    pi@raspberrypi:~ $ route -n
    Kernel-IP-Routentabelle
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.2.1     0.0.0.0         UG    202    0        0 eth0
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
    10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    192.168.2.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

    Wenn, dann sollte maximal die systeminterne laufen. Ich schalte mal ab und teste nochmal.
    Im Moment nutze ich zum testen mein Laptop (über Mobilfunk) mit Win10, hätte auch noch mein Smartphone (android - linuxnäher ^^)
    Später soll es DD-WRT sein, aber dem Gerät kann ich noch weniger Auskünfte entlocken.

    Edit: Ja, natürlich wars die Windowsfirewall die den Ping geblockt hat XD
    Pings an Server-Subnetz-Clients kommen trotzdem nicht zurück. Gut, Antworten auf Anfragen lassen Firewalls ja geschickt durch.

    Ich versuche mal die Ausgabe oben zu interpretieren:
    Pakete an 0.0.0.0 (= default Gateway = Internet) gehen am Netzwerkinterface raus an meinen Router ?Was ist mit der Netzmaske? Und warum Metric 202 ? (=Hops)
    Alle Pakete ans 10.8.0.0-Subnetz gehen über den "VPN-Software-Router" 0.2 ans Tunnel-Interface. OK. (Also Pakete / Antworten an Clients wie 10.8.0.6)
    Alle Pakete an den Router 0.2 gehen am Tunnel-Interface zum Internet-Gateway (das sitzt doch an eth0?)
    Alle Pakete ans eigene Subnetz gehen ans Default-Gateway am eth0. Macht wiederrum keinen Sinn für mich. Klar der Router schickt die dann passend weg.
    Ich glaube die 0.0.0.0 interpretiere ich noch nicht richtig...

    Ansonsten Server-Subnetz-Maschine schickt an Client (10.8.0.6)... kommt irgendwie (Magie?) am Router vorbei landet am Pi eth0. Dort wird er an den Tunnel geleitet VPN-Router 0.2
    Ich nehme an der "verpackt das ganze" und schickt dann ein Paket an eine WAN-IP raus (1. Zeile) die geht über den Router zum Client.
    Ok Antwort vom Client kommt zurück (NAT) Router schickt es am eth0 zum Pi. | Wie gelangt es zum VPN-Router? | Beim VPN Router wird es wieder zerstückelt und entweder in eine 8.0.x Ip umgesetzt oder in eine 168.2.x -> weiß nicht wie das dann abläuft.

    Einmal editiert, zuletzt von dubidum (14. September 2016 um 08:19)


  • Ich versuche mal die Ausgabe oben zu interpretieren:

    Nein. Du denkst zu kompliziert. Dafür ist folgende definierte Route zuständig:

    Code
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0


    Ich habe eine ähnliche Konstellation wie Du. Hättest Du einen "brauchbaren" VPN-Client (Linux, FreeBSD, ...) dann könntest Du auf dem Client sehen was ankommt und was weggeht. Z. B.:
    Auf dem Server (PI mit OpenVPN):

    Code
    :~ $ ping -c 3 10.4.0.6
    PING 10.4.0.6 (10.4.0.6) 56(84) bytes of data.
    64 bytes from 10.4.0.6: icmp_seq=1 ttl=77 time=25.4 ms
    64 bytes from 10.4.0.6: icmp_seq=2 ttl=77 time=21.6 ms
    64 bytes from 10.4.0.6: icmp_seq=3 ttl=77 time=22.4 ms
    
    
    --- 10.4.0.6 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2003ms
    rtt min/avg/max/mdev = 21.670/23.209/25.487/1.643 ms


    Auf dem Linux-VPN-Client:

    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

  • Zitat

    Nein. Du denkst zu kompliziert. Dafür ist folgende definierte Route zuständig:

    Ich habe versucht jede Zeile einzeln "in Worte zu fassen" - waren die alle falsch?


    mhhh ich will jetzt eigentlich nicht auf die schnelle riskieren ein 2. OS auf meinen Laptop zu ziehen

    Aber auf ein LIVE-System bekomme ich OpenVPN nicht drauf. Würde es eine Virtual Machine tun?

    Was ist mit Paketsniffern? Kenn mich da wirklich nicht aus, aber sind die nicht für genau sowas gemacht?

    Einmal editiert, zuletzt von dubidum (14. September 2016 um 12:45)

  • Was ist mit Paketsniffern? Kenn mich da wirklich nicht aus, aber sind die nicht für genau sowas gemacht?

    Ja. z. B. wireshark wäre auch ok.

    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


  • Okay, hab jetzt net zeitlich kurze Aufzeichnung mit Wireshark gemacht auf dem Tunnel Interface (bzw. Ethernet 2 auf dem die IP eben 10.8.0.6 ist)
    Ziemlich viel, und Copy&Paste geht so auch nicht direkt.
    Nach was sollte ich denn ausschauen?

    Interessant ist: 365 72.797252 00:ff:9b:a4:67:37 00:ff:9c:a4:67:37 ARP 42 Who has 10.8.0.5? Tell 10.8.0.6 <- der Client findet sienen DHCP nicht?
    795 202.071092 10.8.0.6 192.168.2.2 ICMP 74 Echo (ping) request id=0x0001, seq=67/17152, ttl=128 (reply in 796)
    796 202.112506 192.168.2.2 10.8.0.6 ICMP 74 Echo (ping) reply id=0x0001, seq=67/17152, ttl=64 (request in 795)

    1266 349.822526 10.8.0.6 192.168.2.100 ICMP 74 Echo (ping) request id=0x0001, seq=68/17408, ttl=128 (no response found!)
    Ich kann damit nicht viel anfangen. Ich sehe zwar viel interessantes, aber das hat damit zu 99% nichts zu tun


    Das Problem sind doch die Antworten, PC Anfragen von Masch. beim Server an eine 10.8.0.x-Adresse, bei denen der Router nicht weiß wohin damit.
    Im Router kann ich keine stat. Rout anlegen. Also was tun?
    Automatisch zusammengefügt:
    https://jankarres.de/2013/05/raspbe…r-installieren/

    Zitat

    Nun richten wir die Internetweiterleitung ein, damit später der durch OpenVPN verbundene Computer auch Internetzugriff erhält. Sofern du nicht die Ethernetbuchse deines Raspberry Pis nutzt (z.B. W-LAN) musst du eth0 im folgenden Kommando durch den Namen deines Netzwerkadapters ersetzen. Wie dieser heißt, findest du mittels
    ifconfig
    heraus.

    Code
    sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
    sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE



    https://wiki.ubuntuusers.de/Router/ erklärt das etwas näher:
    Portforwarding im Kernel (von tun an eth0?)
    Und dann wird NAT aktiviert, und zwar für Quell-IPs aus 10.8.0.0, für Anfragen die auf eth0 rausgehen bzw rückwärts für IPs die dort reingehen.
    MASQUERADE verschleiert das ganze, bzw. die geNATteten IPs nach außen
    Brauche ich das? Das ist kein Sicherheitsfeature oder? Sondern damit keine Probleme mit den IPs entstehen

    Habe in meinen Notizen auch noch das gefunden:

    Zitat

    In der Konfiguration als Server: push "redirect-gateway def1 bypass-dhcp"
    In der iptables Firewall: iptables -t nat -A POSTROUTING -s 10.0.0.0/8 ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE


    Ich überschreibe das Standard-Gateway ohne es zu löschen (was bedeutet das für mich?) (wird das nicht meinen ganzen Internetverkehr umleiten?) und das auf direkter Route zum DHCP ohne Tunnel (also direkt offen übers Internet?)
    Der zweite befehl wie oben, nur dass hier das Quellnetz größer gewählt ist, was bedeutet das "!" ? und -d steht dafür dass nur solche Adressen geprüft werden.
    - In dem Link werden die beiden Befehle dann noch so verankert, dass sie dauerhaft gelten. Kann ich das nicht mit der OpenVPN config starten? Nachdem OpenVPN als Service startet wäre das dann immer dabei.
    Edit: Hat bei mir nicht funktioniert. Keine Verbindung mehr möglich mit der redirect option. Kein Ping vom /ins Servernetz mit dem iptables Befehl
    Variante mit ipforward funktioniert!

    - Das NAT funktioniert doch generell so auch im beim CLient oder? Kann man die 1zu1 übernhmen oder muss etwas angepasst werden?
    - Für Clientseitige Nachbarn muss auch im Servernetz ins Clientnetz geroutet werden. Ist das auch per NAT machbar?
    z.B.

    Code
    sudo iptables -t nat -A POSTROUTING -s 192.178.168.0/24 -o eth0 -j MASQUERADE


    - Ich verstehe das Pakete vom Client auf dem Server genattet werden, also passen Antworten. Aber was wenn ein Server-Nachbar die Anfrage startet ? Dann weiß doch immer noch der Router nich wohin?

    Einmal editiert, zuletzt von dubidum (15. September 2016 um 04:17)

  • OK, der Ping über die tun-Interfaces funktioniert.

    Wie sind jetzt auf deinem PI (mit dem OpenVPN-Server), die Ausgaben von:

    Code
    sysctl net.ipv4.ip_forward
    sudo iptables -nvx -L -t nat
    hostname -I   # großes I und nicht kleines l
    sudo nmap -sn 192.168.????.0/24 | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}'
    # oder von
    sudo arp-scan -v --interface=<Interface> 192.168.???.0/24
    # oder gleichwertig


    ?

    BTW: Bei der Installation von nmap bzw. arp-scan, achte auf die Abhängigkeiten. Evtl. willst Du deshalb diese tools nicht auf deinem PI installieren. Evtl. vor eine Installation nur simulieren:

    Code
    apt-get -s install nmap arp-scan

    EDIT:

    Auf dem VPN-Client brauchst Du eine Route in das Subnetz deines PIs (VPN-Server), mit der IP-Adresse des tun-Interfaces/devices als gateway. Wie ist z. Zt. auf deinem VPN-Client, die Ausgabe von:

    Code
    route -n


    (oder gleichwertig)?


    Automatisch zusammengefügt:


    Interessant ist: 365 72.797252 00:ff:9b:a4:67:37 00:ff:9c:a4:67:37 ARP 42 Who has 10.8.0.5? Tell 10.8.0.6 <- der Client findet sienen DHCP nicht?

    Nein, der Client (... was war das für ein Client?) weiß nicht, dass die tun-Interfaces nicht "arpable" (d. h. mit noarp konfiguriert) sind und sendet arp-requests. Z. B.:

    Code
    :~ $ ifconfig tun0 | grep -i arp
             UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
    Code
    :~ $ sudo tcpdump -vvveni tun0 arp
    [sudo] password for ######: 
    tcpdump: expression rejects all packets

    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 (15. September 2016 um 09:36)

  • Ehm, also im Moment funktioniert server-seitig alles soweit ich mir das vorstelle - abgesehen von der Namensauflösung von fernen Geräten. (Ich kann ja für Windows Geräte einen DNS Server pushen, aber 1. wird der Client kein Win-Gerät sein, 2. hilft das nichts bei client-nachbarn)
    Client-seitig noch nicht. Habe hier im LAN/WAN Gateway ne statische Route 192.168.178.0 auf VPN-Client gesetzt.

    Kann aber z.B. die Fritzbox (clientseite) nicht vom Pi anpingen. Gut ich kann auch den Client unter seiner lan-IP nicht anpingen (nur über vpn-subnet)... Sehe auf Client Seite keine Pings im Wireshark. Der Ping wird also nicht zum Tunnel geroutet.
    Ich habe in der server.conf ein 'route SUBNET MASK' und ein 'push "route SUBNET MASK"'; außerde, om der ccd/client1 das 'iroute SUBNET MASK' Das sagt ja den Kernel bzw. VPN wie es routen muss.
    Jetzt muss das Paket aber noch in den Subnetzen an VPN gehen. Im Client Subnetz habe ich dafür eine stat. Route gesetzt.
    Kann ich im Pi wieder mit NAT arbeiten für 192.168.178 ? - Eigentlich müsste ich im Client wieder natten bevor es zum VPN geht? Damit die ..178er 10.8er Ips bekommen, die werden ja im PI wieder genattet und funktionieren dann. Aber dieses Nat ist ja die andre Richtung?


    (Jetzt muss ich noch den Clientseite regeln und Client auf nem DD-WRT Router zum laufen bringen)


    Die Einstellungen behält er beim reboot!

    Ehm, ich habe jetzt bei der Simulation div. Bibliotheken gesehn, perl, www, robotrules, python. Ich nehme an da gehts um Webhosting, was mir SOrgen machen sollte?
    (Hab lighttpd laufen, von daher: zu spät, oder?)

    Ausgabe von nmap auf pi-subnetz sind die 3 Maschinen die dort gerade laufen: Router, Pi, NAS
    (bin nicht mehr vor ort sondern im späteren Dauer-Client-Subnetz)
    Ausgabe auf das Client-Subnetz: nichts

    Einmal editiert, zuletzt von dubidum (15. September 2016 um 18:57)

  • Also, ich bin weitergekommen.

    Mein "Fix-Client" läuft, es ist nicht der DD-WRT Router geworden (das Openvpn dort war anscheinend zu alt ~ leicht inkompatibel) sondern Freetz/OpenVPN also eine Fritz.Box, mit dem Vorteil, dass es sich dabei um den Router des Client-Netzes handelt.

    Ich will die Situation nochmal neu darstellen:

    Server config:


    Client1 = Fix mit Subnetz Config:


    Client2 (=3,4,5 mobile) Config:

    Ich kann im Moment per Ping erreichen:
    - Vom VPN-Server (pi):
    Geht: Eigene Ip tun0 (10.8.0.1), Client1 VPN Subnetz (10.8.0.6), Client2 VPN (10.8.0.10), lokale Nachbarn (192.168.2.x)
    Nicht: Nachbarn oder Client im Client1 Subnetz (192.168.178.1 bzw .x)

    - Vom Client1:
    Geht: VPN-Server (pi) im VPN-Subnetz (10.8.0.1), eigene VPN-IP (10.8.0.6), lokale Nachbarn (178.x), Server und Nachbarn im Server-Subnetz (2.x), Client2 VPN-IP (10.8.0.10)
    Geht nicht: -

    - Von NAS = Server-Subnetz-Nachbar (192.168.2.100):
    Geht: VPN Server VPN-IP (10.8.0.1), lokale Nachbarn (2.x)
    Geht nicht: VPN-Client1 oder 2 (10.8.0.x), Client1 Subnetz IP / Nachbarn (178.x)

    -Von: Client1-Nachbar:
    Geht: Lokale Nachbarn inkl. Client1 (178.x), Client1 VPN-IP (10.8.0.6)
    Geht nicht: Server/Clients VPN Ips (10.8.0.x), Ferne Nachbarn (192.168.2.100)

    Offensichtlich fehlt im Client1 Netz noch das Routing. Wie genau das geht, würde ich bei Freetz/Ip-Phone-Forum nachfragen, da die Fritz.Box wohl routen auf sich selbst nicht zulässt, und es da kompliziertere Lösungen gibt, aber wie es aktuell aussieht...?
    Wenn das funktioniert, dann müssten Client1 Nachbarn aufs Server Netz zugreifen können, wie der Client1
    Außerdem Client2 auf Client1 Nachbarn ?

    Fragestellung für hier
    Problematisch ist nur, wie Server-Nachbarn (NAS 192.168.2.100) auf Client1-Nachbarn (192.168.178.x) zugreifen können. Ab dem VPN Interface sollte es gehen. Aber wie kommen die Pakete dorthin? Am Server-Router kann ich keine Routen einrichten.


  • Fragestellung für hier
    Problematisch ist nur, wie Server-Nachbarn (NAS 192.168.2.100) auf Client1-Nachbarn (192.168.178.x) zugreifen können. Ab dem VPN Interface sollte es gehen. Aber wie kommen die Pakete dorthin? Am Server-Router kann ich keine Routen einrichten.

    Konfiguriere auf den Server-Nachbarn, eine Route:

    Code
    sudo route add -net 192.168.178.0 netmask 255.255.255.0 gw 192.168.2.2

    (oder gleichwertig),
    mit dem VPN-Server (192.168.2.2) als gateway.

    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

  • Okay, ja da hätte ich eigentlich auch drauf kommen können.
    Eine zentralere Lösung wäre mir aber lieber, falls möglich.

    z.B. würde es gehen, 2 Subnetze am Server Standort zu erstellen, wobei 2.x der WAN-Router und der Pi bleiben, und 3.x der Pi und alle anderen Maschinen beinhaltet?
    Der Pi würde dann als Router / Gateway fungieren (obwohl der physische Aufbau anders aussieht)
    Bzw. würde das Sinn machen? Aller Internetverkehr müsste über den Pi laufen (und sein übers USB-Interface angebundenes Ehternet Interface - meine ich gelesen zu haben)

    Einmal editiert, zuletzt von dubidum (2. Oktober 2016 um 21:41)


  • Eine zentralere Lösung wäre mir aber lieber, falls möglich.

    Dann brauchst Du einen Router, den Du entsprechend konfigurieren kannst.

    EDIT:

    Siehe auch: http://www.ip-phone-forum.de/showthread.php?t=287925

    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 (3. Oktober 2016 um 00:08)


  • - Vom VPN-Server (pi):
    ...
    Nicht: Nachbarn oder Client im Client1 Subnetz (192.168.178.1 bzw .x)

    Poste mal von deinem PI (VPN-Server), die Ausgaben von:

    Code
    cat /etc/openvpn/server.conf | grep -i route
    ls -la /etc/openvpn/ccd
    route -n
    sudo iptables -nvx -L -t nat


    Starte auf deiner gefreetzten FritzBox (VPN-Client):

    Code
    tcpdump -c 30 -vvveni any icmp


    führe danach auf deinem PI (VPN-Server):

    Code
    ping -c 2 -W 2 192.168.178.40
    ping -c 2 -W 2 192.168.178.1


    aus und poste danach die Ausgabe von tcpdump (von der FritzBox/VPN-Client).

    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

  • @ rpi444 der Thread im IP-Phone Forum ist von mir, hatte ich ja vorgesehen, auch wenn eigentlich überflüssig (VPN-Server = Gateway bedeutet keine routen dort nötig)

    [font="monospace"]cat /etc/openvpn/server.conf | grep -i route:
    [/font]

    Code
    # Sage Clients, Ips aus Subnet per VPN zu routen
    push "route 192.168.2.0 255.255.255.0"
    # Sage anderen Clients, Ips aus Subnet(Client1) per VPN zu routen
    # in ccd muss 'client1-file' liegen in dem 'iroute 192.168.178.0 255.255.255.0' steht
    # Das sagt VPN welches Subnet, zu welchem Client geroutet werden soll
    #push "route 192.168.178.0 255.255.255.0"
    route 192.168.178.0 255.255.255.0

    Das push ist auskommentiert, weil es mir sonst immer den Client1 verhagelt (siehe IPF)

    [font="monospace"]ls -la /etc/openvpn/ccd[/font]

    Code
    insgesamt 12
    drwxr-xr-x 2 root root 4096 Sep 14 06:06 .
    drwxr-xr-x 3 root root 4096 Sep 14 06:17 ..
    -rw-r--r-- 1 root root   98 Okt  2 23:38 client1

    route -n:

    Code
    Kernel-IP-Routentabelle
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         192.168.2.1     0.0.0.0         UG    202    0        0 eth0
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
    10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    192.168.2.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
    192.168.178.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0

    sudo iptables -nvx -L -t nat


    Auf der Fritzbox läuft tcpdump nicht.
    root@fritz:/var/mod/root# tcpdump -c 30 -vvveni any icmp
    -sh: tcpdump: not found


    Da muss ich jetzt erst mal ein neues Image mit dem Paket kompilieren. (Bitte Warten.......)

    Einmal editiert, zuletzt von dubidum (3. Oktober 2016 um 15:43)


  • sudo iptables -nvx -L -t nat

    Konfiguriere auf deinem PI, auch:

    Code
    sudo iptables -t nat -I POSTROUTING 1 -o tun+ -j MASQUERADE


    Auf der Fritzbox läuft tcpdump nicht.
    root@fritz:/var/mod/root# tcpdump -c 30 -vvveni any icmp
    -sh: tcpdump: not found


    Da muss ich jetzt erst mal ein neues Image mit dem Paket kompilieren. (Bitte Warten.......)

    Du brauchst keine neues Freetz-Image zu flashen. Cross-kompiliere in deinem Build-System das tcpdump-binary und kopiere dieses auf die FritzBox (... evtl. auch nur mit einem USB-Stick).

    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 (3. Oktober 2016 um 14:26)


  • Konfiguriere auf deinem PI, auch:

    Code
    sudo iptables -t nat -I POSTROUTING 1 -o tun+ -j MASQUERADE


    Done. Aber für meine Notizen: was genau macht das?
    Ich füge in die Tabelle NAT ein, dass kurz bevor es weggeschickt wird (POSTROUTING) die Pakete (1?) ans Tunnelinterface gehen. MASQUERADE spezifiziert den NAT-Typ. Aber auf welche Pakete bezieht sich das?


    Zitat von rpi444


    Du brauchst keine neues Freetz-Image zu flashen. Cross-kompiliere in deinem Build-System das tcpdump-binary und kopiere dieses auf die FritzBox (... evtl. auch nur mit einem USB-Stick).


    Ich bin mir nicht sicher, ob das für mich einfacher wäre.
    Leider kann ich auf mein Build-System gerade nicht zugreifen (hatte Freetz-Linux VM auf meinem Desktop benutzt, weil ich dachte ich müsste da nicht so oft ran. Ich werds jetzt auf dem Pi einrichten, da komme ich immer ran.
    -> Edit: auf dem Pi funktioniert gerade DNS-Auflösung nicht (** server can't find http://www.google.de: REFUSED
    )(verdammt!!) Ich weiß auch nicht was ich dort verändert habe (außer am OpenVPN zeugs) Das muss ich wohl erstmal reparieren

    Einmal editiert, zuletzt von dubidum (3. Oktober 2016 um 14:51)


  • Aber auf welche Pakete bezieht sich das?

    Auf die durch das tun-Interface ausgehenden Pakete. Das tun-Interface ist das device (gateway), das für das routing ins 192.168.178.0/24-er Subnetz zuständig ist. Siehe die Ausgabe von "route -n" auf deinem PI (VPN-Server).

    EDIT:

    Wie ist jetzt nach einem ping ins 178er Subnetz, auf dem PI:

    Code
    ping -c 3 -W 2 192.168.178.1


    , die Ausgabe von:

    Code
    sudo iptables -nvx -L -t nat


    auf deinem PI?

    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 (3. Oktober 2016 um 14:48)

  • Code
    pi@raspberrypi:~ $ sudo ping -c 3 -W 2 192.168.178.1
    PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
    
    
    --- 192.168.178.1 ping statistics ---
    3 packets transmitted, 0 received, 100% packet loss, time 2003ms

    tcpdumd / Freetz still under construction ;)

    Einmal editiert, zuletzt von dubidum (3. Oktober 2016 um 15:51)

  • Code
    pi@raspberrypi:~ $ sudo ping -c 3 -W 2 192.168.178.1
    PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.
    
    
    --- 192.168.178.1 ping statistics ---
    3 packets transmitted, 0 received, 100% packet loss, time 2003ms

    Poste von deinem PI (VPN-Server), auch die Ausgabe von:

    Code
    cat /etc/openvpn/ccd/client1

    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!