Hálózatok általános

Sziasztok!

Nem vagyok sniproxy guru és most beleszaladtam egy olyan kérésbe hogy egy snprxy-n kéne egy 80-as átirányítás szűrni forrás ip-re.

Így nézne ki:

valami.hu:80 -> tűzfal nat -> (megadott forrás ip de csak a valami.hu-nál) sniproxy -> belso-ip:80

Tud ilyet egyáltalán? Nem találom a doksiba...

[megoldva] köszi ggallonak:

tűzfal/router szinten a megadott forrás IP címekről, 80-as cél portra érkező kapcsolatokat (d)NAT-olod a megfelelő belső szerverre, minden más 80-as célportra érkező kapcsolatot pedig az sniproxy-hoz irányítasz mint eddig.

Az egyik ilyen eszközről, az ElastiFlow-ról készült bejegyzésünket szeretném megosztani témaindítónak (angol nyelven íródott): https://ioflair.com/blog/openshift-4-12-traffic-analysis-with-elastiflo…

Az ElastiFlow esetén az egyik érv a rendkívül gyors beüzemelhetőség volt, ezzel együtt a lehető legtöbb releváns adatot lehet vizuálisan kinyerni egy-egy hálózati anomália felfedezésére.

Kinek milyen bevált eszközei vannak hasonló megoldásra? CLI megoldások, és pehelysúlyú megoldások is érdekelnek!

Hello,

úgy alakult szükséges egy ftp szerver is, működik, userek tudják használni, viszont nem tudtam megoldani azt, hogy az adott user a saját mappáján kívül ne tudjon mozogni.

olvastam több verziót, de valahogy nálam sehogy se akar össze jönni.

van erre gyors és egyszerű megoldás?

Köszipacsi.

Budapest, XV. kerület, reggel óta áll.

Ez elég durva, ilyen hosszú leállást eddig még nem tapasztaltam.

Sziasztok,

Egyik ismerősöm ESXi megoldása egy bérszerveren a Rackforestnél megpurcant és vissza kellene állítania 2 tera disk backupot.

Van ötletetek, hogy hol lehetne? Lakossági internettel picit lassú, Rackforestnél pedig nincs lehetőség bemenni és helyi hálózaton felmásolni egy új hostra az adatokat. :(

Update: support tud lehetőséget adni arra, hogy be lehessen menni – félretájékoztatást történt.

(Nem túl viccess a sztori: valami Ransomware pusztíthatott régi ESXi verzió miatt)

Érdekelne hogy van-e "elegáns" megoldása a következő problémának: Szeretném a helyi hálózatomat elérni VPN-en keresztül, úgy hogy a VPN szerver (IKEv2) egy hardveres tűzfalon fut és a tűzfal trusted portja egy router WAN portjára csatlakozik ami mögött van az elérni kívánt hálózat. Szegény ember vázlatrajza alant :-)

     WAN 
      ^
      |External
+-----------+                  +--------+
|    HW     |                  |  WIFI  |
|  Tűzfal   | 192.168.100.0/24 | Router | 192.168.200.0/22
|           |----------------->|        |--------------------->  Helyi háló
|    VPN    |Trusted        WAN|        |LAN                         
|  Server   |                  |        |
|172.24.24.1|                  |        |
+-----------+                  +--------+

Tudom hogy nem feltétlen optimális a fenti kiépítés. Úgy működött eddig a dolog hogy a VPN szerver a helyi hálón egy szerveren futott. De így ha a szerverrel bármi gáz van akkor nincs VPN-em sem, nem érem el a helyi hálót. Ezen szeretnék változtatni. A router-re is beizzíthatnám a VPN szervert, de a tűzfal VPN támogatását sokkal erősebbnek érzem, másrészt terveim szerint a Router idővel kikerül a láncból és AP módban csak a Mesh WIFI marad a feladata.

Szóval a tűzfalon lévő VPN már most is működik de csak a két eszköz közötti 192.168.100.0 hálózatot érem el rajta. Milyen irányba kellene elindulnom ha a fenti fizikai kiépítésen egyelőre nem akarok változtatni?

Üdv!

Egy tőlem távol lévő saját garázs (1 km, belvároson belül a lakás és garázs között) távfelügyeletét szeretném megoldani, és több opció is felmerült.

Célok:

- Elektromos Autó töltési állomás felügyelete (opcionálisan internet elérés biztosítása frissítésekhez)

- Hőmérséklet felügyelete

- Okos eszközök (pl elosztó vezérlése)

- Kamera (opcionálisan)

Opciók amiket látok:

- LTE router a leguniverzálisabb, de garázsban szélsőségesebb körülményeket kell bírnia, mint lakásban + a SIM kártya díja

- LoRaWAN?

A kérdés:

Milyen SIM megoldások lennének ebben az esetben a legkedvezőbbek, kicsi adatforgalom, inkább a hosszú időre való rendelkezésreállás fontosságával. Mivel szoftverfrissítések előfordulhatnak a töltőnél, ez opcionálisan megoldható ideignelenes mobil AP-val, így kisebb sávszélesség / adatforgalom is elegendő lenne.

Másik kérdés: LoRaWAN IP hálózat továbbítására mennyire lenne működőképes ha a nagy adatátvitele nem cél, de IP forgalmat kell továbbítani?

