Acesta este un rutare problemă. iptables nu rutează, dar rutarea poate fi afectată de adresele pe care le poate modifica și de aceea iptables este adesea considerat eronat că face rutarea. Din acest motiv iptables nu poate fi cel soluție pentru a rezolva problema (dar uneori poate face parte dintr-o astfel de soluție).
Mai mult, orice încercare de a modifica a răspuns pachetul care utilizează NAT-ul Netfilter/iptables este ignorat: the nat tabelul este declanșat doar pentru primul pachet al unui flux: nu pentru un răspuns: iptables -t nat -A OUTPUT -p tcp --match multiport --sports 8443,8080 -j DNAT --to 172.24.248.201
nu se va potrivi niciodată. Și dacă ar putea fi făcut să se potrivească, acest lucru nu ar funcționa, deoarece destinația răspunsului trebuie să fie sursa interogării inițiale văzută de serverul real: adresa IP reală a clientului la distanță, nu L3 LB.
Mai jos este o metodă simplă de a face acest lucru corect pe serverul real: cu rutarea politicii.
În această problemă specifică și răspuns, voi presupune Nucleul Linux >= 4.17 pentru „Extinde suportul pentru meciul cu regulile fib pentru a include sport, dport și ip proto match”, ceea ce evită utilizarea complexă a iptables pentru a marca pachetele (dar oricum ar necesita rutarea politicii).
Trebuie să vă asigurați că porturile dedicate ale serverului real nu se pot suprapune cu intervalul de porturi dinamice ale serverului real (utilizat atunci când serverul este un client, cum ar fi pentru interogări DNS sau upgrade de sistem):
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
Asigurați-vă că portul inferior este deasupra celui mai înalt port al serverului real utilizat pentru un serviciu. Aici: 32768 > 8443 este suficient de bun.
Adăugați un tabel de rutare pentru trafic specific destinat să utilizeze L3 LB ca gateway. Tabelul 248201 este o valoare aleasă în mod arbitrar. Presupun că interfața serverului real este numită eth0, va rog adaptati:
IP route add default prin 172.24.248.201 dev eth0 table 248201
Adăugați selectoare: unul pe interval de port. Ar putea fi o singură gamă largă (atâta timp cât nu există interacțiune cu porturile dinamice, nu contează) sau reguli X pentru porturi distincte X. Pentru un singur interval:
regulă ip adăugați iif lo iproto tcp sport 8000-8443 căutare 248201
Unde dacă iată
este sintaxa specială pentru traficul de ieșire inițiat local și nu este cu adevărat despre uite interfata.
Acum, tot traficul de retur intenționat va fi direcționat folosind L3 LB ca gateway. Orice alt trafic va folosi gateway-ul implicit obișnuit dacă este necesar.
nu cred SRPF ar trebui să fie o problemă dacă este activată, cu excepția cazului în care gateway-ul implicit obișnuit al serverului utilizează o altă interfață. Dacă aceasta ar fi o problemă, poate fi setați în modul Loose in schimb.
De făcut numai dacă nu funcționează fără el (și chiar și atunci, eth0 poate fi suficient în loc de toate de mai jos):
sysctl -w net.ipv4.conf.all.rp_filter=2