Két mérnök ugyanazzal az OpenBSD átjáróval gyakran két különböző szabálykészletet ad a távoli hálózat eléréséhez, és mindkettő megvédhető. A forrásfördítás és a visszatérő útvonal közötti választás egyáltalán nem szintaktikai kérdés. Azon múlik, hogy a túloldal mit tud már a 192.168.88.0/24 hálózatról, és hogy neked mit kell megtartanod a naplókban. Ha ezt elrontod, a nat-to sor tökéletesen helyesnek látszik, miközben a válaszok eltűnnek a távoli alapértelmezett átjáróban.

Az útválasztás és az átírás különböző kérdésekre válaszol

Az útválasztási tábla dönti el, hogy a 172.20.0.0/16 elérhető a tun0 felé, és ez a döntés minden pf-fordítás megkérdezése előtt megszületik. A forrásfördítás ezután megváltoztatja a csomagfejlécet, így a távoli vég az átjáró alagútcímét látja LAN-gép helyett. Egyik mechanizmus sem helyettesíti a másikat: a nat szabály nem tud útvonalat varázsolni, az útvonal pedig nem tudja meggyőzni azt a távoli routert, amely soha nem hallott a privát alhálózatodról. Ha a túloldalnak nincs visszaútja, a válaszok eldobódnak vagy a saját alapértelmezett átjárója felé továbbítódnak, és ezen semmilyen szabályhangolás nem segít.

Egyszerűen szólva, a továbbítás azt válaszolja meg, hová megy a forgalom, a fordítás pedig azt, hogy honnan látszik jönni. Tartsd őket külön mentális dobozokban, míg a szabálykészletet tervezed.

Három feltétel, amely eldönti

Tegyél fel három kérdést sorrendben, és a terv általában magától kiválasztja magát. Van-e a távoli hálózatnak statikus útvonala az alagút címére a 192.168.88.0/24 felé, vagy a rendszergazdája irányítja az útvonal routerjeit? Ha igen, hagyd a LAN-címeket változatlanul utazni, és hagyd ki teljesen a fordítást. Szükséged van kliensenkénti láthatóságra a túloldalon, akár hozzáférési szabályzathoz, akár auditnyomhoz? Ha igen, a forrás megőrzése megéri az útválasztási munkát. Elég stabil-e az alagút címe ahhoz, hogy távoli útvonalba írd, vagy újracsatlakozások között változik?

Ha bármelyik válasz nem vagy ismeretlen, a nat-to a pragmatikus választás, és ez a visszafordítható is. A fordítási szabály egyetlen sorban kikerül, amint a túloldal rendes útvonalat ad hozzá. Az a visszatérő útvonal, amelyet soha nem telepítettek, minden alkalommal egy támogatási szálba kerül, amikor valaki megkérdezi, miért csak egy irányban működik az alagút.

A töredék elhelyezése, hogy a pf valóban kiértékelje

Az alábbi töredék feltételezi, hogy a LAN 192.168.88.0/24, a távoli hálózat 172.20.0.0/16, az alagút interfésze pedig tun0. Semmi benne nem választ következő ugrást. Csak azoknak a csomagoknak írja át a forrását, amelyek már az alagúton keresztül távoznak.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Két részlet abban az első sorban viseli a legnagyobb súlyt. A tun0 körüli zárójelek azt mondják a pf-nek, hogy minden állapotbejegyzés építésekor olvassa ki az interfész címét, ami akkor számít, amikor az alagút újraszámozódik egy újracsatlakozás után. A match szó azt jelenti, hogy a szabály átír, majd továbbenged, így egy külön pass szabálynak még mindig beengednie kell a folyamot. A match sorban megnevezett interfésznek is annak kell lennie, amelyet az útválasztási tábla kiválaszt, különben a pf más kimenő útvonalon értékeli a szabályt, mint amelyen a csomag valóban halad.

Ne feledkezz meg a kernel oldaláról. Az IPv4-továbbítást engedélyezni kell, és az alagút valamint a LAN állapottartó pass szabályainak létezniük kell, mielőtt bármi értelmet nyer. A kulcsszavak sorrendjéhez az OpenBSD GYIK PF NAT szakasza a megfelelő hivatkozás.

Ellenőrizd a szabálykészletet, mielőtt megbízol a forgalomban

Először a pfctl -nf /etc/pf.conf paranccsal ellenőrizd a szintaxist, amely betöltés nélkül elemzi a fájlt. Utána töltsd be a szabályzatot, és olvasd vissza, mit tart valójában a kernel, mert egy tisztán elemzett szabály még mindig árnyékba kerülhet, vagy rossz interfészhez kapcsolódhat. A pfctl -sn a fordítási szabályokat nyomtatja ki betöltött formájukban, a pfctl -sr pedig a szűrőszabályokat kiértékelési sorrendben.

Ezután figyeld a vezetéket. Az átjárón a tcpdump -ni tun0 'host 172.20.0.10' megmutatja, hogy az alagútat elhagyó forráscím az alagút címe-e vagy a LAN-gépé. Egy gyors netstat -rn -f inet megerősíti, melyik interfészre oldódik fel a cél. Amint a forgalom megindul, a pfctl -ss felsorolja az állapotbejegyzéseket; ha egy folyam nem hozott létre állapotot, a csomag soha nem talált olyan szabályt, amely létrehozna egyet.

Ha az alagút oldala rendben van, de a válaszok még mindig nem érkeznek, hagyd abba a pf szerkesztését. A fennmaradó hiba a távoli routeren van, ahol a választ egy olyan privát cím felé küldik, amelyet az az oldal nem tud elérni.

Amikor a fordítás többe kerül, mint amennyit megspórol

A fordítás elrejti az ügyfeleket, és néha épp ez a rossz üzlet. Az átfedő alhálózatok egy eset: ha a túloldal belsőleg szintén a 192.168.88.0/24 hálózatot használja, a LAN-gépek átjáróként való bemutatása súlyosbítja az ütközést ahelyett, hogy enyhítené. Az IPsec-szabályzatok, amelyek címpár alapján választják ki a forgalmat, egy másik eset, mert a biztonsági szabályzat adatbázisa a fordítás előtt párosul, és soha nem látja az átírt csomagot. Minden olyan telepítés, amely felhasználónként számláz, korlátoz vagy auditál, szintén elveszíti a szükséges identitást abban a pillanatban, amikor a forrás egyetlen címre omlik össze.

A hordozható pf-leszármazottak külön csapda. Azok a termékek, amelyek saját szabályfájlokat generálnak, elvárják, hogy a NAT-ot a saját felületükön keresztül állítsd be, a kézzel szerkesztett töredékeket pedig a következő újratöltés felülírja. A match kulcsszó megjelenése előtt írt útmutatókból másolt szabálykészletek nem töltődnek be a jelenlegi kernelen, ezért portold a szintaxist, és olvasd el a hibát ahelyett, hogy találgatnál.

A valódi hálózatokkal való találkozást túlélő döntési szabály rövid: telepíts visszatérő útvonalat, amikor tudsz, fordíts, amikor nem tudsz, és írd le, melyik három feltétel vezetett a választáshoz. Az a feljegyzés egy egész délutánt megspórol a következő embernek.

Kapcsolódó cikkek