PÁSZTOR György wrote:
Igen, de az OUTPUT chain a routing decision előtt van mind a nat, mind a
mangle táblában.
Eszerint nem:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
Szal ennek működnie kell:
iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 80 -j
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-16 09:13-kor:
PÁSZTOR György wrote:
Igen, de az OUTPUT chain a routing decision előtt van mind a nat, mind a
mangle táblában.
Eszerint nem:
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
Ez a doksi
PÁSZTOR György wrote:
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-16 09:13-kor:
PÁSZTOR György wrote:
Igen, de az OUTPUT chain a routing decision előtt van mind a nat, mind a
mangle táblában.
Eszerint nem:
PÁSZTOR György wrote:
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-16 12:38-kor:
PÁSZTOR György wrote:
Kerestem is most olyan szervert, ahol OUTPUT-ban DNAT-olok, és megy:
# iptables-save -c |grep OUTPUT |grep DNAT
[7771:553506] -A OUTPUT -d 127.0.0.1 -p udp -m udp --dport 53 -j
Hi!
Ferenc Wagner wf...@niif.hu írta 2008-12-16 11:47-kor:
Lásd http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html 3b ábra alatt:
Note that the iptables nat OUTPUT chain is situated after the
routing decision. As commented in the previous section [...], this
is too late for DNAT.
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-16 12:38-kor:
PÁSZTOR György wrote:
Kerestem is most olyan szervert, ahol OUTPUT-ban DNAT-olok, és megy:
# iptables-save -c |grep OUTPUT |grep DNAT
[7771:553506] -A OUTPUT -d 127.0.0.1 -p udp -m udp --dport 53 -j DNAT
PÁSZTOR György pasz...@linux.gyakg.u-szeged.hu writes:
Ferenc Wagner wf...@niif.hu írta 2008-12-16 11:47-kor:
Lásd http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html 3b ábra alatt:
Note that the iptables nat OUTPUT chain is situated after the
routing decision. As commented in the
Gabor HALASZ halas...@freemail.hu writes:
PÁSZTOR György wrote:
Gabor HALASZ halas...@freemail.hu írta 2008-12-16 09:13-kor:
PÁSZTOR György wrote:
Igen, de az OUTPUT chain a routing decision előtt van mind a nat, mind a
mangle táblában.
Eszerint nem:
PÁSZTOR György wrote:
Kerestem is most olyan szervert, ahol OUTPUT-ban DNAT-olok, és megy:
# iptables-save -c |grep OUTPUT |grep DNAT
[7771:553506] -A OUTPUT -d 127.0.0.1 -p udp -m udp --dport 53 -j DNAT
--to-destination 192.168.0.1:1053
[0:0] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp
Kedves Gyur!
iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
MASQUERADE
Sajnos ez sem működik.
Egyébként squid-nek is...
Igen: tcp_outgoing_address; qmil: qmail-remote-outgoingip.diff.gz
Se a qmail-t, se a squid-et nem nagyon szeretném konfigurálgatni,
mert remélem,
linux wrote:
Kedves Gyur!
A postfix-nek emlékeim szerint meg lehet mondani, mely interfészekre
qmail-em van.
http://rno-consultores.com/mail/qmail/qmail-1.03_outgoingips.patch
--
Gabor HALASZ halas...@freemail.hu
_
linux lista -
linux wrote:
Kedves Gyur!
iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
MASQUERADE
Sajnos ez sem működik.
Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul
van a routing decision-on, es onnan meg par lepes a nat table, plane az
postrouting
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-15 16:58-kor:
iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
MASQUERADE
Sajnos ez sem működik.
Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul
van a routing decision-on, es onnan meg
PÁSZTOR György wrote:
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-15 16:58-kor:
iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j
MASQUERADE
Sajnos ez sem működik.
Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul
van a routing
Gabor HALASZ wrote:
Nem is fog.Mire az output chainben a mangle table sorra kerul, mar tul
van a routing decision-on, es onnan meg par lepes a nat table, plane az
postrouting chain.
Értem én amit mondasz.
Meg lehet ezt a problémát oldani ip/iptables segítségével?
linux wrote:
Gabor HALASZ wrote:
Nem is fog.Mire az output chainben a mangle table sorra kerul, mar tul
van a routing decision-on, es onnan meg par lepes a nat table, plane az
postrouting chain.
Értem én amit mondasz.
Meg lehet ezt a problémát oldani ip/iptables segítségével?
Nem,
Gabor HALASZ wrote:
Nem, tobb rendbeli problema van, azt hiszem, csak interface-re...
Ha nem, hát nem ;-(
Köszönöm a segítséget, útmutatást.
Üdv: Kanyó Miklós
_
linux lista - linux@mlf.linux.rulez.org
Hi!
Gabor HALASZ halas...@freemail.hu írta 2008-12-15 20:24-kor:
Nem, tobb rendbeli problema van, azt hiszem, csak interface-re
Ahogyan az elméleteddel is.
bindelessel oldhato meg. Az alapeveto problema az, hogy routing az
~layer3, a tcp meg ~layer4, igy a routingnak mindegy, hogy http vagy
Szervusztok!
A gateway-en keresztul ket internet szolgaltaton keresztul
erem el az internetet -- tcom, upc.
A multi-route-olassal nics semmi gond.
Viszont egyes cel-portokat a megadott szolgaltaton keresztul
szeretnem elerni. Pl.: a 25-os porot a tcom-on keresztul szeretnem elerni.
// A
Hi!
li...@avia.kfkipark.hu li...@avia.kfkipark.hu írta 2008-12-14 19:21-kor:
A multi-route-olassal nics semmi gond.
Viszont egyes cel-portokat a megadott szolgaltaton keresztul
szeretnem elerni. Pl.: a 25-os porot a tcom-on keresztul szeretnem elerni.
// A gateway-en mail server, squid
Kedves Gyur!
A postfix-nek emlékeim szerint meg lehet mondani, mely interfészekre
qmail-em van.
postrouting-ban még elsimítod egy masq-al.
// van másom is: a 80, 443 portokat az upc-n kívánom.
Ehhez buta vagyok; hogyan?
Kösz:
--miklos
PÁSZTOR György wrote:
Hi!
Hi!
linux li...@avia.kfkipark.hu írta 2008-12-14 20:05-kor:
A postfix-nek emlékeim szerint meg lehet mondani, mely interfészekre
qmail-em van.
Az majdnem olyan jó. Szerintem azt is lehet konfigurálni, bár tény, hogy
macerásabb lehet.
postrouting-ban még elsimítod egy masq-al.
//
22 matches
Mail list logo
