[GELÖST] IPTables auf PVE-Host verhindert Namensauflösung an VM

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Njuguna
Beiträge: 99
Registriert: 28.03.2023 09:47:30

[GELÖST] IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von Njuguna » 12.06.2024 11:40:36

Hallo,

jetzt mache ich doch noch ein Thema zu der Namensauflösung auf. Mittlerweile hatten wir ja herausgefunden, dass das ein Firewall-Problem ist. Leider komme ich doch nicht alleine weiter.
Ich habe hier einen PVE-Host in einem Datacenter, das Infrastrukur für eigene Hardware zur Verfügung stellt, also kein Standardprovider wie Hetzner, Inos etc. Ich selber komme nicht an die Hardware heran, ausser über eine KVM-Konsole.

Problembeschreibung:
Auf dem PVE-Host mit Promox 8.2.2 läuft im Moment nur eine VM mit Debian Linux 12.5. Auf dem PVE-Host läuft eine IPtables-Firewall über UFW. Und unter diesen Umständen kann die VM keine Namensauflösung machen, der PVE-Host sehr wohl. Schalte ich die Firewall auf dem PVE-Host aus, funktioniert die Namensauflösung auch auf der VM problemlos.
Ich hatte jetzt die UFW auf dem PVE-Host - die VM hat noch keine Firewall - komplett gelöscht und deinstalliert. Dann hatte ich UFW wieder neu installiert und eine SSH-Regel eingebaut. Mit der Aktivierung der Firewall auf dem PVE-Host tritt das Problem der Namensauflösung an der VM wieder auf - wie gesagt der PVE-Host hat dieses Problem nicht.

Mittlerweile habe ich auch wieder die anderen Regeln in die Firewall eingebaut, weil ich sie für NFS-Shares und Monitoring an anderen Servern benötige. Für mich spielt das jetzt keine Rolle, ob da nur eine oder 19 Regeln drin stehen, denn alleine das Aktivieren der Firewall auf dem PVE-Host verursacht das Problem. Und das möchte ich nicht nur lösen, sondern auch verstehen können, was da schiefläuft.

Szenario PVE-Host
Dieser PVE-Host hängt an einem Switch, bei dem das Netzwerk aufgeteilt wird wie bei Hetzner-Online, womit 192.110.55.249 und 192.110.55.250 Richtung Internet angeschlossen sind. Die IP-Adressen ab 192.110.55.66 stehen dann einzelnen VMs zur Verfügung.

Netzwerkkonfiguration

Code: Alles auswählen

# ip a show
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
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp49s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ac:1f:6b:26:70:78 brd ff:ff:ff:ff:ff:ff
3: enp49s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether ac:1f:6b:26:70:79 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/30 scope global enp49s0f1
       valid_lft forever preferred_lft forever
4: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether ac:1f:6b:62:15:68 brd ff:ff:ff:ff:ff:ff
    altname enp1s0f0
    inet 192.110.55.250 peer 192.110.55.249/32 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::ae1f:6bff:fe62:1568/64 scope link 
       valid_lft forever preferred_lft forever
5: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ac:1f:6b:62:15:69 brd ff:ff:ff:ff:ff:ff
    altname enp1s0f1
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:5e:30:5b:7d:26 brd ff:ff:ff:ff:ff:ff
    inet 192.110.55.65/26 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::2426:37ff:feec:eabf/64 scope link 
       valid_lft forever preferred_lft forever
7: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2e:0d:94:45:36:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.65/24 scope global vmbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::740a:9aff:fe72:8a10/64 scope link 
       valid_lft forever preferred_lft forever
8: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether aa:5e:30:5b:7d:26 brd ff:ff:ff:ff:ff:ff
9: tap101i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr1 state UNKNOWN group default qlen 1000
    link/ether 2e:0d:94:45:36:2c brd ff:ff:ff:ff:ff:ff

Code: Alles auswählen

# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
        address 192.110.55.250
        netmask 255.255.255.255
        gateway 192.110.55.249
        pointopoint 192.110.55.249
        dns-nameservers 192.55.48.84 9.9.9.9 8.8.8.8 8.8.4.4
        dns-search germany.com

