Forum Turris
Fórum Turris Nápověda

Milí majitelé routerů Turris,

toto fórum bylo 9. 12. 2016 zmrazeno a nahrazeno naším novým Turris fórem. Ještě chvíli bude dostupné k prohlížení, ale již zde není možné přispívat. Více informací naleznete v oznámení o uzavření fóra.

Dear Turris routers users,

this forum has been frozen on Dec 9th, 2016 and replaced by our new Turris forum. It will be read-only accessible for some time after. For more information, read the announcement about closing the forum.

Nahoru Téma Majitelé routerů / Technická podpora / Zachycené firewallové pakety
- - Od jro Dne 2014-04-23 08:40
Docela me prekvapilo, kdyz jsem v zachycenych firewallovych paketech videl jako nejcastejsi IP 217.66.161.8 - coz je muj voip provider (ha-loo).
Na voip adapteru mam nastavene 'keep NAT alive' posilanim paketu kazdou tusim minutu, prichozi i odchozi hovory funguji ok - a nejak me nenapada, proc by mi SIP server mel posilat neco (jineho?) co by firewall v Turrisu citil potrebu zahodit ...  ?
Nadřazený - - Od Štěpán Henek Dne 2014-04-23 09:32
Dobrý den,

Turris loguje packety, které firewall zahodí. Nejspíš by se mělo jednat o pakety ve směru server -> router u nenavázaného spojení.
Pro hlubší zkoumání by bylo dobré se podívat do /var/log/iptables a zjistit, co jsou vlastně ty packety zač (TCP, UDP, port, ...)
Nadřazený - - Od jro Dne 2014-04-23 19:05
hm - behem hovoru (a jenom behem hovoru) FW Turrisu zahazuje tyhle pakety (viz dole), pricemz porty 16500 az 16600 mam ve voip adapteru (SPA 3102) vyhrazene pro RTP (tj jde po nich hlas). Odpovida to i tomu, ze v rozhrani voip adapteru narusta rozdil mezi Call 1 Packets Sent a Call 1 Packets Rcv - zhruba 1 promile paketu se ztrati na FW turrisu.

nasleduji moje spekulace :)
Mam za to, ze tyhle pakety jsou soucasti nejake komunikace - i kdyby voip server (217.66.161.8) vygeneroval nejaky takovy RTP paket (ktery neni jen odezvou na nejaky iniciovany na me strane) a FW by mel jasny duvod ho zahodit, tak jak Turris vi na jaky port to ma prelozit? A preklad se ocividne snazi delat spravne - vzdy do portu z rozsahu 16500-16600.

Ok - uplne extra me to moc nepali, protoze 1 promile ztracenych paketu kvalitu hovoru neovlivni ... spise me to zaujalo a muj stary router tohle nedela (Call 1 Packets Sent a Call 1 Packets Rcv  jsou na voip adapteru skoro stejne). Ma to nejake rozumne zduvodneni?
dik 
2014-04-23T19:44:11+02:00 [85981.325680] turris-000000: IN=eth2 OUT= MAC=d8:58:d7:00:04:a3:00:0c:42:49:1f:67:08:00 SRC=217.66.161.8 DST=(moje_verejna_ip) LEN=92 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=13589 DPT=16535 LEN=72
Nadřazený - - Od Štěpán Henek Dne 2014-04-24 09:38
Dobrý den,

na mě to působí tak, že ten voip server se snaží připojovat na porty z rozsahu 16500...16600 přímo na vaši veřejnou IP.
Co vám během připojení říká
netstat -uan
případně
netstat-nat -np udp
Jsou ty zahozené packety součástí nějakého navázaného spojení?

