Puncte:1

Redirecționare IP cu IPTables pentru modul lvs nat

drapel vn

Învăț despre balansoarele de încărcare L3 și acum lucrez la modul NAT keepalived. Fluxul de pachete ar trebui să fie Client ------> L3(lvs DNAT)------> servere reale și fluxul de returnare ar trebui să fie exact opus fluxului cererii. Dar DNAT-ul lvs schimbă numai NAT-ul de destinație, înseamnă că numai IP-ul de destinație al pachetului este schimbat, adică) [sursă = ip client, destinație = ip server real]. Deci, după ce serverul real procesează cererea îl transmite către gateway-ul implicit în loc de serverul L3 și pachetul este scăpat. Nu vreau să setez serverul L3 ca gateway implicit al serverului real, în schimb am nevoie de o soluție legată de tabelul IP pentru a redirecționa traficul de la serverul real la L3. server când vine vorba de portul 8443 și 8080.

Tabelele IP oferă modalitatea de a redirecționa traficul înainte de procesarea pachetului prin PREROUTING, dar ceea ce vreau este să redirecționeze traficul către L3 după ce serverul procesează cererea. Am încercat cu lanțul OUTPUT încă fără succes sudo iptables -t nat -A OUTPUT -p tcp --match multiport --sports 8443,8080 -j DNAT --to 172.24.248.201

172.24.248.201 este ip-ul serverului L3.

Mulțumesc anticipat

Puncte:1
drapel cl
A.B

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
chellathurai avatar
drapel vn
înseamnă că nu putem seta IP-ul sursă la IP arbitrar, nu? Ai putea explica pe scurt fraza? _Propria adresă IPv4 a L3 LB nu apare în fluxul de răspunsuri așteptat,_
A.B avatar
drapel cl
A.B
Iată un exemplu. Dacă un client la distanță cu adresa 192.0.2.2 se conectează la 172.24.248.201:443 care redirecționează folosind NAT către (de exemplu, nu am informațiile) un server real cu adresa și portul 172.24.248.202:8443, atunci acest server real poate Nu trimiteți înapoi traficul la 172.24.248.201 : trebuie trimis înapoi la 192.0.2.2 : adresa 172.24.248.201 nu apare nicăieri. În același timp, văd că o parte din descrierea mea a fost incorectă. regula DNAT nu se va potrivi niciodată deoarece în răspunsul OUTPUT fluxul nu este în stare NEW. Va trebui să editez începutul răspunsului meu. Soluția nu se schimbă.
A.B avatar
drapel cl
A.B
răspuns modificat (soluția în sine nu se schimbă).
chellathurai avatar
drapel vn
Rutarea politicilor rezolvă problema.
chellathurai avatar
drapel vn
**NAT este ignorat** Lanțul OUTPUT pare să funcționeze. O confirm folosind LOG, dar NAT-ul făcut în OUTPUT pare să nu aibă efect.
A.B avatar
drapel cl
A.B
Răspunsul meu nu folosește NAT. Răspunsul meu nu folosește iptables. Răspunsul meu se bazează pe 2 comenzi: una care începe cu `ip route` una care începe cu `ip rule`. Unde s-au făcut aceste acțiuni?
chellathurai avatar
drapel vn
Am încercat lanțul NAT OUPUT înainte de a posta aici, asta este ceea ce am menționat. Îmi puteți oferi aceeași soluție pentru freebsd folosind ipfw?
A.B avatar
drapel cl
A.B
Nu, nu cunosc FreeBSD. Întrebarea a fost etichetată *iptables* ceea ce implica Linux (și încercarea de iptables a fost făcută și pe Linux)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.