Das längste Thema

  • Ist ein Netzwerk konvergent? Client A soll Client B erreichen.

    Client A hat folgende Config:


    Code: Client A
    #ip a
    inet 172.20.25.8/24 brd 172.20.25.255 scope global ens6
    #ip r l
    10.68.255.0/31 via 172.20.25.1 dev ens6 proto zebra metric 20


    Code: Client B
    #ip a
    inet 10.68.255.0/31 scope global wg0
    #ip r l
    172.20.25.0/24 via 10.68.255.1 dev wg0 proto bird metric 64

    Beide sehen sich, beide wissen, wie sie einander erreichen über einen Dritten. Die Routingtabellen sind Konvergent.

  • Mit Rückroute meine ich, dass das Proxmox Netz auch weiß, über welchen Weg es das OpenVPN Netz erreichen kann.

    pasted-from-clipboard.png

    Hier ein Container aus dem ProxMox Netz. Er kann das VPN problemlos erreichen.



    Und hier der VPN Server... kann den Container nicht erreichen...

    pasted-from-clipboard.png



    EDIT: Ich tendiere ja mittlerweile wirklich dazu, dass das ein Konfigurationsproblem von OpenVPN ist. Entweder am Server oder am Client. Hat da jemand mal eine Beispielconfig, mit der sowas funktioniert?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Und hier der VPN Server... kann den Container nicht erreichen...

    Erreicht er denn 172.21.0.2?

    Stell dich mal an jedem Hop mit tcpdump -nni ethX icmp und gucke, wo der Traffic verschluckt wird.

    Wenn ein Hop von einem Interface ins andere routet, beide Interfaces scannen.


    Auch auf die Source IPs achten, dass die so gewollt sind wegen dem NAT.

  • Erreicht er denn 172.21.0.2?

    Ja, tut er.


    Ich habe das gerade getestet. Der Traffic wird an 172.21.0.1 abgefangen, kommt garnicht erst bei 172.21.0.2 an.

    Es scheint also, wie ich bereits vermutete, am OpenVPN Server zu liegen, dass der das nicht weiter routet. Aber woran könnte das liegen? :/

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Es scheint also, wie ich bereits vermutete, am OpenVPN Server zu liegen, dass der das nicht weiter routet. Aber woran könnte das liegen?

    Das hatte ich auch schonmal, dort blieb der Traffic aber im Tunnel stecken.

    Kommt denn der Traffic im Tunnelinerface auf der anderen Seite an?

    Was sagt denn die Firewall an 172.21.0.1?

  • Tunnelinerface auf der anderen Seite

    Du meinst in tun0 auf dem NAS? Nein, tut er nicht.


    Die Firewall sagt... naja, meinst du die Regeln oder die Logs?

    Loggen tut er nichts. Und die routing Regeln (siehe unten) funktionieren auch...

    Nicht wundern wegen dem UDP und TCP. Das meint nur das Protokoll, mit dem die OpenVPN Instanz läuft.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Und die routing Regeln (siehe unten) funktionieren auch...

    Das sind immer noch keine Routing Regeln, sondern ein Paketfilter?

    Wie soll man das denn debuggen, wenn überall die Source Adresse gewechselt wird?


    Code
    iptables -S
    iptables -t nat -S
    sysctl net.ipv4.ip_forward

    Einmal bitte die Ausgaben. Die letzten zwei Oktette von Public Adressen kannst du ja zensieren.

  • Wusste bisher gar nicht, dass tcpdump eine Funktion zur Ausgabe der Paketinhalte hat:

  • PowerShell ist echt eine Sprache aus der Hölle:


    Code
    $v = @{}
    Get-Content "whitelist.ini" | % { Try { $r = [regex]::Match($_, '^([^=;][^=]*)=(.*)$').captures.groups; $v.Add($r[1].value, $r[2].value); } Catch {} }
    
    foreach($key in $v.Keys) {
        Write-Output "${key}:"
        Write-Output $(If (Get-ChildItem Env:$key -EA 'Ig') {$(Get-ChildItem Env:$key).Value} Else {$v[$key]}) 
    }
  • Rechnen kann ich auch mit einem Texas Instrument. Dafür brauche ich kein Fortran.

    stimmt, zum Datensammeln braucht ma auch keine EDV, des geht mit Karteikarten auch

    zum Orientieren braucht ma auch kein Navi, des geht mit Kompass und Landkarte/Straßenkarte auch

    zum Schreiben braucht ma auch kei Textverarbeitung, des geht mit einer Schreibmaschine auch

    zum Telephonieren braucht ma auch kei Heizflosse :D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)