Hirdetés

  • Mini-ITX méretű RTX 4070 Kínából

    ph A Zephyr egyedi tervezésű VGA-ja szokatlanul rövid hűtést kapott, mely állítólag nagyon hatékony.

  • T Phone 2 Pro - majdnem mindenben jobb

    ma Az első körös magentás szolgáltatói telefonok ugyan nem voltak drágák, de sok kompromisszumot követeltek meg. A második generációs páros minden szempontból fejlődött, miközben az árazás maradt.

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

  • Dißnäëß

    veterán

    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.

    POKE 16017,44 ..... SYS 2077

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