Sziasztok!
Banális kérdés, ha csinálok egy ilyet:
iptables -t nat -i wg0 -A PREROUTING -p udp --dport 6055 -j DNAT --to-destination 10.240.69.1
Akkor a visszafelé jövő válasz csomagok forrás címét magától SNAT-olja, vagy azt nem? TCP-nél ez elég világos, de UDP-nél nem tudom hogy megy ez. Az UDP az connection-less, de nem stateless.
- 481 megtekintés
Hozzászólások
Miért SNAT-olná automatikusan? Csak akkor lesz SNAT, ha van ilyen szabály felvéve, amit ezt megteszi. Én nem tudok semmilyen protokoll esetén automatikus SNAT-ról iptables esetében.
- A hozzászóláshoz be kell jelentkezni
a conntrack-ra gondolhat a költő, ami viszont működik UPD esetében is.
Tehát, elvileg nem kell a csomagokat visszafelé is NAT-olni.
Ez a gyakorlatban viszont attól függ milyen kommunikáció zajlik valójában.
szerintem.
- A hozzászóláshoz be kell jelentkezni
> a conntrack-ra gondolhat a költő, ami viszont működik UPD esetében is.
> Tehát, elvileg nem kell a csomagokat visszafelé is NAT-olni.
Igen, pontosan erre gondoltam.
> Ez a gyakorlatban viszont attól függ milyen kommunikáció zajlik valójában.
Kicsit konkrétabban? :-)
- A hozzászóláshoz be kell jelentkezni
Kicsit konkrétabban? :-)
A fenti szabály konkrétan annyit csinál, hogy a wg0 interfacre UDP-n a 6055 portra érkező csomagokat továbbítja a 10.240.69.1 címre se több se kevesebb. A többi konkrétum attól függ milyen más szabályod van még.
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Jó igen azt nem írtam, hogy ez a legelső FORWARD szabályom:
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Bocsánat, ez nem volt magától értetődő.
- A hozzászóláshoz be kell jelentkezni
Ennek semm köze, a topic nyitó szabályhoz. Ez csak annyit mond, hogy a router átengedi azokat a csomagokat amik RELATED/ESTABLISHED kapcsoloval vannak. DE te NAT táblában operálsz, ez a szabály meg másik táblában ...
Javaslom előbb kicsit nézzél körbe iptables táblák stb témában mi merre hol, báár, mivel jó pár éve nftables van, lehet hagynod is kéne, csak bezavar, és egyből nftables ...
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Annyi köze van hozzá, hogy ha az egyik irányban átengedte az UDP-t akkor visszafelé is át fogja, feltéve hogy működik rá a conntrack. Igazából ez a kérdés, hogy UDP-nél mi kell ahhoz, hogy működjön a conntrack.
- A hozzászóláshoz be kell jelentkezni
Nem, mivel nyitó szabályod -t nat tábla a fenti forward szabály meg nem a -t nat tábla ...
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
az "átengedi" az a FORWARD
ez nem "átengedi" hanem "csinál" is vele valamit.
- A hozzászóláshoz be kell jelentkezni
iptables-hez tényleg nem értek (ahogy a mellékelt példa is mutatja), viszont docker-t használok sok helyen, és docker mindenhol iptables szabályokat kreál. Ha most feltenném egy ilyen gépre az nftables-t, akkor a iptables-nftables-compat -t használná? (Tudom ez offtopic)
- A hozzászóláshoz be kell jelentkezni
@zurbi átolvastam az udp-re vonatkozó részt az általad küldött leírásból. Ott nem szabályokat írtak, hanem egy példát. Emiatt nem 100% hogy jól értem, de így sejtem: ha a válasz ugyan arról a portról és címről érkezik, és ugyan arra a portra és címre megy vissza, akkor működni fog a conntrack és magától visszaírja a forrás címet. De ez csak sejtés.
- A hozzászóláshoz be kell jelentkezni
a portszám egyezés az alapvető követelmény, azon felül a timeout rész a lényeges.
van az olalon külön UDP-re magyarázat és példa is, hogy ez hogyan számolódik.
nagyon röviden:
amig nem 'esik ki' a conntrack táblából addig jól fog működni.
De ha a válaszcsomag csak egy hét múlva jön, akkor tutira nem :)
- A hozzászóláshoz be kell jelentkezni
Amúgy nem esik ki, 1 sec-en belül jön a válasz mindig.
- A hozzászóláshoz be kell jelentkezni
akkor működni fog a conntrack és magától visszaírja a forrás címe
Nem fogja, ahhoz kell egy MASQUERADE szabály
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Jó akkor most melyik az igaz? Akkor is átírja ha nem esik ki a conntrack-ből, vagy csak akkor írja át ha MASQUERADE van, vagy mindkettő?
- A hozzászóláshoz be kell jelentkezni
Nem kell MASQUERADE, ha rövid időn belül jön a válasz.
- A hozzászóláshoz be kell jelentkezni
Szóval akkor azt mondod, hogy először legyen egy DNAT, utána egy MASQUERADE, és úgy jó lesz?
- A hozzászóláshoz be kell jelentkezni
iptables -t nat -I POSTROUTING -o wg0 -j MASQUERADE
A fenti szabály annyit csinál, hogy minden csomag ami a NAT táblából, elhagyja az interface-t lecseréli a src ip-t a wg0 interface IP-jére.
Azaz jön a csomag az 1.1.1.1-es IP ről ezt megkapja a 10.240.69.1 ip, a fogadó látja, hogy az 1.1.1.1 ről jött így elkezdi oda visszaküldeni. Mivel a forrás IP: 10.240.69.1 ami egy nem routeotlt tartomány így a szolgáltató első route pontjánál dobodik a francba. Ezért van a MASQUERADE, hogy ne a nem publikus IP-vel hagyja el a csomag a gépet, hanem azzal amire maszkolják, fenti esetben a wg0 ipjével.
A conntrack meg ott jön a képbe, hogyha több IP van 1 IP mögé maszkolva, akkor tudni kell hogy melyik csomag melyik IP-hez tartozik.
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Jó szóval a MASQUERADE -hez kötelező a conntrack, mert változó lehet a forráscím, és vissza kell őket mappelni. Nekem ezen felül még a cél címet is át kell írnom egy konkrét IP-re. A DNAT a PREROUTING-ban van, a MASQUERADE a POSTROUTING-ban, szóval akkor gondolom a PREROUTING-ba tegyem bele a DNAT részt a POSTROUTING-ba meg a MASQUERADE -et?
iptables -t nat -A PREROUTING -p udp --dport 6055 -j DNAT --to-destination 10.240.69.1
iptables -t nat -I POSTROUTING -o wg0 -j MASQUERADE
Az a cél, hogy bárhonnan érkezik egy UDP csomag a 6055 -re, akkor az továbbítódjon (forrás cím átírással) a fix belső 10.240.69.1 -re, és ha onnan jön egy válasz (rövid időn belül), akkor annak a forrás címe legyen átírva arra a címre amelyiken eredetileg bejött az első csomag, a cél címe meg szintén arra a címre, ahonnan érkezett az eredeti első csomag.
- A hozzászóláshoz be kell jelentkezni
Az a cél, hogy bárhonnan
Akkor nem kell a -o wg0 , ha azt kihagyod, akkor az azt fogja jelenteni, hogy mikor a csomag eljhagyja az interface-t akkor forrásip az interface ip-je lesz.
cél címe meg szintén arra a címre, ahonnan érkezett az eredeti első csomag.
Amennyiben a bejövő csomagnál nem változtatod meg a forrás címét, a válasz mindig a forrás cím lesz.
Fedora 41, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Értem, köszi. (Bár ez tutira azon fog kimenni.)
- A hozzászóláshoz be kell jelentkezni
> Amennyiben a bejövő csomagnál nem változtatod meg a forrás címét, a válasz mindig a forrás cím lesz.
Ohh tehát a DNAT mellé kell egy SNAT is. Akkor három szabály kell.
- A hozzászóláshoz be kell jelentkezni
iptables -t nat -A PREROUTING -p udp --dport 6055 -j DNAT --to-destination 10.240.69.1
iptables -t nat -A POSTROUTING -p udp --sport 6055 -s 10.240.69.1 -j SNAT --to ?????
iptables -t nat -I POSTROUTING -o wg0 -j MASQUERADE
Így? Csak nem tudom, hogy a ??? helyére mit írjak. A wg0 interface címét?
- A hozzászóláshoz be kell jelentkezni
Vagy mégse kell az SNAT, mert a MASQUERADE átírja a forráscímet.
- A hozzászóláshoz be kell jelentkezni
a MASQ interface-re NAT-ol, az SNAT pedig IPcímre. Remélem tudod értelmezni a különbséget.
- A hozzászóláshoz be kell jelentkezni
Az alapprobléma az, hogy a 6055 portra érkező UDP csomagokat továbbítanom kellene egy adott IP-re úgy, hogy a válaszok visszamenjenek az eredeti forráshoz. De az eredeti forrás címe előre nem ismert, az bármi lehet.
Ráadásul egyszerre kellene DNAT és SNAT MASQUERADE ezekre (mármint az odafelé menő csomagokra), máskülönben a válasz csomag nem jó helyre lesz route-olva. A válasz csomagokra pedig kellene automatikusan visszaírni az eredeti forrás- és célcímet úgy, hogy ezek közül csak a célt tudomm a forrás az bármi lehet.
Igen, erre kellene a conntrack. Csak nem vagyok benne biztos, hogy mit kell ahhoz tennem, hogy UDP-re működjön a conntrack. Mivel itt nincsenek csomag szekvencia értékek. TCP-nél ez elég egyértelmű.
- A hozzászóláshoz be kell jelentkezni
a MASQUERADE nem kell neked, a DNAT elég:
To enable DNAT, at least one iptables command is required. The connection tracking mechanism of netfilter will ensure that subsequent packets exchanged in either direction (which can be identified as part of the existing DNAT connection) are also transformed.
reference:
- A hozzászóláshoz be kell jelentkezni
Biztos hogy elég? Ha a csomag forráscíme nincs átírva, akkor a célállomás ( 10.240.69.1 ) honnan fogja tudni, hogy ebbe az irányba kell visszaküldenie a választ? (Ha a default route-on át küldi, akkor az nem itt fog átmenni...)
- A hozzászóláshoz be kell jelentkezni
Sőt jobban belegondolva, lehet hogy meg se kapja, mert INVALID lesz belőle. A célállomás 10.240.69.1 csak a 10.240.0.0/14-ből fogad csomagokat a wireguard tunnel-en át, szóval ha a forráscímet nem írom át, akkor meg se kapja. (nyilván ez egy olyan infó amit eddig nem mondtam)
- A hozzászóláshoz be kell jelentkezni
na jó, de ez akkor már teljesen más felállás :D
én feltételeztem, hogy routing van a hálózatok között.
ha elhallgatod az információkat ,akkor nem megfelelő tanácsot fogsz kapni ;)
Egyébként ha már egyszer van egy tunnel-ed.. abban is lehet(ne) ám route-olni normálisan
szerintem vázold az alap felállást, amit meg kell oldanod.
ne csak azt a részét, ami szerinted jó megoldásból szerinted hiányzik.
- A hozzászóláshoz be kell jelentkezni
Szóval ez így van:
- távoli szerverek amik amazonaws-ben futnak küldenek UDP csomagot
- az beérkezik egy docker-ben futó VPN wireguard szerverre, aminek a 6055 -ös portja publish-olva van
- ez a VPN szerver továbbítja a csomagot a partner telephelyén levő mikrotik router-re
- az a router még egyszer dstnat-ol és masquerade-ezik, és feladja egy trunk portra
- onnan átmegy egy másik router-be ami kirakja egy access portra
- onnan megy bele a tulajdonképpeni cél eszközbe, ami válaszol rá
És hogy miért kell a VPN szerver: azért, mert a partnernek olyan hálózata van, ami megbízhatatlan, és váltogat a lassú ADSL kapcsolat meg a még lassabb LTE modem között (WAN failover), ahol ráadásul az LTE modem az persze CGNAT mögött van.
Ezek közül mindent sikerült beállítani, kivéve a docker-ben futó VPN szerveren belül a DNAT + MASQUERADE szabályokat. Azért, mert iptables-ből béna vagyok. :-)
Úgy kifejezetten nem akartam elhallgatni semmit, de ha mindent leírtam volna az első post-ban akkor senki nem olvassa el. :-D
A megoldásból tényleg csak ez az UDP DNAT + MASQUERADE hiányzott. És neked teljesen igazad volt abban, hogy azt feltétlezted, hogy a válaszoló fél default route-ja arra küldi vissza a csomagot, amerről jött. De nem így van.
> Egyébként ha már egyszer van egy tunnel-ed.. abban is lehet(ne) ám route-olni normálisan
Szerintem teljesen normálisan route-oltam mindent. :-D Annak jó oka van, hogy a partner default route-ja nem ezen a VPN szerveren keresztül megy. De ennek az oknak semmi köze az eredeti kérdéshez. Viszont tényleg szükséges lett volna tudni ahhoz, hogy jó választ kapjak.
De mint mondtam, nem értek az iptables-hez, talán elnézhető nekem.
A lényeg, hogy most úgy tűnik, megoldódott a probléma.
- A hozzászóláshoz be kell jelentkezni
nekem van egy ilyenem ez tcp de hátha segít :)
-A PREROUTING -i eth0 -p tcp -m tcp --dport 5500 -j DNAT --to-destination 172.16.0.4
-A POSTROUTING -p tcp -m tcp --dport 5500 -d 172.16.0.4 -j MASQUERADE
- A hozzászóláshoz be kell jelentkezni
Köszi, szóval DNAT + MASQUERADE. Kipróbálom. :-)
- A hozzászóláshoz be kell jelentkezni
Na ez lett belőle:
iptables -t nat -A PREROUTING -p udp -m udp --dport 6055 -j DNAT --to-destination 10.240.69.1
iptables -t nat -I POSTROUTING -p udp -m udp --dport 6055 -d 10.240.69.1 -j MASQUERADE
A célcím a wireguard tunnel másik oldalán egy mikrotik router, ott packet snifferrel ezt látom:
Columns: TIME, INTERFACE, SRC-ADDRESS, DST-ADDRESS, IP-PROTOCOL, SIZE, CPU
# TIME INTERFACE SRC-ADDRESS DST-ADDRESS IP-PROTOCOL SIZE CPU
0 2.621 wg-vpn 10.240.208.1:59224 10.240.69.1:6055 udp 37 2
1 2.621 ORANGE_VLAN 192.168.1.1:59224 192.168.1.99:6055 udp 51 2
2 2.621 BR1 192.168.1.1:59224 192.168.1.99:6055 udp 55 2
3 2.621 ether1-trunk 192.168.1.1:59224 192.168.1.99:6055 udp 55 2
4 2.647 ether1-trunk 192.168.1.99:6055 192.168.1.1:59224 udp 116 1
5 2.647 BR1 192.168.1.99:6055 192.168.1.1:59224 udp 116 1
6 2.647 ORANGE_VLAN 192.168.1.99:6055 192.168.1.1:59224 udp 112 1
7 2.647 wg-vpn 10.240.69.1:6055 10.240.208.1:59224 udp 98 1
Szóval bejön a vpn szerver forráscímével a csomag, eljut a céleszközig, és utána a 4-es sortól kezdve megy vissza szépen a válasz, ami a vpn szerver felé távozik is a tunnel-en.
Szerintem jó lett, de biztosan majd csak holnap derül ki.
Köszönöm a segítséget! :-)
- A hozzászóláshoz be kell jelentkezni
Szia!
Fent írták, kell még a FORWARD szabály is - anélkül nem fog menni:
-A FORWARD -s <ip> -j ACCEPT
-A FORWARD -d <ip> -j ACCEPT
Egy kis "hardening" - következőképpen nézne ki:
- Alapból nem engedünk át semmit, DROP default mindenütt ( filter tábla - INPUT/OUTPUT )
- Alapból nem engedünk át semmit, DROP default mindenütt ( filter tábla - FORWARD)
- "martians" IP-címeket (RFC 1812) szűrjük - debug miatt
A fentieket 2 helyen is be kell állítani
> iptables
> /etc/sysctl.conf
eth1: 10.0.0.1/24
http-server: 10.0.0.10/24 - (http-server-gw 10.0.0.1)
eth2: 172.16.0.100/24
router-gw: 172.16.0.1
webserver-redirect + NAT: 172.16.0.100:80 --> 10.0.0.10:80
(minta - iptables )
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
#
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
#
#
#
-A INPUT -i lo -j ACCEPT
#
#
#
# eth1 #
-A INPUT -i eth1 -s 0.0.0.0/8 -j DROP
##-A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 100.64.0.0/10 -j DROP
-A INPUT -i eth1 -s 127.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 169.254.0.0/16 -j DROP
-A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -s 192.168.0.0/16 -j DROP
#
-A INPUT -i eth1 -d 0.0.0.0/8 -j DROP
##-A INPUT -i eth1 -d 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -d 100.64.0.0/10 -j DROP
-A INPUT -i eth1 -d 127.0.0.0/8 -j DROP
-A INPUT -i eth1 -d 169.254.0.0/16 -j DROP
-A INPUT -i eth1 -d 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -d 192.168.0.0/16 -j DROP
#
##-A INPUT -i eth1 -j DROP
#
#
#
# eth2 #
-A INPUT -i eth2 -s 0.0.0.0/8 -j DROP
-A INPUT -i eth2 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth2 -s 100.64.0.0/10 -j DROP
-A INPUT -i eth2 -s 127.0.0.0/8 -j DROP
-A INPUT -i eth2 -s 169.254.0.0/16 -j DROP
##-A INPUT -i eth2 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth2 -s 192.168.0.0/16 -j DROP
#
-A INPUT -i eth2 -d 0.0.0.0/8 -j DROP
-A INPUT -i eth2 -d 10.0.0.0/8 -j DROP
-A INPUT -i eth2 -d 100.64.0.0/10 -j DROP
-A INPUT -i eth2 -d 127.0.0.0/8 -j DROP
-A INPUT -i eth2 -d 169.254.0.0/16 -j DROP
##-A INPUT -i eth2 -d 172.16.0.0/12 -j DROP
-A INPUT -i eth2 -d 192.168.0.0/16 -j DROP
#
##-A INPUT -i eth2 -j DROP
#
#
#
# eth1 - ssh #
#
-A INPUT -i eth1 -d 10.0.0.1 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
...
# eth2 #
#
...
#
#
#
-A INPUT -p icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp --icmp-type 3/4 -j ACCEPT
-A INPUT --fragment -j ACCEPT
-A INPUT -p icmp -j DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
#
#
#
-A FORWARD -s 10.0.0.10 -j ACCEPT
-A FORWARD -d 10.0.0.10 -j ACCEPT
-A FORWARD -j DROP
#
#
#
-A OUTPUT -o lo -j ACCEPT
#
#
#
# eth1 #
-A OUTPUT -o eth1 -s 0.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -s 10.0.0.0/24 -j ACCEPT
-A OUTPUT -o eth1 -s 10.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -s 100.64.0.0/10 -j DROP
-A OUTPUT -o eth1 -s 127.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -s 169.254.0.0/16 -j DROP
-A OUTPUT -o eth1 -s 172.16.0.0/12 -j DROP
-A OUTPUT -o eth1 -s 192.168.0.0/16 -j DROP
#
-A OUTPUT -o eth1 -d 0.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -d 10.0.0.0/24 -j ACCEPT
-A OUTPUT -o eth1 -d 10.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -d 100.64.0.0/10 -j DROP
-A OUTPUT -o eth1 -d 127.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -d 169.254.0.0/16 -j DROP
-A OUTPUT -o eth1 -d 172.16.0.0/12 -j DROP
-A OUTPUT -o eth1 -d 192.168.0.0/16 -j DROP
#
-A OUTPUT -o eth1 -j DROP
#
#
#
# eth2 #
-A OUTPUT -o eth2 -s 0.0.0.0/8 -j DROP
-A OUTPUT -o eth2 -s 10.0.0.0/8 -j DROP
-A OUTPUT -o eth2 -s 100.64.0.0/10 -j DROP
-A OUTPUT -o eth2 -s 127.0.0.0/8 -j DROP
-A OUTPUT -o eth2 -s 169.254.0.0/16 -j DROP
-A OUTPUT -o eth2 -s 172.16.0.0/24 -j ACCEPT
-A OUTPUT -o eth2 -s 172.16.0.0/12 -j DROP
-A OUTPUT -o eth2 -s 192.168.0.0/16 -j DROP
#
-A OUTPUT -o eth2 -d 0.0.0.0/8 -j DROP
-A OUTPUT -o eth2 -d 10.0.0.0/8 -j DROP
-A OUTPUT -o eth2 -d 100.64.0.0/10 -j DROP
-A OUTPUT -o eth2 -d 127.0.0.0/8 -j DROP
-A OUTPUT -o eth2 -d 169.254.0.0/16 -j DROP
-A OUTPUT -o eth2 -d 172.16.0.0/24 -j ACCEPT
-A OUTPUT -o eth2 -d 172.16.0.0/12 -j DROP
-A OUTPUT -o eth2 -d 192.168.0.0/16 -j DROP
#
-A OUTPUT -o eth2 -j DROP
#
#
#
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -j DROP
#
#
#
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
#
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
#
#
#
-A PREROUTING -i eth2 -d 172.16.0.100 -p tcp --dport 80 -j DNAT --to 10.0.0.10
-A POSTROUTING -o eth2 -s 10.0.0.10 -j SNAT --to 172.16.0.100
-A POSTROUTING -o eth2 -j MASQUERADE
#
#
#
(minta - sysctl)
/etc/sysctl.conf
#
# GLOBAL #
#
net.ipv4.ip_forward = 1
net.ipv4.ip_no_pmtu_disc = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_local_port_range = 32768 65535
net.ipv4.ip_nonlocal_bind = 1
#
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.proxy_arp_pvlan = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.accept_source_route = 0
#
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.default.arp_filter = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.proxy_arp_pvlan = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 1
net.ipv4.conf.default.accept_source_route = 0
#
#
# INTERFACES #
#
net.ipv4.conf.eth1.forwarding = 1
net.ipv4.conf.eth1.mc_forwarding = 1
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth1.arp_filter = 1
net.ipv4.conf.eth1.proxy_arp = 0
net.ipv4.conf.eth1.proxy_arp_pvlan = 0
net.ipv4.conf.eth1.send_redirects = 0
net.ipv4.conf.eth1.accept_redirects = 0
net.ipv4.conf.eth1.secure_redirects = 1
net.ipv4.conf.eth1.accept_source_route = 0
#
net.ipv4.conf.eth2.forwarding = 1
net.ipv4.conf.eth2.mc_forwarding = 1
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.eth2.arp_filter = 1
net.ipv4.conf.eth2.proxy_arp = 0
net.ipv4.conf.eth2.proxy_arp_pvlan = 0
net.ipv4.conf.eth2.send_redirects = 0
net.ipv4.conf.eth2.accept_redirects = 0
net.ipv4.conf.eth2.secure_redirects = 1
net.ipv4.conf.eth2.accept_source_route = 0
#
#
#
- A hozzászóláshoz be kell jelentkezni
Szerintem felesleges volt beraknod egy komplett tűzfal konfigot. Ez a konfig amit küldtél egy olyan gépre való, ami egy belső hálózatot véd a megbízhatatlan internet elől. De ez a gép amire nekem a DNAT kellett, nem ilyen. Egy egy docker-ben futó wireguard VPN szerver, ami az internet felől összesen kétféle dolgot kaphat: hitelesített wireguard UDP csomagot, és ezt a 6055 -ös portra érkező izét.
Egyébként meg nagyon hasznos lesz, ha iptables alapokon akarok tűzfalat építeni. :-)
- A hozzászóláshoz be kell jelentkezni
Ha ez egy önálló tűzfal, akkor ez a sok output drop tök felesleges. Az csak a konkrét gépről kezdeményezett kapcsolatokra vonatkozik. A gépen átmenő csomagokat a FORWARD-ban lehet szűrni, ott opciónak meg lehet adni az input/output interface-eket, ha ilyen szűrést szeretnél csinálni.
- A hozzászóláshoz be kell jelentkezni
Tesztelve, működik.
- A hozzászóláshoz be kell jelentkezni