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

• #28037 Dißnäëß nagyúr

  Új Válasz 2019-03-09 09:42:03 #28037

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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