Când mașina internă inițiază o conexiune de ieșire, IP-ul său este
NAT este adresa principală a porții, nu adresa pe care încerc să o fac
da-o.
Acest lucru ar trebui rezolvat cu:
iptables -t nat -I POSTROUTING 1 -s 10.125.0.2 -o eth0 -j SNAT --to-source <FORWARD_IP>
Este adăugat în față, așa că se va declanșa mai întâi, va detecta că pachetul provine din acest sistem și îl va traduce în IP-ul specificat, în loc să aleagă o adresă din interfață.
Când se primesc conexiuni, acestea par să provină de la
IP-ul local al gateway-ului, nu IP-ul original (ar trebui să existe o cale de ocolire
că, deoarece aceasta este gateway-ul implicit).
Această problemă este legată de următoarea regulă SNAT:
iptables -t nat -A POSTROUTING -j MASQUERADE
Este cale prea lat. Tu faci SNAT Tot în fiecare direcție, care nu este eficientă și nici sigură. Se potrivește cu toate, inclusiv cu pachetele dvs. DNATed. Ele sunt mai întâi traduse de destinație în adresă privată, apoi sursa lor este tradusă prin această regulă în adresă selectată dintr-o interfață privată unde este atribuită adresa 10.x.x.x.
Bănuiesc că încercați să acoperiți toate interfețele publice și toate rețelele private cu o singură regulă. Deși există liste de adrese în Linux (seturi de IP), nu există liste de interfețe, așa că nu este posibil să faceți acest lucru corect doar cu o singură regulă.
Filtrați-l cu macar adresa sursei (de ex. care adrese către sursă-traducere):
iptables -t nat -A POSTROUTING -s 10.125.0.0/24 -j MASQUERADE
Dacă aveți mai multe rețele private, adăugați mai multe reguli de acest fel.
Cred că este mai bine să creați o regulă individuală pentru fiecare interfață publică, astfel încât pachetele care trec prin interfața privată nu ar putea niciodată să fie traduse la sursă, indiferent de adresa sursă pe care o au, de ex. iptables -t nat -A POSTROUTING -s 10.125.0.0/24 -o eth0 -j MASQUERADE și așa mai departe. În acest fel, pachetele de la 10.x.x.x la 172.x.x.x nu vor fi traduse nici ele, iar serviciile dumneavoastră din ambele rețele își vor vedea IP-ul celuilalt direct, lăsând totuși posibilitatea de a le filtra selectiv în lanțul de filtre FORWARD.
Dacă un serviciu ascultă pe 0.0.0.0 pe gateway, conexiunile sunt activate
acel port nu este redirecționat, ei merg la acel serviciu.
Și, în sfârșit, nu înțeleg pe deplin acest aspect.Am intrebat in comentariu, nu mi-ai raspuns. Ce conexiuni, de unde, care este IP-ul sursă?
Prelucrarea DNAT are loc înainte de decizia de rutare, de aceea lanțul se numește „PREROUTING”. Nu verifică niciodată dacă există un proces local care ascultă pe acel port. Singura modalitate prin care serviciul local are șansa de a răspunde este ca pachetul să treacă lanțul INPUT. Pentru aceasta, codul de rutare trebuie să decidă că este destinat mașinii locale, așa că trebuie să nu fie tradus deloc sau să fie tradus într-o adresă atribuită de acest sistem.
Cu regulile actuale, pachetele trimise din rețelele private către IP-urile publice ar trebui nu fi tradus, pentru că nu vin prin eth0. Deci, acestea urmează să fie deservite de serviciile locale. Dar acest lucru nu depinde de dacă serviciul local rulează sau nu; dacă nu este, veți avea „conexiunea refuzată”.
Dacă aveți nevoie de pachete din LAN la <FORWARD_IP> pentru a fi traduse după aceeași regulă DNAT, renunțați-l -i eth0 Meci:
iptables -A PREROUTING -d <REDACTED_FORWARDING_IP>/32 -j DNAT --to-destination 10.125.0.2
Cu toate acestea, sunt împotriva unei reguli atât de ample. După părerea mea, este mai bine să ai reguli DNAT cât mai stricte, așa că mai bine filtrezi după proto-uri (tcp/udp) și porturile serviciilor pe care le rulezi pe 10.125.0.2. Dacă acesta este un server web, redirecționați numai tcp/80 și tcp/443, astfel: iptables -A PREROUTING -d <REDACTED_FORWARDING_IP>/32 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 10.125.0.2.
Care este problema? Spune, verifici ceva cu ping-ul. Acest rezultat ping va depinde de această stare internă a sistemului, este sistemul pe care îl faceți ping în realitate. Asta creează confuzie. Acesta nu este comportamentul pe care majoritatea administratorilor de sistem se așteaptă să îl vadă atunci când pun ping la un router. Așa că mai bine lăsați ping să primească un răspuns de către gazdă.
