Skip to content

OpenWRT - Zonen

Verschoben OpenWRT & Ubiquiti ER-X
  • Was mir immer noch etwas Kopfschmerzen bereitet, ist die Firewall. Mal ein Beispiel.

    f3da391f-459f-40b7-bcbe-58cfb5afb2cb-grafik.png

    Ich habe zwei LANs, einmal LAN und einmal "DMZ". Wenn ich nun vom LAN aus Teilnehmer in der "DMZ" erreichen will, geht das so nicht. Dafür muss man die Einstellungen von LAN editieren.

    7f173a6c-c491-41db-be0a-a95e044baf76-grafik.png

    Danach kann ich dann einen Teilnehmer aus der "DMZ" z.B. pingen.

    frank@:~$ ping 192.168.5.99
    PING 192.168.5.99 (192.168.5.99) 56(84) Bytes Daten.
    64 Bytes von 192.168.5.99: icmp_seq=1 ttl=63 Zeit=0.707 ms
    64 Bytes von 192.168.5.99: icmp_seq=2 ttl=63 Zeit=0.712 ms
    ^C
    --- 192.168.5.99 ping statistics ---
    2 Pakete übertragen, 2 empfangen, 0% Paketverlust, Zeit 1019ms
    rtt min/avg/max/mdev = 0.707/0.709/0.712/0.002 ms
    

    Ok, so weit verstanden. Aber wofür ist dann dieses Forward zuständig 🤔

    5d8000c1-388f-4cd3-9577-af85049cbd9b-grafik.png

  • Was mir immer noch etwas Kopfschmerzen bereitet, ist die Firewall. Mal ein Beispiel.

    f3da391f-459f-40b7-bcbe-58cfb5afb2cb-grafik.png

    Ich habe zwei LANs, einmal LAN und einmal "DMZ". Wenn ich nun vom LAN aus Teilnehmer in der "DMZ" erreichen will, geht das so nicht. Dafür muss man die Einstellungen von LAN editieren.

    7f173a6c-c491-41db-be0a-a95e044baf76-grafik.png

    Danach kann ich dann einen Teilnehmer aus der "DMZ" z.B. pingen.

    frank@:~$ ping 192.168.5.99
    PING 192.168.5.99 (192.168.5.99) 56(84) Bytes Daten.
    64 Bytes von 192.168.5.99: icmp_seq=1 ttl=63 Zeit=0.707 ms
    64 Bytes von 192.168.5.99: icmp_seq=2 ttl=63 Zeit=0.712 ms
    ^C
    --- 192.168.5.99 ping statistics ---
    2 Pakete übertragen, 2 empfangen, 0% Paketverlust, Zeit 1019ms
    rtt min/avg/max/mdev = 0.707/0.709/0.712/0.002 ms
    

    Ok, so weit verstanden. Aber wofür ist dann dieses Forward zuständig 🤔

    5d8000c1-388f-4cd3-9577-af85049cbd9b-grafik.png

    Es ist was heller geworden 🙂

    7b86e97c-31a5-44b6-809f-25d9d1c2ee4a-image.png

    Die besagte Forward Regel

    Zonen.png

    Diese Forward Regel zieht erst dann, wenn es mehrere Interfaces in einer Zone gibt. Aus der Doku

    • INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone.
    • OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone.
    • FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone.

    Das heisst nun, das ein Forwarding zwischen zwei Zonen immer eine spezifische Regel unter Traffic Rules benötigt.

    Forwarding between zones always requires a specific rule.

    Somit ist ein Forwarding zwischen zwei Zonen in den Standard Einstellungen nicht erlaubt. Das kann ich hier auch so bestätigen. Das ist ja auch das was ich mit meiner "DMZ"-Zone erreichen möchte. Kein Zugriff auf LAN.

    Unter Zone ⇒ Forwardings kann man jetzt sehen, das das Forwarding von LAN in Richtung WAN und DMZ erlaubt ist. WAN ist logisch, sonst komme ich ja nicht ins Internet. DMZ habe ich eingestellt, damit ich auch Teilnehmer im DMZ Netz erreichen kann, wenn ich da mal ran muss.

    8a548c29-8bc5-4074-8099-66460bcea9a8-image.png

    Stelle ich das jetzt so ein.

    dca8b393-f613-4cab-a377-ffbc2bb8ddf5-image.png

    Dann kann ich von der DMZ Zone aus das LAN erreichen. Aha, so langsam verstehe ich 😉

    Quelle: https://forum.openwrt.org/t/firewall-zones-and-settings/84369

  • Debian Bookworm 12.6 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    154 Aufrufe
    Niemand hat geantwortet
  • Redis ändert das Lizenz Modell

    Redis
    2
    0 Stimmen
    2 Beiträge
    173 Aufrufe
    FrankMF
    Ein Artikel von Heise zum Thema https://www.heise.de/news/Datenbankanbieter-Redis-aendert-sein-Lizenzmodell-erneut-9661949.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon
  • Ansible - Proxmox Server bearbeiten

    Ansible
    1
    1
    0 Stimmen
    1 Beiträge
    430 Aufrufe
    Niemand hat geantwortet
  • NanoPi R2S - OpenWRT VLAN

    Verschoben NanoPi R2S
    11
    8
    0 Stimmen
    11 Beiträge
    1k Aufrufe
    FrankMF
    @thrakath1980 Ok, du meinst die FriendlyArm Variante von OpenWRT. Ich denke, da sollte man besser alles neu machen. Leider ist das bei OpenWRT nicht so einfach zu updaten/upgraden wie z.B. bei einem Linux Kernel. Ich habe es mal runtergeladen, wenn ich mal Zeit habe, schau ich mal rein.
  • LUKS verschlüsselte Platte mounten

    Linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    So, jetzt das ganze noch einen Ticken komplizierter Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen. Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung. unbekannter Dateisystemtyp „LVM2_member“. Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen. root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7 Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool. root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands. Das muss dann so aussehen! vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten! Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet. /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0 Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!! Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren
  • ROCKPro64 - Projekt Wireguard Server

    Verschoben ROCKPro64
    2
    2
    0 Stimmen
    2 Beiträge
    532 Aufrufe
    FrankMF
    Hat ein wenig Nerven gekostet und der Artikel ist auch was länger geworden Viel Spaß beim Lesen und testen!
  • ROCKPro64 - PCIe NVMe SSD installieren

    Hardware
    1
    0 Stimmen
    1 Beiträge
    333 Aufrufe
    Niemand hat geantwortet
  • Sidebar im Theme Quark bearbeiten

    Grav
    1
    0 Stimmen
    1 Beiträge
    597 Aufrufe
    Niemand hat geantwortet