Takhle to je bez následného zákazu portu 80
Žádný „následný zákaz portu“ v netfilteru neexistuje. Porty „zakazujete“ v chainu INPUT, kde se ta pravidla prochází jendo po druhém, dokud nějaké pravidlo nevyhoví. Nezáleží na tom, zda jste to pravidlo do chainu vložil dřív nebo později, než pravidlo pro NAT. Pořadí zpracování PREROUTING, INPUT, OUTPTU, FORWARD, POSTROUTING je pevně dané tím, jak paket prochází síťovým stackem – vy to pořadí nemůžete nijak ovlivnit. Dával jsem vám sem i odkaz na dokumentaci, kde je ten průchod paketu schematicky znázorněný.
ale stejně bych čekal, že povolený port by měl být 8080, ale to se chová jinak
Ano, chová se to tak, jak jsem napsal už asi desetkrát. DNAT se dělá v PREROUTING a ten se provádí dřív, než INPUT.
Takže příchozímu paketu s cílovým portem 8080 se změní cílový port na port 80. Teprve pak jde paket do INPUTu. Tam prochází jednotlivá pravidla, až narazí na povolení portu 80, takže je propuštěn dál.
Příchozímu paketu s cílovým portem 80 se změní cílový port na port 8080. Pak jde paket do INPUT chainu, prochází všechna pravidla, žádné pravidlo nevyhoví, tak se uplatní politika chainu, která je DROP, takže se paket zahodí.
Jediná věc, která není zřejmá, jsou ta dvě NATovací pravidla, protože pakety, které odpovídají prvnímu pravidlu, po provedení NATu odpovídají i druhému pravidlu. Naštěstí pro vás se NetFilter chová buď tak, že první pravidlo, kterému paket vyhoví, procházení ukončí, nebo že se proti pravidlům vyhodnocuje vždy ten původní paket (nechce se mi hledat, která varianta platí – nikdy jsem takovéhle zašmodrchání NATu nepotřeboval).