auto vmbr0
iface vmbr0 inet static
        address 192.110.55.65/26
        bridge-ports none
        bridge-stp off
        bridge-fd 0

auto vmbr1
iface vmbr1 inet static
        address 192.168.1.65/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        dns-nameservers 192.55.48.84

auto enp49s0f1
iface enp49s0f1 inet static
        address 192.168.3.1/30

iface enp49s0f0 inet manual

iface eno2 inet manual
Routing auf PVE-Host

Code: Alles auswählen

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.110.55.249  0.0.0.0         UG    0      0        0 eno1
192.110.55.64   0.0.0.0         255.255.255.192 U     0      0        0 vmbr0
192.110.55.249  0.0.0.0         255.255.255.255 UH    0      0        0 eno1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 vmbr1
192.168.3.0     0.0.0.0         255.255.255.252 U     0      0        0 enp49s0f1
Firewall

Code: Alles auswählen

# iptables -nvx -L
Chain INPUT (policy DROP 16 packets, 742 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
  164550 11760787 ufw-before-logging-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  164550 11760787 ufw-before-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   11203   709085 ufw-after-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   10314   667253 ufw-after-logging-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   10314   667253 ufw-reject-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   10314   667253 ufw-track-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 487 packets, 22420 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
   61999  2893321 ufw-before-logging-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   61999  2893321 ufw-before-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-after-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-after-logging-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-reject-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-track-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
  190717 14942070 ufw-before-logging-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
  190717 14942070 ufw-before-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    2742   282613 ufw-after-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    2742   282613 ufw-after-logging-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    2742   282613 ufw-reject-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
    2742   282613 ufw-track-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-after-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-after-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:137
       0        0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:138
       0        0 ufw-skip-to-policy-input  6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:139
       2      104 ufw-skip-to-policy-input  6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:445
       0        0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
       0        0 ufw-skip-to-policy-input  17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:68
       4      200 ufw-skip-to-policy-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
      13      580 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
      13      618 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-after-logging-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-after-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-before-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
      12      432 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 12
      30     1084 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
     490    22544 ufw-user-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-before-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
    1008    64008 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0           
     627    66482 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 ufw-logging-deny  0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
       0        0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 12
      15     1056 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
       0        0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
      27     1326 ufw-not-local  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
       0        0 ACCEPT     17   --  *      *       0.0.0.0/0            224.0.0.251          udp dpt:5353
       0        0 ACCEPT     17   --  *      *       0.0.0.0/0            239.255.255.250      udp dpt:1900
      27     1326 ufw-user-input  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-before-logging-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-before-logging-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-before-logging-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-before-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
    1008    64008 ACCEPT     0    --  *      lo      0.0.0.0/0            0.0.0.0/0           
     895   145382 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 ufw-user-output  0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-logging-allow (0 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW ALLOW] "

Chain ufw-logging-deny (2 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID limit: avg 3/min burst 10
       0        0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "

Chain ufw-not-local (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
      21     1022 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL
       0        0 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type MULTICAST
       6      304 RETURN     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type BROADCAST
       0        0 ufw-logging-deny  0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10
       0        0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-reject-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-reject-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-reject-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-skip-to-policy-forward (0 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-skip-to-policy-input (7 references)
    pkts      bytes target     prot opt in     out     source               destination         
       6      304 DROP       0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-skip-to-policy-output (0 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-track-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-track-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-track-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW
       0        0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate NEW

Chain ufw-user-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-user-input (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     6    --  *      *       0.0.0.0/0            192.110.55.250       tcp dpt:52022
       0        0 ACCEPT     6    --  *      *       192.168.1.0/24       0.0.0.0/0            tcp dpt:52022
       0        0 ACCEPT     6    --  *      *       192.55.48.71         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.71         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.72         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.72         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.75         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.75         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.80         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.80         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.84         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.84         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.85         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.85         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.79         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.79         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.250        0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.250        0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.55.48.76         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.55.48.76         0.0.0.0/0            udp dpt:2049
       0        0 ACCEPT     6    --  *      *       192.168.1.86         0.0.0.0/0            tcp dpt:2049
       0        0 ACCEPT     17   --  *      *       192.168.1.86         0.0.0.0/0            udp dpt:2049
       2      120 ACCEPT     6    --  *      *       192.55.48.72         0.0.0.0/0            tcp dpt:6556
       2      120 ACCEPT     6    --  *      *       192.146.57.85        0.0.0.0/0            tcp dpt:6556
       0        0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
       0        0 ACCEPT     17   --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53

Chain ufw-user-limit (0 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 5 LOG flags 0 level 4 prefix "[UFW LIMIT BLOCK] "
       0        0 REJECT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain ufw-user-limit-accept (0 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain ufw-user-logging-forward (0 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-user-logging-input (0 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-user-logging-output (0 references)
    pkts      bytes target     prot opt in     out     source               destination         

Chain ufw-user-output (1 references)
    pkts      bytes target     prot opt in     out     source               destination

Code: Alles auswählen

# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
192.110.55.250 52022/tcp   ALLOW IN    Anywhere                   # SSH from Internet
52022/tcp                  ALLOW IN    192.168.1.0/24             # SSH from intern network
2049                       ALLOW IN    192.55.48.71               # Allow NFS
2049                       ALLOW IN    192.55.48.72               # Allow NFS
2049                       ALLOW IN    192.55.48.75               # Allow NFS
2049                       ALLOW IN    192.55.48.80               # Allow NFS
2049                       ALLOW IN    192.55.48.84               # Allow NFS
2049                       ALLOW IN    192.55.48.85               # Allow NFS
2049                       ALLOW IN    192.55.48.79               # Allow NFS
2049                       ALLOW IN    192.55.48.250              # Allow NFS
2049                       ALLOW IN    192.55.48.76               # Allow NFS
2049                       ALLOW IN    192.168.1.86               # Allow NFS
6556/tcp                   ALLOW IN    192.55.48.72               # Allow CheckMK monitoring
6556/tcp                   ALLOW IN    192.146.57.85              # Allow CheckMK monitoring
53/tcp                     ALLOW IN    Anywhere                   # Allow DNS traffic
53/udp                     ALLOW IN    Anywhere                   # Allow DNS traffic
53/tcp (v6)                ALLOW IN    Anywhere (v6)              # Allow DNS traffic
53/udp (v6)                ALLOW IN    Anywhere (v6)              # Allow DNS traffic


Szenario am VM-Gast

Netzwerkkonfiguration

Code: Alles auswählen

 # ip a show
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
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:95:b5:34 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet 192.110.55.86 peer 192.110.55.65/32 brd 192.110.55.86 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::be24:11ff:fe95:b534/64 scope link 
       valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:10:f1:8a brd ff:ff:ff:ff:ff:ff
    altname enp0s19
    inet 192.168.1.86/24 brd 192.168.1.255 scope global ens19
       valid_lft forever preferred_lft forever
    inet6 fe80::be24:11ff:fe10:f18a/64 scope link 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

# cat /etc/network/interfaces

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static
        address 192.110.55.86
        netmask 255.255.255.255
        pointopoint 192.110.55.65
        gateway 192.110.55.250
        dns-nameservers 9.9.9.9 8.8.8.8 8.8.4.4
        dns-search germany.com

# The intern network interface
allow-hotplug ens19
iface ens19 inet static
        address 192.168.1.86/24
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 9.9.9.9 8.8.8.8 8.8.4.4
        dns-search germany.com
Routing auf VM

Code: Alles auswählen

# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.110.55.250  0.0.0.0         UG    0      0        0 ens18
192.110.55.65   0.0.0.0         255.255.255.255 UH    0      0        0 ens18
localnet        0.0.0.0         255.255.255.0   U     0      0        0 ens19
Hier ist bisher keine Firewall installiert.

Test für die Namensauflösung an der VM bei aktiver Firewall auf PVE-Host

Code: Alles auswählen

# ping -c3 www.google.com
ping: www.google.com: Temporärer Fehler bei der Namensauflösung

Code: Alles auswählen

# nslookup -query=A www.google.de 9.9.9.9
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; communications error to 9.9.9.9#53: timed out
;; no servers could be reached
Test für die Namensauflösung an dem PVE-Host bei aktiver Firewall auf PVE-Host

Code: Alles auswählen

ping -c3 www.google.com
PING www.google.com (216.58.206.68) 56(84) bytes of data.
64 bytes from tzfraa-aa-in-f4.1e100.net (216.58.206.68): icmp_seq=1 ttl=118 time=7.65 ms
64 bytes from tzfraa-aa-in-f4.1e100.net (216.58.206.68): icmp_seq=2 ttl=118 time=7.63 ms
64 bytes from tzfraa-aa-in-f4.1e100.net (216.58.206.68): icmp_seq=3 ttl=118 time=7.71 ms

--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 7.632/7.663/7.713/0.035 ms

Code: Alles auswählen

# nslookup -query=A www.google.de 9.9.9.9
Server:         9.9.9.9
Address:        9.9.9.9#53

Non-authoritative answer:
Name:   www.google.de
Address: 142.250.184.227
Das ist jetzt ein wenig viel geworden. Aber ich denke, so sind alle notwendigen Informationen kompakt an einer Stelle. Mir geht es darum heraus zufinden, was an der Firewall auf dem PVE-Host so stört, sobald sie nur aktiviert wird. Ich verstehe das insoweit nicht, da ich diese Konstellation Host zu VMs mit der UFW nicht das erste Mal mache und ich dieses Problem so zum ersten Mal sehe.

Viele Grüße
Njuguna
Zuletzt geändert von Njuguna am 13.06.2024 17:38:57, insgesamt 2-mal geändert.

Benutzeravatar
heisenberg
Beiträge: 3746
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von heisenberg » 12.06.2024 12:41:23

Vorab: Ich selbst nutze die ufw nicht - habe speziell davon keine Ahnung, bin aber mit diversen anderen Firewalls vertraut.

ufw ist schon mehr eine "richtige" Firewall. Das bedeutet, dass erst mal jeglicher Traffic verboten ist, der nicht erlaubt ist und auch dass da diverse grundsätzliche Regeln sind, die viele Kleinigkeiten auch bei erlaubten Regeln als unerwünschten Traffic blocken. Vielleicht gibt es da Ausnahmen (z. B. ping). Insofern müssen für jeden Traffic, der erlaubt werden soll, im Einzelnen entsprechende Firewall-Regeln umgesetzt werden, sonst darf die VM da genau das, was sie jetzt eben darf: Gar nichts! Das ist also hier kein Fehler, sondern geliefert, wie beabsichtigt. Insofern solltest Du wissen, wie man eine Firewall konfiguriert, welche Datenströme da üblicherweise anfallen und für diese ganzen Datenströme entsprechende Regeln einrichten können. Mein aktueller Eindruck ist - und da kann ich mich täuschen - dass Du davon (noch) nicht all zu viel Ahnung hast.

Wenn Du das nicht kannst, dann würde ich Dir empfehlen, Dich entweder intensiv in das Thema Netzwerk, Netzwerkprotokolle, Paketfilter und die Bedienung der ufw einzuarbeiten oder ansonsten die Finger von der ufw zu lassen. Als Alternative wäre die Absicherung Deines Servers mit ein paar einfachen iptables / nft Regeln hier mit Sicherheit eine wesentlich einfachere Angelegenheit.

Njuguna
Beiträge: 99
Registriert: 28.03.2023 09:47:30

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von Njuguna » 12.06.2024 14:17:16

Hallo Heisenberg,

ich weiß sehr wohl was Uncomplicated Firewall (UFW) ist, nämlich ein Frontend für die Erstellung von Netfilter-Regeln. Ich kenne auch die Funktionsweise von Firewalls.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 12:41:23
ufw ist schon mehr eine "richtige" Firewall. Das bedeutet, dass erst mal jeglicher Traffic verboten ist, der nicht erlaubt ist und auch dass da diverse grundsätzliche Regeln sind, die viele Kleinigkeiten auch bei erlaubten Regeln als unerwünschten Traffic blocken. Vielleicht gibt es da Ausnahmen (z. B. ping). Insofern müssen für jeden Traffic, der erlaubt werden soll, im Einzelnen entsprechende Firewall-Regeln umgesetzt werden, sonst darf die VM da genau das, was sie jetzt eben darf: Gar nichts! Das ist also hier kein Fehler, sondern geliefert, wie beabsichtigt. Insofern solltest Du wissen, wie man eine Firewall konfiguriert, welche Datenströme da üblicherweise anfallen und für diese ganzen Datenströme entsprechende Regeln einrichten können. Mein aktueller Eindruck ist - und da kann ich mich täuschen - dass Du davon (noch) nicht all zu viel Ahnung hast.
Der Befehl

Code: Alles auswählen

ufw status verbose
sagt doch ganz offensichtlich on top was Sache ist. Insofern fühle ich mich schon irgendwie durch Deine Worte und Deinen aktuellen Eindruck angegriffen. Als ob ich nicht selber lesen könnte, was mir das Programm als Information liefert. Mein aktueller Eindruck von Dir ist, dass Du nicht alles richtig oder komplett liest. Das ist mir bereits gestern in Deinen Antworten aufgefallen, dass Du vorhandene Informationen offensichtlich nicht wahrgenommen hattest und entsprechend reagiert hattest.
Was will ich Dir gerade sagen? Ich mache es Dir einfach:
Ich verstehe das insoweit nicht, da ich diese Konstellation Host zu VMs mit der UFW nicht das erste Mal mache und ich dieses Problem so zum ersten Mal sehe.
Das steht am Ende meines Threads. Anders ausgedrückt sage ich hiermit, dass ich keineswegs das erste Mal eine Firewall konfiguriere. Ich sage sogar, dass exakt dieselbe Firewall-Konfiguration auf anderen PVE-Hosts mit mehreren VMs funktioniert.
Du scheinst das aber entweder nicht zu lesen, oder eben zu ignorieren.
Kann man vielleicht solche Aussagen mitberücksichtigen, anstatt mit subjektiven Eindrücken die Personen negativ zu triggern?

Möchtest Du jetzt hier weitermachen? Oder können exakt bei dem Punkt, dass etwas das bereits funktioniert, jetzt funktioniert? Ich habe jedoch keine Lust mich hier so fertigmachen zu lassen.

Benutzeravatar
heisenberg
Beiträge: 3746
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von heisenberg » 12.06.2024 14:37:13

Hallo Njuguna,

Da habe ich mich also möglicherweise getäuscht, was Deinen Kompetenzstand zum Thema betrifft.

Das ist richtig, dass ich Deinen aktuellen Beitrag nicht sonderlich gewissenhaft gelesen habe. Den gestrigen Beitrag hatte ich allerdings sehr wohl gründlich und mehrfach gelesen.

Ich bin dann hier raus - da ich mich mit der ufw nicht auskenne und hoffe, dass es andere gibt, von denen Du die gewünschte Unterstützung erhältst.

Es ist nicht im Geringsten in meinem Interesse, Dich in irgend einer Form zu diskreditieren oder Dir Deine Kompetenzen abzusprechen. Es geht mir darum, evtl. bessere Vorgehensweisen bei erkannten Kompetenzstufen zu empfehlen. Die Wahrnehmung, dass das, was verschiedentlich Hilfesuchende vor haben, nicht mit den eigenen Fähigkeiten zusammen passt, ist dabei - aus meiner Sicht - häufig der Fall. Falls Du weiterhin Ärger hast - und dazu in den Austausch gehen möchtest - lass' uns das bitte per PN klären, so daß Deine Anfrage hier fachlich ungestört weiter laufen kann.

Viele Grüße,
h.

Njuguna
Beiträge: 99
Registriert: 28.03.2023 09:47:30

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von Njuguna » 12.06.2024 15:00:26

heisenberg hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 14:37:13
Hallo Njuguna,

Da habe ich mich also möglicherweise getäuscht, was Deinen Kompetenzstand zum Thema betrifft.

Das ist richtig, dass ich Deinen aktuellen Beitrag nicht sonderlich gewissenhaft gelesen habe. Den gestrigen Beitrag hatte ich allerdings sehr wohl gründlich und mehrfach gelesen.

Ich bin dann hier raus - da ich mich mit der ufw nicht auskenne und hoffe, dass es andere gibt, von denen Du die gewünschte Unterstützung erhältst.

Es ist nicht im Geringsten in meinem Interesse, Dich in irgend einer Form zu diskreditieren oder Dir Deine Kompetenzen abzusprechen. Es geht mir darum, evtl. bessere Vorgehensweisen bei erkannten Kompetenzstufen zu empfehlen. Die Wahrnehmung, dass das, was verschiedentlich Hilfesuchende vor haben, nicht mit den eigenen Fähigkeiten zusammen passt, ist dabei - aus meiner Sicht - häufig der Fall. Falls Du weiterhin Ärger hast - und dazu in den Austausch gehen möchtest - lass' uns das bitte per PN klären, so daß Deine Anfrage hier fachlich ungestört weiter laufen kann.

Viele Grüße,
h.
Hallo Heisenberg,

ich akzeptiere Deine Entschuldigung hiermit, somit brauchen wir das nicht weiter vertiefen. Ich würde es jedoch, generell an Alle gerichtet, begrüssen, dass wir hier alle sachlich argumentieren. Die IT ist derart komplex, als dass jeder oder jede alles wissen kann. Ich suche jedenfalls nach dem i-Tüpelchen, dass exakt das beschriebene Problem verursacht. Vielleicht ist ja gar nicht UFW und Iptables, sondern hat mit Proxmox zu tun, was ich gerade checke.

Vielen Dank
Njuguna

Benutzeravatar
MSfree
Beiträge: 11063
Registriert: 25.09.2007 19:59:30

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von MSfree » 12.06.2024 15:43:31

Ich habe nur kurz die UFW-Regeln überflogen, und dabei ist mir aufgefallen, daß zwar INPUT-seitig Port 53 UDP/TCP und OUTPUT-seitig Port 53 UDP/TCP erlaubt sind. Um aber von einer VM auf einen DNS zugreifen zu dürfen, der nicht auf dem Proxmox-Host läuft, braucht man noch FORWARD-Regeln. Ich nutze ebenfalls keine UFW, so daß ich dir hier mit der Erstellung solcher Regeln nicht weiterhelfen kann.

Alternativ kannst du natürlich einen DNS auf dem PROXMOX-Host konfigurieren und die VM auf diesen zugreifen lassen. Dafür würden die INPUT/OUTPUT-Freigaben nämlich reichen. Der am einfachsten zu konfigurierende DNS ist meiner Meinung nach dnsmasq, den DHCP-Teil mußt du dann aber abschalten, dann ist es ein einfacher caching DNS.

mat6937
Beiträge: 3209
Registriert: 09.12.2014 10:44:00

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von mat6937 » 12.06.2024 16:03:23

Njuguna hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 11:40:36
Mir geht es darum heraus zufinden, was an der Firewall auf dem PVE-Host so stört, sobald sie nur aktiviert wird.
Probier mal temporär, mit der default policy der FORWARD chain auf ACCEPT:

Code: Alles auswählen

iptables -P FORWARD ACCEPT
Debian 12.6 mit LXDE, OpenBSD 7.5 mit i3wm, FreeBSD 14.0 mit Xfce

Benutzeravatar
heisenberg
Beiträge: 3746
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von heisenberg » 12.06.2024 16:30:05

Njuguna hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 11:40:36
...
Firewall

Code: Alles auswählen

# iptables -nvx -L

...
Chain FORWARD (policy DROP 487 packets, 22420 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
   61999  2893321 ufw-before-logging-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   61999  2893321 ufw-before-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-after-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-after-logging-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-reject-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
   58896  2780543 ufw-track-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
...
Chain ufw-after-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination
    <LEER>         
...
Chain ufw-after-logging-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
      13      580 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 3/min burst 10 LOG flags 0 level 4 prefix "[UFW BLOCK] "
...
Chain ufw-before-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
      12      432 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 3
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 11
       0        0 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 12
      30     1084 ACCEPT     1    --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
     490    22544 ufw-user-forward  0    --  *      *       0.0.0.0/0            0.0.0.0/0           
...
Chain ufw-before-logging-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
    <LEER>
...
Chain ufw-reject-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
    <LEER>
...
Chain ufw-user-forward (1 references)
    pkts      bytes target     prot opt in     out     source               destination         
    <LEER>
...
Ja. MSfree und mat6937 haben recht: Es sind schlicht keine Regeln angelegt, die Port 53 udp+tcp in FORWARD erlauben, wie oben in dem Teil der übersetzten FW-Regeln zu sehen. Da ist sind nur ein paar ICMP-Pakettypen erlaubt und sonst gar nix.

Das muss man für die ufw noch konfigurieren.

Eine gute Möglichkeit wäre hier, dass bei der anderen ufw anzuschauen und zu übernehmen.

Njuguna
Beiträge: 99
Registriert: 28.03.2023 09:47:30

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von Njuguna » 12.06.2024 17:19:51

Erst einmal vielen Dank bis hier her.

Njuguna
Beiträge: 99
Registriert: 28.03.2023 09:47:30

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von Njuguna » 12.06.2024 19:34:05

Ich habe jetzt noch einmal zwei funktionierende UFW-Konfigurationen auf zwei anderen PVE-Hosts mit dem Betroffenen überprüft: Auf hier benötige ich kein Forwarding oder einen lokalen DNS auf dem Host.
Allerdings ich habe dann den Vorschlag des lokalen DNS dnsmasq übernommen und erfolgreich umgesetzt. So ist die Namensauflösung der VM in Ordnung, auch wenn ich nicht ganz nachvollziehen kann, warum das hier so notwendig war. Aber das herauszufinden ist zu zeitintensiv, wichtig ist, dass diese Lösung funktioniert.

Insoweit vielen Dank für die Unterstützung und die Geduld

Njuguna

mat6937
Beiträge: 3209
Registriert: 09.12.2014 10:44:00

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von mat6937 » 12.06.2024 19:54:19

Njuguna hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 19:34:05
Allerdings ich habe dann den Vorschlag des lokalen DNS dnsmasq übernommen und erfolgreich umgesetzt.
Unter welchem user ist der dnsmasq aktiv?

Code: Alles auswählen

ps aux | grep -i [d]ns
systemctl status dnsmasq
?
Zeitintensiv ist das nicht, denn wenn Du (auf einem anderen System) schon funktionierende ufw-Regeln hast, kannst Du diese mit den nicht funktionierenden vergleichen.
Debian 12.6 mit LXDE, OpenBSD 7.5 mit i3wm, FreeBSD 14.0 mit Xfce

Benutzeravatar
heisenberg
Beiträge: 3746
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: [GELÖST] IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von heisenberg » 12.06.2024 20:02:07

Die Befehle für die ufw zum erlauben der Regeln für DNS-Zugriffe von den VMs sind (ungetestet):

Code: Alles auswählen

ufw route allow out on eno1 to any port 53 proto tcp
ufw route allow out on eno1 to any port 53 proto udp
Edit: Korrigiert!

Njuguna
Beiträge: 99
Registriert: 28.03.2023 09:47:30

Re: IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von Njuguna » 13.06.2024 07:45:44

mat6937 hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 19:54:19
Unter welchem user ist der dnsmasq aktiv?

Code: Alles auswählen

ps aux | grep -i [d]ns
systemctl status dnsmasq
?

Code: Alles auswählen

dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; preset: enabled)
     Active: active (running) since Wed 2024-06-12 19:14:34 CEST; 12h ago
    Process: 295191 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 295198 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
    Process: 295206 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
   Main PID: 295205 (dnsmasq)
      Tasks: 1 (limit: 77034)
     Memory: 844.0K
        CPU: 113ms
     CGroup: /system.slice/dnsmasq.service
             └─295205 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08>

Jun 12 19:14:34 neckar2 dnsmasq[295205]: using nameserver 9.9.9.9#53
Jun 12 19:14:34 neckar2 dnsmasq[295205]: using nameserver 8.8.8.8#53
Jun 12 19:14:34 neckar2 dnsmasq[295205]: using nameserver 8.8.4.4#53
Jun 12 19:14:34 neckar2 dnsmasq[295205]: read /etc/hosts - 20 names
Jun 12 19:14:34 neckar2 systemd[1]: Started dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server.
Jun 12 19:22:31 neckar2 dnsmasq[295205]: reducing DNS packet size for nameserver 9.9.9.9 to 1232
Jun 12 20:44:13 neckar2 dnsmasq[295205]: reducing DNS packet size for nameserver 9.9.9.9 to 1232
Jun 13 01:21:12 neckar2 dnsmasq[295205]: reducing DNS packet size for nameserver 9.9.9.9 to 1232
Jun 13 01:40:10 neckar2 dnsmasq[295205]: reducing DNS packet size for nameserver 8.8.8.8 to 1232
Jun 13 02:19:59 neckar2 dnsmasq[295205]: reducing DNS packet size for nameserver 9.9.9.9 to 1232
Benutzer dnsmasq

Warum fragst Du?

Und das hier ist wieder so eine total überflüssige Bemerkung:
mat6937 hat geschrieben: ↑ zum Beitrag ↑
12.06.2024 19:54:19
Zeitintensiv ist das nicht, denn wenn Du (auf einem anderen System) schon funktionierende ufw-Regeln hast, kannst Du diese mit den nicht funktionierenden vergleichen.
Aber das hatte ich hier bereits schon einmal kommuniziert, dass Einige nicht alles lesen oder es nicht verstehen können.
Ich sagte, dass die Fehlersuche zu zeitintensiv ist. Aber Deutsch eben immer noch eine Herforderung für Manche.
Und mich triggert es, wenn ich feststellen darf, dass man mir Unvermögen unterstellt, man aber selber nicht in der Lage ist, gegebene Tatsachen vollständig zu erfassen.

Benutzeravatar
heisenberg
Beiträge: 3746
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: [GELÖST] IPTables auf PVE-Host verhindert Namensauflösung an VM

Beitrag von heisenberg » 13.06.2024 17:04:35

Hallo Njuguna,

nachdem das Problem des Themas nun für Dich behoben ist, noch ein paar abschließende Worte:
Njuguna hat geschrieben:... ich akzeptiere Deine Entschuldigung hiermit ...
Das war keine (Bitte um) Entschuldigung. Das war eine Erläuterung meines vorigen Beitrages und die Ergänzung, dass mein Respekt für andere Menschen hier unabhängig ist von deren Verhalten.

Bzgl. meiner inhaltlichen Einschätzung lag ich - wie der Thread zeigte - ganz richtig. Wenn jemand - auch nach Hinweis darauf - nicht die grundsätzliche Funktionsweise des Paketfilters unter Linux versteht, dann zeigt das einen Mangel an Kompetenz in diesem Bereich. Konkret meine ich damit z. B. Dein mangelhaftes Verständnis der Ketten von iptables, wie z. B. hier in diesem Schema zu sehen:

Bild

Die Tatsache ändert sich auch nicht dadurch, dass Du sagst, dass Du die ufw für mehrere Server betreust. Offensichtlich hast Du nur ein geringes Verständnis von dem, was Du da tust.

Es ist für mich ok, wenn Du sagst: Habe ich kein Bock drauf. Ist mir zu kompliziert. Habe ich keine Zeit für.

Das ist jedoch nicht, wie Du es schreibst, eine "Fehlersuche", sondern ganz normaler Wissens-/Kompetenzaufbau. Und für Menschen mit der Einstellung gebe ich meine Zeit nicht her.

Viele Grüße,
h.

Antworten