1
Sítě / Re:Rozdíl mezi REJECT a DROP ve firewallu
« Poslední příspěvek od František Ryšánek kdy Dnes v 20:32:11 »> jak se to aplikace dozví
Programujete trochu? Pokud ano, v čem?
Já trochu znám BSD sockets API hezky jak ho pánbůh stvořil = v céčku. Tzn.:
- na straně klienta se TCP spojení navazuje: socket(), connect()
- na straně serveru klasická práce s TCP vypadá takto: socket(), bind(), listen(), accept()
V obou případech dostanete "otevřený file descriptor" - pokud všechna volání skončila úspěchem.
S otevřeným socketem/deskriptorem se dál pracuje pomocí funkcí jako send()/recv(), případně read()/write(), trochu specialita je select() = lze čekat na událost od kteréhokoli z více otevřených socketů ve specifikované množině.
Jsou i nějaké další modernější funkce nad otevřenými sockety (poll(), co já vím co ještě).
Takže pokud se pokusíte otevřít spojení na trase, kde je předem ofiltrováno pomocí REJECT směrem ven, tak Vám na klientu connect() skončí okamžitě chybou, na serveru si nejsem jist - accept() buď skončí chybou, nebo se možná vůbec neprobudí z blokujícího čekání na příchozí TCP relaci.
Pokud byste měl navázané TCP spojení, běžel na něm provoz, a vy byste v tu chvíli vložil pravidlo s REJECTem do iptables, tak Vám selže s chybou nějaký ten send() / recv() a socket se sám zavře / padne do nějakého vadného stavu.
Výše uvedené chování při REJECTu odhaduji pro TCP = když při vytváření socketu specifikujete option SOCK_STREAM.
Jak to vypadá při použití connection-less vrstvy UDP (SOCK_DGRAM) to si nejsem jist.
Okamžitý stav socketu se dá zjistit jednak funkcí getsockopt(), druhak i bez ní jednotlivá výše zmíněná volání "končí chybou" tím způsobem, že v souladu s manuálovou stránkou vrátí "chybovou" návratovou hodnotu (třeba recv() vrací 0 bajtů přijato, jiné funkce mohou vracet přímo chybový kód se znaménkem mínus) - vedle návratové hodnoty bývá současně k dispozici globální proměnná errno, kterou lze interpretovat na textovou zprávu (řetězec) funkcemi strerror() nebo perror()... k tomu všemu jsou v linuxu man pages.
Programujete trochu? Pokud ano, v čem?
Já trochu znám BSD sockets API hezky jak ho pánbůh stvořil = v céčku. Tzn.:
- na straně klienta se TCP spojení navazuje: socket(), connect()
- na straně serveru klasická práce s TCP vypadá takto: socket(), bind(), listen(), accept()
V obou případech dostanete "otevřený file descriptor" - pokud všechna volání skončila úspěchem.
S otevřeným socketem/deskriptorem se dál pracuje pomocí funkcí jako send()/recv(), případně read()/write(), trochu specialita je select() = lze čekat na událost od kteréhokoli z více otevřených socketů ve specifikované množině.
Jsou i nějaké další modernější funkce nad otevřenými sockety (poll(), co já vím co ještě).
Takže pokud se pokusíte otevřít spojení na trase, kde je předem ofiltrováno pomocí REJECT směrem ven, tak Vám na klientu connect() skončí okamžitě chybou, na serveru si nejsem jist - accept() buď skončí chybou, nebo se možná vůbec neprobudí z blokujícího čekání na příchozí TCP relaci.
Pokud byste měl navázané TCP spojení, běžel na něm provoz, a vy byste v tu chvíli vložil pravidlo s REJECTem do iptables, tak Vám selže s chybou nějaký ten send() / recv() a socket se sám zavře / padne do nějakého vadného stavu.
Výše uvedené chování při REJECTu odhaduji pro TCP = když při vytváření socketu specifikujete option SOCK_STREAM.
Jak to vypadá při použití connection-less vrstvy UDP (SOCK_DGRAM) to si nejsem jist.
Okamžitý stav socketu se dá zjistit jednak funkcí getsockopt(), druhak i bez ní jednotlivá výše zmíněná volání "končí chybou" tím způsobem, že v souladu s manuálovou stránkou vrátí "chybovou" návratovou hodnotu (třeba recv() vrací 0 bajtů přijato, jiné funkce mohou vracet přímo chybový kód se znaménkem mínus) - vedle návratové hodnoty bývá současně k dispozici globální proměnná errno, kterou lze interpretovat na textovou zprávu (řetězec) funkcemi strerror() nebo perror()... k tomu všemu jsou v linuxu man pages.