Am întâlnit o problemă dificilă cu NAT sursă atunci când folosim mai multe VRF pe un router bazat pe Debian. Este puțin complex de explicat, așa că voi încerca să fiu clar, dar nu va fi scurt, îmi pare rău pentru asta. Problema ar trebui să fie ușor de reprodus, totuși.
Pentru a izola partea „management” a routerului (ssh și alte servicii) de jobul său de router (pachete de rutare și NATing), am încercat să configurez VRF „mgmt” în VRF implicit (mai ușor de tratat cu prizele de servicii) și cel de rutare într-un VRF numit „firewall”.
Diagrama poate fi rezumată astfel:
Diagrama rețelei
Rețeaua de „management” este 192.168.100.0/24 și este direcționată de un switch L3 care are un L3 cu VRF „firewall” al routerului prin rețeaua 10.254.5.0/24. A treia interfață de router este cea „internet”, iar pachetele care trec prin ea sunt sursă NAT. Această configurare funcționează destul de bine pentru tot ce se află în subrețeaua de administrare, cu excepția pachetelor proprii ale routerului, cauza conntrack.
Despre regulile iptables:
# Filtru tabel
# lanț INPUT
-A INPUT -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
(unele reguli de INPUT, pentru ssh, snmp etc.)
-A INTRARE -j CĂDERARE
# lanț înainte
-A FORWARD -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -o eth2 -j ACCEPT
-A ÎNTÂMPRE -j PĂDURA
# Tabelul nat
# lanț POSTOUTING
-A POSTROUTING -o eth2 -j SNAT --to-source 192.168.122.100
Despre tabelul de rutare:
# VRF implicit
implicit prin 192.168.100.1 dev eth0 proto metric static 20
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.90
# firewall VRF
implicit prin 192.168.122.1 dev eth2 proto metric static 20
10.254.5.0/24 dev eth1 proto kernel scope link src 10.254.5.2
192.168.100.0/24 proto bgp metric 20 nexthop prin 10.254.5.10 dev eth1 greutate 1
192.168.122.0/24 dev eth2 proto kernel scope link src 192.168.122.100
Deci, atunci când un pachet din VRF implicit încearcă să acceseze internetul, iese din eth0, este direcționat de comutatorul L3, intră în firewall-ul VRF prin eth1 și este direcționat și NAT prin eth2. Deoarece urmăresc conexiunile INPUT și FORWARD, conntrack este puțin confuz când pachetul revine și nu poate ști ce să facă cu pachetul.
Am reușit să rezolv acest lucru pentru ICMP și UDP utilizând zona conntrack în tabelul brut
# Tabel brut
# lanț PRERUTARE
-A PREROUTING -i eth0 -j CT --zona 5
# lanț OUTPUT
-A IEȘIRE -o eth0 -j CT --zona 5
Cu aceste reguli, pachetele care provin de la router și trec eth0 sunt etichetate zona 5 iar când intră pachetele eth0 sunt de asemenea etichetate zona 5.
Cu un ping la 8.8.8.8, arată așa (cu comanda conttrack -E):
[NOU] icmp 1 30 src=192.168.100.90 dst=8.8.8.8 type=8 code=0 id=1999 [UNREPLIED] src=8.8.8.8 dst=192.168.100.90 type=0 code=0 zone id=5999
[NOU] icmp 1 30 src=192.168.100.90 dst=8.8.8.8 type=8 code=0 id=1999 [NERĂSPUNS] src=8.8.8.8 dst=192.168.122.100 type=0 code=0 id=1999
[ACTUALIZARE] icmp 1 30 src=192.168.100.90 dst=8.8.8.8 type=8 code=0 id=1999 src=8.8.8.8 dst=192.168.122.100 type=0 code=0 id=1999
[UPDATE] icmp 1 30 src=192.168.100.90 dst=8.8.8.8 type=8 code=0 id=1999 src=8.8.8.8 dst=192.168.100.90 type=0 code=0 id=1999 zone=5
Putem vedea aici primul NOU conexiunea este creată atunci când pachetul trece eth0 cu zona=5 etichetă, apoi o nouă când intră în firewall-ul VRF et1 fără etichetă. Când vine răspunsul, a doua conexiune este actualizată mai întâi (din moment ce este cea care se confruntă cu internet) și apoi prima.
Acest lucru funcționează și cu UDP, de exemplu cu o interogare DNS la 8.8.8.8
[NOU] udp 17 30 src=192.168.100.90 dst=8.8.8.8 sport=53369 dport=53 [UNREPLIED] src=8.8.8.8 dst=192.168.100.90 sport=53 dport=5369 dport=5369
[NOU] udp 17 30 src=192.168.100.90 dst=8.8.8.8 sport=53369 dport=53 [UNREPLIED] src=8.8.8.8 dst=192.168.122.100 sport=53369 dport=53369
[ACTUALIZARE] udp 17 30 src=192.168.100.90 dst=8.8.8.8 sport=53369 dport=53 src=8.8.8.8 dst=192.168.122.100 sport=53 dport=53369
[ACTUALIZARE] udp 17 30 src=192.168.100.90 dst=8.8.8.8 sport=53369 dport=53 src=8.8.8.8 dst=192.168.100.90 sport=53 dport=53369 zone=5
Dar cu TCP nu merge. O interogare telnet către portul 80 172.16.10.10 arată astfel:
[NOU] tcp 6 120 SYN_SENT src=192.168.100.90 dst=172.16.10.10 sport=60234 dport=80 [NERĂSPUNS] src=172.16.10.10 dst=192.16.10.10 sport=192.16.10.16port=192.16.0.16port=80.02.
[NOU] tcp 6 120 SYN_SENT src=192.168.100.90 dst=172.16.10.10 sport=60234 dport=80 [UNREPLIED] src=172.16.10.10 dst=192.16.10.10 sport=192.16.180.
[ACTUALIZARE] tcp 6 58 SYN_RECV src=192.168.100.90 dst=172.16.10.10 sport=60234 dport=80 src=172.16.10.10 dst=192.168.120.120.10.10 sport=80.10.10
[ACTUALIZARE] tcp 6 57 SYN_RECV src=192.168.100.90 dst=172.16.10.10 sport=60234 dport=80 src=172.16.10.10 dst=192.168.120.120.10.10 sport=80.
(Ultima linie se repetă de mai multe ori)
Dacă eu tcpdump et2 raspunsul acolo:
IP 192.168.122.100.60236 > 172.16.10.10.80: Flags [S], seq 4203590660, win 62720, opțiuni [mss 1460,sackOK,TS val 15118 ec,rwscale 15118,rwscale 17nop,]rwscale 172880
IP 172.16.10.10.80 > 192.168.122.100.60236: steaguri [S.], seq 3672808466, ack 4203590661, win 65535, opțiuni [mss 1430, 1430, val 818182, TS6181821, TS618181821
IP 192.168.122.100.60236 > 172.16.10.10.80: Flags [S], seq 4203590660, win 62720, opțiuni [mss 1460,sackOK,TS val 15118 ec,rwscale 7nop,rwscale 7nop,rwscale 7nop]
IP 172.16.10.10.80 > 192.168.122.100.60236: steaguri [S.], seq 3672808466, ack 4203590661, win 65535, opțiuni [mss 1430, 1430, val 6180820, TS6181820, TS61818247]
Dar, deoarece SIN ACK nu este niciodată confirmat, routerul continuă să trimită SIN nou.
Acum, dacă tcpdump et1:
IP 192.168.100.90.60238 > 172.16.10.10.80: Steaguri [S], seq 3124513394, win 62720, opțiuni [mss 1460,sackOK,TS val 1511928806,nopcr]wscale 07 ecr]
IP 192.168.100.90.60238 > 172.16.10.10.80: Steaguri [S], seq 3124513394, win 62720, opțiuni [mss 1460,sackOK,TS val 1511929802,nopc,wscale 37nopc]
IP 192.168.100.90.60238 > 172.16.10.10.80: Flags [S], seq 3124513394, win 62720, opțiuni [mss 1460,sackOK,TS val 1511931803,nopc]wscale 097 epc]
Putem vedea că răspunsul nu este niciodată trimis înapoi la 192.168.100.90.
Dacă am dezactivat urmărirea conexiunii și am permis totul în iptables, funcționează. Deci, cred că conntrack are probleme cu conexiunile TCP gestionate de la sine în altă zonă când sunt NAT? Dacă ceva nu este clar, voi răspunde cu plăcere la orice întrebări despre asta.
