Vraag Hoe de poort doorsturen van de ene ip naar de andere ip in hetzelfde netwerk?


Ik zou graag wat doen NAT in iptables. Zodat alle pakketten naar toe komen 192.168.12.87 en poort 80 wordt doorgestuurd naar 192.168.12.77 haven 80.

Hoe dit te doen met iptables?

Of

Andere manieren om hetzelfde te bereiken?


62
2018-04-03 17:58


oorsprong


@Matthewlfe, Om wat voor reden dan ook, moet ik alle apache-verzoeken doorsturen van (192.168.12.87) naar (192.168.12.77). - sat
@Matthewlfe, ik heb twee productieservers. Eén is verbonden met een openbaar statisch IP-adres. Vanwege enkele connectiviteitsproblemen, kan ik geen verbinding maken met DB en andere systemen 192.168.12.87. Dus ik moet alle verzoeken doorsturen naar 192.168.12.77. - sat
@lain, ik ben niet bekend met iptables. En ik heb enkele voorbeelden gezien. Maar het lijkt twee ethernet te vereisen. Link: revsys.com/writings/quicktips/nat.html - sat
U kunt ook de proxymodus in uw webserverconfiguratie gebruiken om verzoeken naar 192.168.12.77 te verzenden vanaf 192.168.12.87 (als uw webserver dit ondersteunt) - krisFR
askapache.com/htaccess/... - dmourati


antwoorden:


Deze regels zouden moeten werken, ervan uitgaande dat iptables wordt uitgevoerd op de server 192.168.12.87 :

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F
iptables -t nat -F
iptables -X

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87

Je moet binnenkomend verkeer op poort 80 DNAT, maar je zult ook het verkeer terug moeten SNATEN.


Alternatieve (en beste benadering IMHO):

Afhankelijk van wat uw webserver is (Apache, NGinx) moet u een HTTP-proxy overwegen op uw front-endserver (192.168.12.87):


62
2018-04-03 21:46



Werkt zo lang als ufw is uitgeschakeld, hoewel de poort in ufw toestaat, maar als ufw is ingeschakeld, werkt dit doorstuur-spul niet, enig idee? - Sudhir N
Geweldige vraag met goed antwoord. Een andere use-case waar dit handig voor is, is als je tijdelijk al het verkeer dat naar een dienst komt, zeg inktvis, naar een andere ip / poort moet omleiden om wat onderhoud aan de originele service uit te voeren zonder alle clients opnieuw te configureren! Heel handig! - PF4Public
"maar je zult ook het verkeer terug moeten SNATEN." -> Je hebt mijn dag bewaard. Dank je - obayhan
Deze oplossing werkt niet voor mij. Ik moet van eth0 doorsturen naar een virtueel netwerk (virb0) dat wordt gebruikt door een KVM-gast. Ik heb geprobeerd de -i en -o opties toe te voegen, maar het is niet toegestaan ​​om te prerouting. Suggesties? - lostiniceland


De reden een schijnbaar voor de hand liggend iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 zal niet werken is hoe de retourpakketten worden gerouteerd.

U kunt regels instellen die ervoor zorgen dat de pakketten die naar 192.168.12.87 worden verzonden, gewoon NATED zijn naar 192.168.12.77, maar 192.168.12.77 verzendt de antwoorden dan rechtstreeks terug naar de client. Die antwoorden zullen niet door de host gaan waar uw iptables-regel NAT doet, vandaar dat de pakketten in één richting worden vertaald, maar pakketten in de andere richting niet.

Er zijn drie manieren om dit probleem op te lossen.

  1. Op de eerste host niet alleen DNAT doen, maar ook SNAT doen zodat retourverkeer via de eerste host wordt teruggestuurd. De regel zou er ongeveer zo uit kunnen zien iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
  2. Laat u inspireren door DSR-taakverdeling en DNAT de pakketten op Ethernet-laag in plaats van op IP-laag. Door de MAC-bestemming van de pakketten te vervangen door de MAC van 192.168.12.77 en deze op het Ethernet te verzenden zonder de IP-laag aan te raken, kan 192.168.12.77 192.168.12.87 hebben geconfigureerd op een dummy-interface en dus de TCP-verbinding kunnen beëindigen met de server IP bekend bij de klant.
  3. Gebruik de naïeve (maar niet werkende) oplossing op de eerste host. Behandel dan de retourpakketten op de tweede host door een SNAT te doen op het retourverkeer. Een regel zou eruit kunnen zien iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

Elk van deze drie oplossingen heeft nadelen, dus u moet goed overwegen of u deze specifieke verzending echt moet doen.

  1. Het gebruik van SNAT verliest het client-IP, dus host nummer 2 zal denken dat alle verbindingen afkomstig zijn van 192.168.12.87. Daarnaast gebruik je voor alle antwoordpakketten bandbreedte via hostnummer 1, wat een directere route zou zijn met de andere benaderingen.
  2. De DSR-benadering zal alle andere communicatie tussen de twee knooppunten verbreken. De DSR-benadering is eigenlijk alleen geschikt als het serveradres niet het primaire IP-adres van een van de hosts is. Elke host moet een primaire IP hebben, wat niet het DSR IP is.
  3. Het gebruik van verbindingsregistratie op één host om in één richting te vertalen en het volgen van verbindingen op een andere host om in de andere richting te vertalen is gewoon lelijk en er zijn verschillende manieren om het te verbreken. Als poortnummers bijvoorbeeld door NAT op beide hosts worden gewijzigd, is er geen manier om deze te reconstrueren. Het is ook geen gegeven dat het volgen van verbindingen correct zal werken, als het eerste pakket dat het ziet een SYN-ACK is in plaats van een ACK.

Van de drie benaderingen denk ik dat de eerste de oplossing is, die waarschijnlijk zal werken. Dus als u de IP-adressen van de client niet hoeft te weten, is dat degene die ik zou aanbevelen.

U kunt er ook voor kiezen NAT helemaal te vergeten en niet proberen het probleem op MAC- of IP-laag op te lossen. U kunt helemaal naar de HTTP-laag gaan en daar naar een oplossing zoeken. In dat geval is de oplossing die u zult vinden een HTTP-proxy. Als u een HTTP-proxy installeert op 192.168.12.87 en deze op de juiste manier configureert, kunt u deze laten doorsturen naar 192.168.12.77 en de antwoorden doorsturen. Bovendien kan het een X-Forwarded-For-header invoegen met behoud van het oorspronkelijke client-IP. De server op 192.168.12.77 moet vervolgens worden geconfigureerd om de X-Forwarded-For-header te vertrouwen van 192.168.12.87.


26
2018-04-03 21:44



Ik ben verrast -j MASQUERADE wordt hier niet genoemd; is het niet de gebruikelijke aanpak met DNAT? - remram
@remram heb ik genoemd SNAT in plaats van MASQUERADE, want dat is wat de documentatie zegt. De exacte bewoording in de documentatie is: It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. - kasperd