Un server conectat simultan la două rețele poate avea nevoie ca fiecare interfață să folosească propriul gateway și propriile rute, fără ca traficul să ajungă accidental în cealaltă rețea. Poți rezolva situația cu policy-based routing, dar când vrei domenii L3 clare și ușor de administrat, Linux oferă VRF — Virtual Routing and Forwarding.
Un VRF Linux este asociat unei tabele FIB separate. Interfețele introduse în acel VRF folosesc tabelul respectiv, iar aplicațiile pot fi legate explicit de domeniul de rutare. Este VRF-lite: separă rutarea Layer 3, nu procesele, filesystem-ul sau întregul network stack ca un network namespace.
Construiește două domenii de rutare
Vom folosi:
VRF blue → tabela 100
enp1s0 → 192.0.2.10/24
gateway → 192.0.2.1
VRF red → tabela 200
enp2s0 → 198.51.100.10/24
gateway → 198.51.100.1Înainte să modifici un server remote, păstrează acces prin consolă sau printr-o a treia interfață de management. Mutarea interfeței SSH active într-un VRF poate întrerupe sesiunea.
Salvează starea inițială:
ip -br address
ip route show table all
ip rule showCreează VRF-urile:
sudo ip link add vrf-blue type vrf table 100
sudo ip link add vrf-red type vrf table 200
sudo ip link set vrf-blue up
sudo ip link set vrf-red upVerifică:
ip vrf show
ip -d link show type vrfKernelul creează automat, la primul VRF, o regulă l3mdev pentru IPv4 și IPv6, cu prioritatea implicită 1000. Aceasta direcționează lookup-ul către tabela asociată VRF-ului.
Mută interfețele în VRF
Adaugă fiecare interfață în domeniul său:
sudo ip link set enp1s0 master vrf-blue
sudo ip link set enp2s0 master vrf-redVerifică:
ip link show master vrf-blue
ip link show master vrf-redUn detaliu important: când o interfață este „enslaved” într-un VRF, rutele locale și connected sunt mutate automat în tabela VRF. Alte rute care depind de interfața respectivă pot fi eliminate și trebuie adăugate din nou.
Configurează gateway-urile:
sudo ip route add table 100 \
default via 192.0.2.1 dev enp1s0
sudo ip route add table 200 \
default via 198.51.100.1 dev enp2s0Inspectează separat:
ip route show table 100
ip route show table 200
ip rule showAcum două default routes pot exista simultan fără să concureze în tabela main.
Testează fiecare domeniu independent
ip vrf exec permite rularea unei aplicații în contextul unui anumit VRF:
sudo ip vrf exec vrf-blue ping -c 3 1.1.1.1
sudo ip vrf exec vrf-red ping -c 3 1.1.1.1Pentru HTTP:
sudo ip vrf exec vrf-blue \
curl https://example.com
sudo ip vrf exec vrf-red \
curl https://example.comPoți confirma asocierea proceselor:
ip vrf pids vrf-blue
ip vrf identify PIDip vrf exec configurează socket-urile procesului pentru VRF și necesită cgroup v2 împreună cu suportul kernel CGROUP/BPF; executarea obișnuită se face ca root.
Pentru aplicații scrise special pentru VRF, socket-ul poate fi legat direct de dispozitiv prin SO_BINDTODEVICE.
Atenție la serviciile care ascultă pe toate VRF-urile
Implicit, un socket TCP nelegat de un VRF din domeniul default nu acceptă automat conexiunile sosite prin celelalte VRF-uri.
Există:
sysctl net.ipv4.tcp_l3mdev_accept
sysctl net.ipv4.udp_l3mdev_acceptActivarea lor poate permite serviciilor din VRF-ul default să deservească și celelalte domenii, dar schimbă modelul de izolare. Nu seta valorile pe 1 doar pentru a „face serverul să meargă”; decide dacă serviciul trebuie să existe global sau separat pentru fiecare VRF.
Fă configurația persistentă cu NetworkManager
Comenzile ip dispar după reboot. Cu NetworkManager:
sudo nmcli connection add \
type vrf ifname vrf-blue \
con-name vrf-blue table 100 \
ipv4.method disabled ipv6.method disabledAdaugă interfața:
sudo nmcli connection add \
type ethernet \
con-name blue-uplink \
ifname enp1s0 \
master vrf-blue \
ipv4.method manual \
ipv4.addresses 192.0.2.10/24 \
ipv4.gateway 192.0.2.1Repetă cu tabela 200 pentru vrf-red. NetworkManager suportă nativ tipul vrf, iar rutele conexiunii slave sunt asociate automat tabelei VRF respective.
După reboot verifică din nou:
ip vrf show
ip route show table 100
ip route show table 200
ip rule showVRF este alegerea potrivită când ai nevoie de rutare L3 separată, dar nu de izolarea completă oferită de namespace-uri sau VM-uri. Pentru management, multi-tenancy de rețea, două uplink-uri independente sau servicii care trebuie să folosească gateway-uri diferite, rezultatul este mult mai clar decât acumularea unor zeci de reguli PBR.
Surse folosite
Linux Kernel Documentation — Virtual Routing and Forwarding, l3mdev, tabele VRF și comportamentul interfețelor.
Linux iproute2 — ip-vrf, ip vrf exec, identificarea proceselor și cerințele cgroup/BPF.
NetworkManager Reference Manual — conexiuni de tip VRF și proprietatea vrf.table.
Red Hat Documentation — configurarea persistentă VRF și asocierea interfețelor prin nmcli.
