Openwrt upgrade, iptables helyett nftables

Hálózatok egyéb

Sziasztok!

A 22-es wrttől kezdve nem iptables van hanem nftables.
Volt pár iptables szabályom amit sajnos sehogy nem sikerül nftables alatt életre kelteni.

iptables -I FORWARD -i br-lan -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br-lan -j ACCEPT
iptables -I INPUT -i tun0 -j ACCEPT
iptables -I OUTPUT -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
 

Nem vagyok egy nagy firewall mágus úgyhogy pls ne kövezzetek meg. 

Odáig eljutottam hogy talán (FIXME) nft fileokkal kell operáljak, odáig eljutottam hogy valahogy így kellene kinézzen:

#!/usr/sbin/nft -f

table inet fw4 {
    chain input {
        type filter hook input priority 0; policy drop;
        iifname "tun0" accept
    }

    chain output {
        type filter hook output priority 0; policy drop;
        oifname "tun0" accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        iifname "br-lan" oifname "tun0" accept
        iifname "tun0" oifname "br-lan" accept
    }

    chain postrouting {
        type nat hook postrouting priority 0;
        oifname "tun0" masquerade
    }
}

Viszont sajnos ez nem úgy működik ahogy szeretném, a router egy openvpn client és szeretném ha az openvpn szerver a lan hálózatból is elérhető legyen, ami iptables alatt gyönyörűen működött. 

Hol lehet a hiba?

Köszi mindenkinek a hozzászólást.

 

  • 729 megtekintés

( Czo v | 2023. 08. 11., p – 12:57 )

Szerkesztve: 2023. 08. 11., p – 12:58

O, biztos, hogy ehhez kell barmilyen kezi-vezerelt medzsik? Csak ez az 5 iptables command van? Ehhez szerintem, semmilyen custom rule nem kell. Kell ketto zona, az egyik az, amelyik tartlamazza a 'br-lan' interfacet, a masik pedig, amelyik tartalmazza a 'tun0'-t. A zonaknal be tudod allitani a default input/output/forwardot, illetve ott tudod kapcsolni a masqueradet, ezen kivul, kell 1-1 forwarding config opcio is, amiben definialni tudod, hogy honnan hova. 

Igazából sajnos ott sosem tudtam összerakni, ezért volt a manuális iptables szabály.

Most megpróbáltam összerakni így néz ki jelenleg. 

https://i.imgur.com/CLz4Fuv.png
 

config zone
    option name 'vpn'
    option input 'ACCEPT'
    option output 'ACCEPT'
    list network 'VPN'
    option forward 'ACCEPT'

config forwarding
    option src 'vpn'
    option dest 'lan'
 

config zone
    option input 'ACCEPT'
    option output 'ACCEPT'
    list device 'br-lan'
    option forward 'ACCEPT'
    option name 'LANTOVPN'

config forwarding
    option dest 'vpn'
    option src 'LANTOVPN'
 

Illetve most így probálkozom de sajnos így sem jó. :/

config rule
    option name 'Allow_FORWARD_br-lan_to_tun0'
    option src 'br-lan'
    option dest 'tun0'
    option target 'ACCEPT'

config rule
    option name 'Allow_FORWARD_tun0_to_br-lan'
    option src 'tun0'
    option dest 'br-lan'
    option target 'ACCEPT'

config rule
    option name 'Allow_INPUT_tun0'
    option src 'tun0'
    option target 'ACCEPT'

config rule
    option name 'Allow_OUTPUT_tun0'
    option dest 'tun0'
    option target 'ACCEPT'

config zone
    option name 'tun'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'
    option network 'tun0'

config forwarding
    option src 'br-lan'
    option dest 'tun'

config forwarding
    option src 'tun'
    option dest 'br-lan'

config nat
    option target 'MASQUERADE'
    option name 'MASQUERADE_tun0'
    option src 'tun'
 

Szerintem, nem kell tobb, annal, mint amit irtam. De olvasd at ujra a dokumentaciot megoldani nem fogom). Miert csinaltad ezeket az "Allow_FORWARD_xxx" szabalyokat? Ezeket siman megtudja tenni a "forwarding" opcio. Direkt kevered az inerface nevet meg a zonakat? Tenyleg annyi zonad van, amire szukseged van? Pl. az elozo konfigreszletednel egy 'LANTOVPN' es egy 'vpn' nevu zonat definialtal, majd engedelyezted a forwardingot a 'LANTOVPN' - 'vpn' iranyban, illetve a 'vpn' - 'lan' iranyban.