Neměl jste u předchozího routeru nastavený port forward daného rozsahu na ten voip adaptér?
Nadřazený - - Od jro Dne 2014-04-27 11:44
jsem se v tom hrabal, ale ocividne tomu nerozumim :(
netstat mi ani behem pripojeni neukazuje zadne relevantni spojeni a navic neni zadny rozdil jestli se divam behem hovoru nebo ne

Proto Recv-Q Send-Q Local Address           Foreign Address         State
udp        0      0 0.0.0.0:53                       0.0.0.0:*
udp        0      0 0.0.0.0:67                       0.0.0.0:*
udp        0      0 (moje_verejna_ip):123       87.236.195.213:123      ESTABLISHED
udp        0      0 :::547                             :::*
udp        0      0 :::53                              :::*

a ani v tcp toho neni vice (v raw taky ne). Neco ocividne nechapu, protoze na portu 5060 posilam kazdych 15s paket na muj sip server abych udrzel zive spojeni (overena metoda aby se mi dalo dovolat) - tohle bych cekal, ze nekde uvidim.
Ale ano - voip server by mel behem hovoru neco posilat na porty 16500-16600 (RTP pakety), ale ty by mely byt soucasti nejake komunikace a jako takove nezahozene fw. Nakonec hovor probiha a slysime se.
To vypada jako kdyby voip server na zacatku hovoru dostal rozsah portu pro RTP a behem hovoru se obcas sam snazil port zmenit - a takovy paket je potom zahozeny fw. Nicmene to mi prijde jako ponekud divoka konstrukce ... navic tuhle komunikace nevidim nikde v netstat (co sakra delam blbe??) aby se podival na aktualne pouzite porty a mohl tak overit, ze se meni..
Nadřazený - - Od Štěpán Henek Dne 2014-04-27 18:46
Hmm, pokud to nezobrazuje netstat, zkuste se podívat do /proc/net/nf_conntrack.
Nadřazený - - Od jro Dne 2014-04-27 19:26
jasne ! tam je behem hovoru to, co bych ocekaval: prvni radek je rtp (hovor, v tomhle pripade na portu 16588), druhy sip (signalizace, tu mam u sebe na portu 5061)

ipv4     2 udp      17 179 src=10.0.0.2 dst=217.66.161.8 sport=16588 dport=11026 packets=538 bytes=107600 src=217.66.161.8 dst=10.14.34.10 sport=11026 dport=16588 packets=539 bytes=107800 [ASSURED] mark=0 use=2

ipv4     2 udp      17 174 src=10.0.0.2 dst=217.66.161.8 sport=5061 dport=5060 packets=21252 bytes=8644911 src=217.66.161.8 dst=10.14.34.10 sport=5060 dport=5061 packets=21244 bytes=8167957 [ASSURED] mark=0 use=2

pricemz fw zahazuje

2014-04-27T20:15:30+02:00 [164695.021450] turris-000000: IN=eth2 OUT= MAC=d8:58:d7:00:04:a3:00:0c:42:49:1f:67:08:00 SRC=217.66.161.8 DST=(moje_verejna_ip) LEN=200 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=11026 DPT=16588 LEN=180

10.0.0.2 je vnitrni adresa voip adapteru. Vypada to, ze tenhle konkretni hovor bezi na portu 16588, taky se normalne slysime ... akorat fw se rozhodne nejaky paket obcas zahodit...? (coz je asi blbost, nejaky duvod mit bude. Nakonec mi pripada podobne jako vyse uvedeny priklad s web serverem a portem 80 ... ?)
Nadřazený - - Od Štěpán Henek Dne 2014-04-28 07:58
Podle mě to nějaký důvod určitě má.
Zkuste si přidat následující pravidlo:
iptables -I zone_wan_input -m state --state INVALID -j LOG --log-prefix "INVALID_PACKET"
a podívat se do /var/log/messages

Jinak v tom zalogovaném packetu mi přijde hodnota ID=0 poměrně zvláštní...
Nadřazený - Od jro Dne 2014-04-28 17:49
tohle pravidlo nic relevantniho neloguje (funguje, ale loguje jen zahozene pakety z uplne jinych IP)
kdyz to pravidlo ale zmenim na

iptables -I zone_wan_input -m state --state NEW -j LOG --log-prefix "NEW_PACKET"

tak razem vidim

2014-04-28T18:38:53+02:00 warning kernel[]: [72103.860881] NEW_PACKETIN=eth2 OUT= MAC=d8:58:d7:00:04:a3:00:0c:42:49:1f:67:08:00 SRC=217.66.161.8 DST=(moje_ip) LEN=92 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=19079 DPT=16507 LEN=72

mozna za to muze RTPC (http://en.wikipedia.org/wiki/RTP_Control_Protocol) ... tj ze by si sip server posilal nejake pakety (RTPC) ...? (ale to jen spekuluji, o voip toho tolik nevim)
asi by 'pomohlo' otevrit pro jednu ip adresu sip serveru a mnou zvolene RTP porty - ale proc, kdyz nevypada, ze by to necemu vadilo.
- Od JFila (>>) Dne 2014-04-25 08:23
Chápu grafy z routeru správně, že se jedná o zahozené pakety? Proč se zahazují pakety na portu 80, když mám na tomto portu povolený web server a z internetu normálně funguje? Je možné ještě doplnit grafy pro přijaté pakety?
Nahoru Téma Majitelé routerů / Technická podpora / Zachycené firewallové pakety

Powered by mwForum 2.29.3 © 1999-2013 Markus Wichitill