Hi Oliver,
On Fri, Dec 29, 2017 at 05:32:47PM +0100, Oliver Fromme wrote:
> Hallo Harold,
>
> Harold Gutch wrote:
> > [...]
> > Was ich versuche ist im Prinzip:
> >
> > ipfw add 100 nat 1 udp from any to a.b.c.d 53
> > ipfw nat 1 config redirect_port udp 127.0.0.2:53 53 reverse
>
> Das sollte eigentlich gehen, allerdings denke ich, dass das
> „reverse“ falsch ist.
Hm, das kann durchaus sein. Ich fand die natd(8) Manpage an der Stelle
nicht wirklich klar, ich glaube ich hatte im Laufe der Tests aber alles
sowohl mit als auch ohne "reverse" probiert. Ich werd das mal nochmal
testen.
> Außerdem brauchst Due eine zweite
> „nat“-Regel für herausgehende Pakete (auf dieselbe nat-Instanz),
> ungefähr so:
>
> ipfw add 200 nat 1 udp from 127.0.0.2 53 to any
>
> (Ich habe das jetzt nicht selbst getestet; das ist nur aus
> dem Kopf.)
Richtig - ich hatte eine entsprechende Regel auch anfangs mal drin,
nachdem es damit aber nicht ging hab ich die fürs erste verworfen um
die Fehlersuche nicht komplizierter zu gestalten als sie eh schon war.
Egal ob die nun drin ist oder nicht, der named im Jail sollte die
einkommenden Queries sehen (es geht ja um UDP). Darum dass die
Antworten auch passen wollte ich mich im nächsten Schritt kümmern.
> IPFW ist ein ziemlich mächtiges Werkzeug, das über die Jahre
> viele Features angesammelt hat, was leider zur Folge hat,
> dass es recht komplex ist. Daher ist eine Ferndiagnose von
> Problemen auch sehr schwierig, da die Ursache an einer ganz
> anderen, unerwarteten Stelle verborgen sein kann.
>
> Als erstes wäre zu prüfen, ob die FW-Regeln stateful oder
> stateless sind. Sind sie stateful, sollte die „nat“-Regel
> für die hereinkommenden Pakete VOR der check-state-Regel
> stehen, und die „nat“-Regel für die herausgehen Pakete sollte
> NACH der check-state-Regel stehen.
Alle stateful-Regeln hatte ich während der Tests verworfen, es waren
lediglich einige sehr spezifische Filter drin (z.B. "ssh von X
erlaubt, ssh sonst geblockt") und die waren stateless.
> Als nächstes: Ist der systctl net.inet.ip.fw.one_pass auf
> 1 oder auf 0 gesetzt? Das entscheided, ob ein Paket nach
> Abarbeiten einer „nat“-Regel fertig ist, oder ob es dann mit
> der darauffolgenden Regel weiterbehandelt wird.
Da hatte ich auch beides getestet ohne dass ich einen Unterschied
feststellen konnte.
> Außerdem ist natürlich zu prüfen, ob die Pakete nicht durch
> andere Regeln bereits verworfen oder modifiziert werden.
> Das kann man relativ einfach herausfinden, indem man das
> Logging für die „nat“-Regeln aktiviert (entweder per syslog
> oder per tcpdump auf ipfw0, siehe das „log“-Keyword in der
> ipfw(8)-Manpage).
Das hab ich anhand der Zähler/Zeitstempel ("ipfw -ta l") verifiziert.
Ich hatte auch direkt nach der nat-Regel um sicher zu gehen noch zwei
"allow"-Regeln (für die unmodifizierten und die modifizierten Pakete -
bin mir gerade nicht mehr sicher bei welcher die Zähler erhöht wurden,
das werde ich noch testen). ipfw0 ist aber ein guter Hinweis, das
kannte ich in der Tat bisher noch nicht.
> Wie gesagt: Grundsätzlich sollte das mit IPFW gehen, was
> Du versuchst.
OK, dann probier ich damit nochmal etwas herum. Schöner wäre es auf
jeden Fall alles einfach nur via IPFW zu erledigen anstatt auf zwei
verschiedene Paketfilter zurückzugreifen.
Danke für alle Hinweise!
Harold
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 30 Dec 2017 - 00:28:26 CET