Mivel latom, hogy van luci is, ha nem megy kozvetlen a konfigfileok iranyabol, akkor probalhatod osszekattingatva is. Megcsnialod a zonakat, a zonakhoz rendeled az interfaceket, bepipalod, honnan hova mehet csomag, majd bepipalod a maszkolast is es keszen is vagy.

De olvasd at ujra a dokumentaciot megoldani nem fogom

Azt nem is kértem mert úgy nem tanulok :)

Miert csinaltad ezeket az "Allow_FORWARD_xxx" szabalyokat? 

Megpróbáltam más megközelítésből a dolgokat, ennek a következménye a több zóna. 
Most kitöröltem mindent és proba a legelejétől. 

( _ventura_ v | 2023. 08. 11., p – 14:49 )

En visszaraktam az iptables-t azaz firewall3 -at :D Ami bevalt azon nem kell valtoztatni :D

Fedora 42, Thinkpad x280

Az a gond, hogy mire a népek megtanulták az ipfwadm-et, jött az ipchains. Na, mire azt is megismerték a népek, már iptables volt a trendy. Nyilván most már nem az van, hanem nftables. Probáljuk meg ebből megsaccolni, mennyi energiát érdemes beletenni a nftables megismerésébe.

Emléjeim szerint az iptables 90 es évek végén jött ki. Az nftables meg valamikor 2014 környékén, A distrok meg pár évvel utána kedztek rá beállni. 

Tehát jó 20 évig volt alap az iptables. nftables is velünk lesz szerintem jó pár évig  még, minimum 10 :D

Fedora 42, Thinkpad x280

Az NFT számos dologban újított, egy manapság korszerűnek mondható linux kernellel az iptables-t sok esetben képes felülmúlni.

Csak egy ilyen tipikus példa az IPv6 dual stack támogatása, ha nincs saddr és daddr, nem kell külön szabályokkal bohóckodni ha pl. csak port vagy interface alapú szabályt hozok létre az input, forward típusú chain-eken.

Tehát már nem iptables és ip6tables, hanem egy tűzfal van és csak akkor van jelentősége, hogy IPv4 vagy IPv6, ha annak tényleges relevanciája van.

 

Ezen felül sokkal átláthatóbb mint az iptables. Mondom ezt úgy, hogy én akkor csöppentem bele ebbe az egészbe, amikor az NFT-vel még csak riogattak, hogy Debian 10-től az lesz az alapértelmezett.

 

Szerintem.

TheAdam

( Friczy v | 2023. 08. 11., p – 15:42 )

type filter hook output priority 0; policy drop;

Ez szerintem nem jó, minden output forgalmat megfog. A második sor alapján kivéve a tun0 interface-t de persze az összességében kevés. Általában output policynak ritkán szokás dropot beállítani. Persze van olyan helyzet, ahol arra van szükség.

( theadam | 2023. 08. 11., p – 16:04 )

Szerkesztve: 2023. 08. 11., p – 16:06

Nekem egy Wireguard-dal csatolt távoli subnet elérése van megoldva úgy, hogy elérem a LAN-omról és onnan is elérhető a LAN-om + van egy olyan bonyolítás, hogy nincs NAT, routolva van a forgalom, hogy rendesen legyenek source IP-k.

 

alapvetően a LAN-om, az IoT és a guest közt nincs átjárás, emiatt az alapvető tiltásból vannak engedve a dolgok.

 

config zone
    option name 'lan'
    list network 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'DROP'

 

config zone
    option name 'kimsufi_wg'
    list network 'kimsufi_wg'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'DROP'
    option masq '0'
    option mtu_fix '1'

 

#mindkét irányt engedem

config forwarding
    option src 'lan'
    option dest 'kimsufi_wg'

 

config forwarding
    option src 'kimsufi_wg'
    option dest 'lan'

 

Így van három hálózatom (LAN, gst, IoT). A LAN-ból át lehet menni a VPN-re és fordítva, de más irányokba nem. Az input-output direkt accept, a router elérését nem látom értelmét korlátozni az általam kezelt LAN-ról és VPN-ről:D no meg ha távolról kell, akkor is így érem el a routert.

TheAdam

( lcsaszar v | 2023. 08. 13., v – 21:19 )

Nálam ez van, és működik (IPv6 sorokat kigyomláltam, ha kell megadom azokat is):

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

( gazsiazasz | 2023. 08. 14., h – 19:16 )

Luckily for those migrating from iptables, nftables still accepts the old syntax.

You can also use the iptables-translate utility, which will accept iptables commands and convert them to the nftables equivalent. This is an easy way to see how the two syntaxes differ.