Rég nem volt már teljes egészében Vyattának szentelt írás az oldalon, a napokban épp szóba is került a rendszernek egy érdekesebb tulajdonsága a munkahelyemen, így most semmi sem tarthat vissza attól, hogy mindazt, amiről ott szó volt, közzé ne tegyem. Alapvetően egyszerű dologról van szó, a Vyatta port forwarding vagy DNAT lehetőségéről, ami kombinálva némi szűréssel, könnyen káromkodásba fordulhat (megjegyzem, minden Linux rendszeren ugyanezen szisztéma szerint működik a DNAT). Mi is ez az egész pontosan? Íme a Vyatta dokumentációból kiollózott ábra, mely az egyes NAT alrendszerek, a routing folyamat és a tűzfalazás viszonyát szemlélteti:
Az ábrán a témánk szempontjából két fontos dolgot láthatunk, az egyik az, hogy a DNAT (destination NAT, avagy port forwarding, esetleg szolgáltatás publikálás) minden egyéb feldolgozási folyamat, routeolás, szűrés előtt történik meg egy beérkező csomagon. Ezzel szemben az SNAT (source NAT) a legutolsó lépés, ami csak a routeolás és a tűzfalazás után történik. A szűrés szempontjából az SNAT sima ügy, bejön a klienstől a csomag mondjuk a 192.168.0.100-as forrás IP-vel, a célcím nem a Vyatta rendszer (Dest=local? No), a tűzfal szépen átkergeti az IN, majd az OUT irányú szabályokon, végül az SNAT dobozkában leszerelik róla a 192.168.0.100-as feladói címet és ráhegesztik mondjuk feladóként az 1.2.3.4 publikus címet, illetve ezt fel is jegyzik egy táblázatba, hogy a visszatérő forgalmat le lehessen kezelni és eljusson az eredeti feladóhoz.
A DNAT egy kicsit más, arról van ugye szó, hogy az 1.2.3.4-re irányuló, pl. TCP 80-as forgalmat valójában nem a Vyatta webszervere emésztgeti, hanem a mögötte lévő NAT-olt hálóban mondjuk a 192.168.0.101-es host. Bemegy a DNAT dobozba a 1.2.3.4:80-ra küldött üzenet, odabent átalakul, és ami kijön, annak már 192.168.0.101:80 lesz a célja. Persze a dobozban ezt a csereberét megintcsak jól feljegyzik. Ezek után a routing megmondja, hogy ez a 192.168.0.101 a Vyatta LAN oldalán található cím (Dest=local? No), átmegy az IN, majd az OUT szűrőn, és kimegy a LAN-ba.
Mindez azért érdekes, mert az ember - főképp, ha vállalati tűzfalak GUI-jához szokott - a tűzfalszabályok írásakor alapból nincs NAT üzemmódban, és egy ilyen DNAT-olt 80-as portot simán úgy vesz fel a Vyatta tűzfalszabályokban, hogy a külső IP címmel számol, az 1.2.3.4:80-ra engedi be a népeket, pedig mire a tűzfalhoz eljut az 1.2.3.4:80-as csomag, addigra az már keresztülverekedte magát a DNAT-on, és 192.168.0.101:80 van benne.
Következzék egy konkrét konfig példa, ami kívülről elérhetővé teszi az 1.2.3.4:22-es és 1.2.3.4:80-as TCP portokat, a különbség annyi, hogy az SSH a Vyattán fut, a HTTP viszont NAT mögött, másik hoston. A Vyatta külső interfészének (eth0) bejövő szűrőjében mégis egy privát, belső IP cím szerepel:
firewall {
name INET_to_INTERNAL {
default-action drop
rule 100 {
action accept
description "Allowing HTTP traffic to internal host 101"
destination {
address 192.168.0.101
port 80
}
protocol tcp
}
}
name INET_to_LOCAL {
default-action drop
rule 100 {
action accept
protocol icmp
}
rule 200 {
action accept
description "SSH access on port 22"
destination {
address 1.2.3.4
port 22
}
protocol tcp
}
}
}
interfaces {
ethernet eth0 {
address 1.2.3.4/24
firewall {
in {
name INET_to_INTERNAL
}
local {
name INET_to_LOCAL
}
}
}
ethernet eth1 {
address 192.168.1.1/24
}
loopback lo {
}
}
protocols {
static {
route 0.0.0.0/0 {
next-hop 1.2.3.1 {
}
}
}
}
service {
nat {
rule 100 {
description "DNAT for HTTP on 192.168.0.101"
destination {
address 1.2.3.4
port 80
}
inbound-interface eth0
inside-address {
address 192.168.0.101
}
protocol tcp
type destination
}
rule 200 {
description "SNAT for internal subnet"
outbound-interface eth0
outside-address {
address 1.2.3.4
}
source {
address 192.168.0.0/24
}
type source
}
}
ssh {
port 22
protocol-version v2
}
}
