Új hozzászólás Aktív témák

  • Dißnäëß

    nagyúr

    Esetedben Te bal lentről indulsz, localhost-ról, local process-ből és felfele haladsz.

    Az OUTPUT több táblában is szerepel, tábladefiníció nélkül megadva a filter táblában lévő része van értelmezve és annak megfelelően ott machinálsz.

    A baj ott lehet, hogy X user kimenő csomagját ha Te VPN-be akarod áttolni és ez magáról a tűzfal gépről származik, ami ha jól értem, így van, azaz localhost-ról származik a csomag (!), akkor a filter tábla OUTPUT láncán átmegy, abba meg betettél egy DROP-ot, persze, hogy fogja.

    Kiszedném ezt a DROP szabályt és inkább egy ilyen UUID-el létrehoznék OUTPUT-ban egy ACCEPT szabályt, DROP-ot pedig nem is tennék a lánc végére, szerintem kevésbé szerencsés megoldás, inkább a lánc policy-jét érdemes DROP-ra állítani és automatikusan dob mindent, ami nem felelt meg 1 szabálynak sem (vagy még mindig a láncon maradt).

    Ha a szomszéd, melletted lévő gépről jönne a csomag és így kéne mennie tovább másik interfészre, akkor a csomag kihagyja localhost-ot és source/destination nat mellett machinálni a FORWARD láncokkal is, azokban szűrni (mondjuk policy DROP-ra itt is és akkor ütsz a pajzson egy lyukat, de az alapvetően mindig dob mindent, illetve a vissza iránynak is a válaszcsomagok érdekében ütni egy ACCEPT-es szabállyal lyukat és szűrted az átmenőt is). FORWARD-nál arra érdemes ügyelni, hogy kétirányú, tehát ott van -i és -o is értelmezve, míg egy INPUT chain -o eth0 -ra például elhasal, akárcsak egy OUTPUT a -i -re.

    Itt mégegy.

Új hozzászólás Aktív témák