Rutarea Linux obișnuită alege traseul în principal după adresa de destinație. Policy-based routing, prescurtat PBR, adaugă reguli prin care traseul poate fi ales și după IP-ul sursă, interfața de intrare, marcajul firewall sau alte caracteristici ale traficului.
Este utilă pe un server cu două conexiuni la internet, mai multe adrese publice, tuneluri VPN ori rețele separate. Un caz clasic: cererea intră prin ISP1, dar răspunsul pleacă prin ISP2 deoarece acesta are ruta implicită principală. Rezultatul poate fi o conexiune asimetrică pe care providerul, firewall-ul sau sistemul remote o respinge.
Topologia folosită în exemplu
Serverul are două interfețe:
eth0: 192.0.2.10/24
Gateway ISP1: 192.0.2.1
eth1: 198.51.100.10/24
Gateway ISP2: 198.51.100.1
Înainte să modifici rutarea pe un server remote, păstrează accesul prin consolă și salvează configurația existentă:
ip -br address
ip route show table all
ip rule show
ip route gestionează tabelele de rutare ale kernelului, iar ip rule controlează Routing Policy Database, lista de reguli care decide ce tabel trebuie consultat.
Creează două tabele de rutare
Deschide fișierul:
sudo nano /etc/iproute2/rt_tables
Adaugă la final:
100 isp1
200 isp2
Numerele identifică tabelele, iar numele simplifică comenzile. Nu folosi valorile rezervate pentru tabelele interne local, main și default.
Adaugă în fiecare tabel ruta rețelei direct conectate și gateway-ul corespunzător:
sudo ip route add 192.0.2.0/24 \
dev eth0 src 192.0.2.10 table isp1
sudo ip route add default \
via 192.0.2.1 dev eth0 table isp1
Pentru al doilea provider:
sudo ip route add 198.51.100.0/24 \
dev eth1 src 198.51.100.10 table isp2
sudo ip route add default \
via 198.51.100.1 dev eth1 table isp2
Ruta rețelei locale este necesară pentru ca gateway-ul să fie accesibil în tabelul respectiv. Fiecare tabel conține acum un traseu complet prin propriul provider.
Adaugă regulile după IP-ul sursă
Configurează traficul care pleacă de la fiecare adresă să consulte tabelul corespunzător:
sudo ip rule add priority 100 \
from 192.0.2.10/32 table isp1
sudo ip rule add priority 110 \
from 198.51.100.10/32 table isp2
Verifică:
ip rule show
Regulile sunt evaluate în ordinea priorității; numărul mai mic este verificat primul. Linux păstrează implicit reguli pentru tabelul local, apoi pentru main și default, motiv pentru care prioritățile custom trebuie alese deliberat.
Nu adăuga două reguli cu aceeași prioritate. Configurația devine greu de urmărit, iar ordinea reală poate să nu fie cea presupusă.
Testează fără să generezi trafic real
Comanda ip route get arată traseul ales de kernel:
ip route get 1.1.1.1 from 192.0.2.10
Rezultatul trebuie să indice:
via 192.0.2.1 dev eth0
Pentru a doua adresă:
ip route get 1.1.1.1 from 198.51.100.10
Ar trebui să apară:
via 198.51.100.1 dev eth1
Testează apoi fiecare interfață:
ping -I 192.0.2.10 -c 3 1.1.1.1
ping -I 198.51.100.10 -c 3 1.1.1.1
Pentru investigații mai precise:
sudo tcpdump -ni eth0
sudo tcpdump -ni eth1
Verifică reverse path filtering
Pe serverele multihomed, filtrarea strictă a traseului invers poate respinge trafic legitim dacă răspunsul ar fi căutat prin altă interfață:
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter
Valoarea 1 aplică validare strictă, iar 2 folosește modul loose. Nu dezactiva sau relaxa global protecția fără testare; modificarea trebuie făcută numai pe interfețele unde arhitectura asimetrică o cere. Documentația kernelului explică modul în care rp_filter validează ruta sursei și impactul său asupra configurațiilor complexe.
Fă regulile persistente
Comenzile ip dispar după restart. Dacă sistemul folosește NetworkManager, fiecare profil poate primi propriul tabel și propria regulă:
sudo nmcli connection modify ISP1 \
ipv4.route-table 100 \
ipv4.routing-rules \
"priority 100 from 192.0.2.10/32 table 100"
Pentru ISP2:
sudo nmcli connection modify ISP2 \
ipv4.route-table 200 \
ipv4.routing-rules \
"priority 110 from 198.51.100.10/32 table 200"
NetworkManager cere o prioritate fixă pentru fiecare regulă și folosește numărul tabelului în configurația persistentă.
Nu reactiva profilurile remote până când configurația nu este verificată și nu ai acces alternativ. După aplicare, repetă ip rule show, ip route show table isp1, ip route show table isp2 și testele ip route get.
Policy-based routing funcționează corect când fiecare adresă sursă folosește gateway-ul potrivit, răspunsurile păstrează traseul așteptat, iar regulile rămân clare și documentate.
Surse folosite
Linux manual pages — ip-rule și Routing Policy Database.
Linux manual pages — ip-route și tabelele de rutare ale kernelului.
Linux Kernel Documentation — policy routing și parametrii IP.
NetworkManager Reference Manual — ipv4.route-table și ipv4.routing-rules.

















