Ez most így egy nyílt kérdés, tehát bármi további megoldási ötlet érdekel, vagy akár kritikák a felmerült ötlet mentén, hogy mi lehet ezekkel a buktató, előny stb.

Sziasztok!

Abban kérnék segítséget, hogy mikrotik eszközön (hAP ac, RuterOS 7.7) próbálok másodlagos wifi AP-t, a hozzá kapcsolódó vlan+DHCP-vel létrehozni, de valami nem kerek, és nem jövök rá, hogy mi. Az ap ok, a telefonon csatlakozásakor az látszik, hogy kérne IP-t, de nem kap. Van már másik slave AP, az jó, nem találom i az eltérés a kettő között. Ami érdekes, hogy volt összesen 3 slave AP-is, ami korábban ok volt, szerinte még 6.x volt mikor létrehoztam, ebből az egyiket próbáltam módosítani, hogy az új hálózatba menjen, az se lett jó, de visszaírva az eredetire a vlan id-t már ahhoz se csatlakozik, de régebben ez biztosan ok volt.

Merre induljak, mi lehet elrontva?

Lentebb van pár új részlet + szerintem conf. részletek.

update

2023.02.14.: fél megoldás : https://hup.hu/comment/2886960#comment-2886960

Segítségeteket kérném a megfelelő tűzfal szabály létrehozásában. Az eszköz Mikrotik hAPac2. A port forward szabályom szerintem jó, legalábbis, ha meghívom a böngészőből látom a winboxban a byte-ok és a csomagok számát is nőni.

 > ip firewall filter export 
# feb/07/2023 10:25:00 by RouterOS 6.49.7
# software id = XQP8-1QZR
#
# model = RBD52G-5HacD2HnD

/ip firewall filter
add action=drop chain=input comment="Input filter a k\FCls\F5 DNS t\E1mad\E1sok ellen" dst-port=53 protocol=udp src-address=!192.168.0.0/16
add action=fasttrack-connection chain=forward connection-state=established,related dst-address=192.168.5.0/24
add action=accept chain=forward connection-state=established,related
add action=accept chain=forward comment=ProxmoxVE connection-nat-state="" connection-state=established,related dst-port=8006 protocol=tcp src-port=8006
add action=accept chain=input comment="Established connections" connection-state=established
add action=accept chain=input in-interface=!pppoe-digi src-address=192.168.0.0/24
add action=accept chain=forward connection-state=established,related
add action=add-src-to-address-list address-list=blacklist address-list-timeout=1d10m chain=input comment="port scanners kiv\E9d\E9s\E9re" protocol=tcp \
    psd=21,3s,3,1
add action=drop chain=input comment="drop blacklist input" src-address-list=blacklist
add action=drop chain=forward comment="drop blacklist forward" src-address-list=blacklist
add action=drop chain=input comment="Invalid csomagok eldob" connection-state=invalid
add action=drop chain=forward comment="Invalid csomagok eldob" connection-state=invalid
add action=drop chain=input comment="Input filter a k\FCls\F5 DNS t\E1mad\E1sok ellen" dst-port=53 protocol=udp src-address=!192.168.0.0/16
add action=fasttrack-connection chain=forward connection-state=established,related dst-address=192.168.5.0/24
add action=accept chain=forward connection-state=established,related
add action=accept chain=input comment="Established connections" connection-state=established
add action=accept chain=input in-interface=!pppoe-digi src-address=192.168.0.0/24
add action=add-src-to-address-list address-list=blacklist address-list-timeout=1d10m chain=input comment="port scanners kiv\E9d\E9s\E9re" protocol=tcp \
    psd=21,3s,3,1
add action=drop chain=input comment="drop blacklist input" src-address-list=blacklist
add action=drop chain=forward comment="drop blacklist forward" src-address-list=blacklist
add action=drop chain=input comment="Invalid csomagok eldob" connection-state=invalid
add action=drop chain=forward comment="Invalid csomagok eldob" connection-state=invalid

Ugye a fentiekből a 

add action=accept chain=forward comment=ProxmoxVE connection-nat-state="" connection-state=established,related dst-port=8006 protocol=tcp src-port=8006

sor lenne a releváns. 

Még egy kis infó:

A

/ip firewall connection print detail

parancs releváns sora, tehát a NAT szabályom így néz ki.

    C   d protocol=tcp src-address=192.168.5.181:50460 dst-address=79.120.174.212:8006 reply-src-address=192.168.5.153:8006 
            reply-dst-address=192.168.5.181:50460 tcp-state=syn-sent timeout=4s orig-packets=1 orig-bytes=52 orig-fasttrack-packets=0 
            orig-fasttrack-bytes=0 repl-packets=0 repl-bytes=0 repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=0bps repl-rate=0bps 

Van egy OpenVPN server egy VPS-en. Hozzá csatlakoznak több helyről routerek kliensként, mögöttük belső hálókkal. Belső hálók push route-tal ki vannak tolva a kliensek felé, így szépen a különböző hálók gépei látják egymást. Van laptopon is kliens, így bárhonnan be tudok csatlkozni és látok bármit. Ugyanez lenne a cél Android-os eszközökről is, viszont itt a push routing nem megy át. Sőt ha kézzel állítok be route-ot az android klienseken a belső hálókra, azt sem állítja be.
Van erre eselleg valalkinek ötlete?

Köszönöm

UPD: végül váltottam wireguard-ra, ezzel megoldódott a gond