Am un server Proxmox Linux, care este capabil să trimită și să primească pachete către gazdele din rețeaua locală, dar nu va procesa pachete de la gateway. Acest lucru face ca traficul de internet să eșueze, așa că nu pot rula apt pentru a actualiza pachetele. Toate protocoalele par a fi afectate.
VM-uri care rulează pe server poate sa accesează bine gateway-ul.
Fișierul meu /etc/network/interfaces conține:
auto lo
iface lo inet loopback
iface enp10s0 inet manual
auto vmbr0
iface vmbr0 inet static
adresa 10.0.1.200/24
gateway 10.0.1.1
bridge_ports enp10s0
bridge_stp off
bridge_fd 0
auto wlp7s0
iface wlp7s0 inet static
hostapd /etc/hostapd/hostapd.conf
adresa 10.0.2.1
mască de rețea 255.255.255.0
auto vmbr1
iface vmbr1 inet static
adresa 10.1.2.1
mască de rețea 255.255.255.0
bridge_ports niciunul
bridge-stp off
punte-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.1.2.0/24' -o wlp7s0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.1.2.0/24' -o wlp7s0 -j MASQUERADE
wlp7s0 și vmbr1 sunt NAT pentru a permite unei VM să acceseze dispozitive IOT fără fir care nu ar trebui să aibă acces la rețeaua generală/internet.
Tabelul meu de rute:
$ traseu ip
implicit prin 10.0.1.200 dev vmbr0 metric 100
10.0.1.0/24 dev vmbr0 proto kernel scope link src 10.0.1.200
10.0.2.0/24 dev wlp7s0 proto kernel scope link src 10.0.2.1
10.1.2.0/24 dev vmbr1 proto kernel scope link src 10.1.2.1
După câteva citite, am încercat să schimb rp_filter, dar schimbarea valorii de la 2 la 0 nu a ajutat. Setările implicite (cu interfețele VM eliminate):
$ sysctl -a | grep \.rp_filter
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.enp10s0.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.vmbr0.rp_filter = 0
net.ipv4.conf.vmbr1.rp_filter = 0
net.ipv4.conf.wlp7s0.rp_filter = 0
ip_forward este setat:
$ cat /proc/sys/net/ipv4/ip_forward
1
Am verificat prin tcpdump că sunt primite pachete de la gateway atunci când încerc să fac ping de la server la gateway sau de la server la gateway. Acest exemplu folosește ping:
# tcpdump -n -i vmbr0 gazdă 10.0.1.1 și icmp
tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
ascultare pe vmbr0, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
22:42:37.136341 IP 10.0.1.200 > 10.0.1.1: Solicitare ecou ICMP, id 22073, secv 1, lungime 64
22:42:37.136478 IP 10.0.1.1 > 10.0.1.200: răspuns ecou ICMP, id 22073, seq 1, lungime 64
22:42:38.142240 IP 10.0.1.200 > 10.0.1.1: Solicitare ecou ICMP, id 22073, secv. 2, lungime 64
22:42:38.142429 IP 10.0.1.1 > 10.0.1.200: răspuns ecou ICMP, id 22073, secv 2, lungime 64
Ieșirea lui ping -v este pur și simplu goală:
$ ping -v 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) octeți de date.
^C
--- 10.0.1.1 statistici ping ---
22 de pachete transmise, 0 primite, 100% pierdere de pachete, timp 511 ms
Singura intrare în tabelele ip este NAT:
# iptables-save -c
# Generat de iptables-save v1.8.2 pe sâmb. 29 ianuarie 22:45:46 2022
*brut
:ACCEPTAREA PRE-ROUTARE [1828405583:1847667077335]
: ACCEPT IEȘIRE [10762322:981310704]
COMMIT
# Finalizat sâmb. 29 ianuarie 22:45:46 2022
# Generat de iptables-save v1.8.2 pe sâmb. 29 ianuarie 22:45:46 2022
*filtru
:INPUT ACCEPT [10597558:1212589593]
:ACCEPTAȚI înainte [1782904005:1841102268241]
: ACCEPT IEȘIRE [10762351:981313827]
COMMIT
# Finalizat sâmb. 29 ianuarie 22:45:46 2022
# Generat de iptables-save v1.8.2 pe sâmb. 29 ianuarie 22:45:46 2022
*nat
:ACCEPTAREA PREROUTARE [29808561:4940456833]
:INPUT ACCEPT [2456738:231340403]
: ACCEPT IEȘIRE [1168080:75403202]
: POSTROUTING ACCEPT [2829337:181352732]
[190:11400] -A POSTROUTING -s 10.1.2.0/24 -o wlp7s0 -j MASQUERADE
COMMIT
# Finalizat sâmb. 29 ianuarie 22:45:46 2022
