Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Internet a sítě => Téma založeno: Kreny 24 Října 2008, 18:17:14
-
Zdravim, damy a panove,
mam problem:
Doma mam lokalni sit, o kterou se mi stara AP . na WAN portu je pevna IP, na LAN a WIFI pak klasicke 192.168.1.xxx
Vsechno bylo OK, az na vcerejsek.
Vcera jsme v ramci pokroku presli na televizi/telefon pres internet a nas provider to vyresil tak, ze donesl 5-ti portovy switch za 170 korun a nastrkal do neho dve televize a telefon (celkem 3 porty), jejich internet (4. port) a zbyl mi jen jeden port. Ten jsem spojil s WAN portem meho AP, v ifconfigu jsem memu AP rekl, ze na WAN ma pripojeny 100Mbit FullDuplex (protoze se to nejak detekovalo jako 10mbit a cele to pak jelo desitkou) a byl jsem spokojeny, ze sve jede.
Problem ale je, ze kdyz se zapnou obe televize, tak jejich switch tupe posila na ostatni 4 porty veskerou komunikaci a me to nejak zahlti moje AP a temer se nedostanu na Internet. Muzete mi prosim nekdo poradit, jak mam pomoci iptables (nebo cehokoli jineho:) rict memu AP, at ignoruje vsechno krom paketu smerujicich na IP toho AP? (ja poctive googlil a uz mi z toho jde hlava kolem a nic nenachazim)
Nebo jeste jinak, v cem jinem by mohl byt problem, pokud by se to nevyresilo filtrem v iptables ?
Dekuji za pomoc
-
hm,
1. mas nejaku moznost konfigurovat ten switch co si dostal? napr. cez web management a pod., ci tam nie je nejaka moznost vypnut prijem z ostatnych portov. kazdopadne sa mi to podla toho co pises zda skor ako hub, a nie switch.
2. prip. ako to zastavit pomocou iptables? vies nejako identifikovat komunikaciu z ostatnych zariadeni? ci uz maju nejaku IPcku, MAC adresu a pod.? to by sa potom dalo blokovat priamo na tom AP WAN vstupe - ak ti to samozrejme AP umozni.
-
Ahoj,
diky za rychlou odpoved.
AD1, Ten jejich "switch" je samozrejme jen hub, hloupa krabice, co posila vsechno na vsechny bez moznosti volby.
AD2, Presne tohle potrebuji. Z toho hubu vedou draty na settop boxy, ktere maji svou vlastni IP a taky na muj AP, ktery ma svoji IP. Takze bych potreboval pomoc s tim, co mam napsat (pravdepodobne) do iptables, aby na WAN portu AP zahazovalo vse, krom paketu urcenych primo pro IP toho AP.
-
Vůbec se nemusím jednat o HUB, ale klidně o switch, jen je TV šířena jako stream nad multicastem na 224.0.0.1 - tím pádem by router měl takovou komunikaci poslat všem multicastovým strojům, o což se docela klidně může snažit. V iptables prostě na AP jednoduše udělejte
iptables -A INPUT -p ALL -d 224.0.0.1 -j DROP
Nicméně se trochu bojím, že pokud nezvládá AP jako takové, tak problém bude přetrvávat. Pokud jde jen o zahlcení bezdrátové části, tak by to mělo pomoci.
-
Ja to trochu upresnim. Opravdu se jedna o switch, je to konkretne typ "LevelOne 5 Port Switch". Ty settop boxy maji kazdy svou vlastni IP.
Kdyz je pustim, muj tcpdump na AP vidi tohle (samozrejme se to opakuje porad dokola):
00:03:48.264700 IP 172.20.0.222.49152 > 239.0.0.1.5000: UDP, length 1316
00:03:48.265088 IP 172.20.0.222.49152 > 239.0.0.4.5000: UDP, length 1316
Muzete mi prosim Vas priklad aplikovat na tohle ? Ja to zkousel a nepomohlo mi to, za provozu televizi se nedostanu ani na AP, natoz dale do internetu.
V pripade, ze budu muset jejich uber switch vymenit za nejaky chytrejsi, jaky byste mi doporucili ? A nebude se situace opakovat ? Nezahltli to prozmenu ten switch ? A jak se to vlastne potom resi ?
Diky za odpoved
-
Je to úplně jedno, co tam dáte za switch. Bude fungovat naprosto identicky. LeveOne produkty jsou vcelku dobré a funkční řešení.
Předpokládám, že 172.20.0.222 je IP jednoho sboxu?
iptables -A INPUT -p ALL -s 172.20.0.222 -j DROP
možná by bylo vhodné přidat i druhý směr
iptables -A INPUT -p ALL -d 172.20.0.222 -j DROP
-
Vůbec se nemusím jednat o HUB, ale klidně o switch, jen je TV šířena jako stream nad multicastem na 224.0.0.1 - tím pádem by router měl takovou komunikaci poslat všem multicastovým strojům, o což se docela klidně může snažit.
isteze, ja som nepisal ze to je hub, ale ze mi to podla sposobu komunikacie pripominalo skor hub.
a co sa tyka toho TV streamu, tak zatial som sa s takymi vecami nehral, preto som netusil ze to lieta cez multicast.
Ja to trochu upresnim. Opravdu se jedna o switch, je to konkretne typ "LevelOne 5 Port Switch". Ty settop boxy maji kazdy svou vlastni IP.
Kdyz je pustim, muj tcpdump na AP vidi tohle (samozrejme se to opakuje porad dokola):
00:03:48.264700 IP 172.20.0.222.49152 > 239.0.0.1.5000: UDP, length 1316
00:03:48.265088 IP 172.20.0.222.49152 > 239.0.0.4.5000: UDP, length 1316
Muzete mi prosim Vas priklad aplikovat na tohle ? Ja to zkousel a nepomohlo mi to, za provozu televizi se nedostanu ani na AP, natoz dale do internetu.
tak podla tejto komunikacie by som do AP natlacil asi nasledovne:
iptables -A INPUT -p udp -d 172.20.0.222 -j DROP
hm, ako vidim si ma predbehol, neva :)
este ma napadlo ze by sa mohla pridat aj varianta s bloknutim podla MAC adresy
si cez arp -a zisti MAC adresy ostatnych zariadeni
a ich potom uz len jednoducho pridaj do pravidla:
iptables -A INPUT -p udp -m mac --mac-source {MAC adresu} -j DROP
-
Já mám jen trochu strach, že problém bude v přetěžování vlastního CPU té krabičky a -j DROP packet stejně zpracuje a zařadí. Takže mám trochu strach, že to to AP prostě nezvládá.
-
Hezky vecer,
ohledne IP settopboxu, tak podle me to budou takto :
00:03:48.264700 IP 172.20.0.222.49152 > 239.0.0.1.5000: UDP, length 1316
00:03:48.265088 IP 172.20.0.222.49152 > 239.0.0.4.5000: UDP, length 1316
tucne by mely byt sboxy a kurzivou by mel byt nejaky jejich server, ktery mi posilala digitalni televizi.
tcpump jsem provedl na WAN portu meho AP, takze podle me switch posila jeden stream na 239.0.0.1 a druhy na 239.0.0.4 ... ale posila to na vsechny porty, takze me to zatezuje AP (jedna se o Asus WL500G DeLuxe s OpenWRT vevnitr).
Strojovy cas nutny pro zahozeni paketu pres iptables a nebo pro vyhodnoceni, zda je na LAN pripojena tato IP je asi podobny, co ? :(
Da se s tim neco delat? Slo by treba poridit si nejaky programovatelny switch a rict mu, ze na portu x ma poustet pouze pakety pro x, na y pro y a podobne ? Nebude mit zase problem ten switch to zvladnout ? (bavime se o lidovych switchich, ne o nejake masine za x desitek tisic:)
Dekuji za odpoved a dekuju za reakce a pomoc
-
Obávám se, že switch toto nezvládne. Rozhodně ne lidový :)
Upravte IP dle potřeby v těch příkazech a vyzkoušejte - za to nic nedáte.
WL500G je dobrý kus železa, ale CPU vevnitř je přeci jen hodně slaboučké - mám dojem je tam Broadcom BCM470 někde kolem 250MHz, ne? Bohužel mám zkušenosti, že ani mikrotik na tom není o moc lépe.
-
zadal jsem do AP :
iptables -A INPUT -p udp -d 172.20.0.222 -j DROP
a bohuzel vysledek je stejny. Zde prikladam par radek z top, kdyz jedou obe televize
Mem: 8400K used, 22116K free, 0K shrd, 844K buff, 2584K cached
Load average: 0.07, 0.05, 0.01 (State: S=sleeping R=running, W=waiting)
PID USER STATUS RSS PPID %CPU %MEM COMMAND
566 root R 400 563 1.3 1.3 top
562 root S 588 517 0.7 1.9 dropbear
3 root RWN 0 1 0.3 0.0 ksoftirqd_CPU0
563 root S 440 562 0.0 1.4 ash
--> dle toho to (podle me) nevypada, ze by nestihalo CPU meho AP. Nemuze to byt velke sousto pro sitovku ? Jako ze sitovka ktera se stara o WAN neni schopna pojmout tolik komunikace ? Dalo by se ji nejak pomoci urcitym nastavenim ? V tomhle se nevyznam, tak se asi ptam hloupe :)
-
grrr ... to přeci není možné :D
sudo iptables -A INPUT -s 224.0.0.0/8 -j DROP
sudo iptables -A FORWARD -d 224.0.0.0/8 -j DROP
sudo iptables -A FORWARD -s 224.0.0.0/8 -j DROP
sudo iptables -A OUTPUT -d 224.0.0.0/8 -j DROP
sudo iptables -A INPUT -s 239.0.0.0/8 -j DROP
sudo iptables -A FORWARD -d 239.0.0.0/8 -j DROP
sudo iptables -A FORWARD -s 239.0.0.0/8 -j DROP
sudo iptables -A OUTPUT -d 239.0.0.0/8 -j DROP
-
to je fakt divne.
co tak namiesto blokovania roznych zdrojov bloknut rovno vsetko co ide na AP:
iptables -P INPUT DROP
iptables -A INPUT -s 127.0.0.1 -i lo -m state --state NEW -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-
ja jsem na AP sshcknutej jako root, ale i tak mi to moc nepomohlo, asi mi to nezvlada APecko :(
V tom pripade jake navrhujete nejschudnejsi reseni ? (a omlouvam se, ze s tim porad otravuju:)
-
Jeste jedna vec mi prisla na mysl. Nevim, jaky datovy tok ma televize pres internet. Dejme tomu, ze maximalne 10mbit/s . To prece neni mozne, aby AP nezvladlo vyhodnotit 10mbit/s informaci ? Internet mam sam o sobe 25 mbit a kdyz jsou televize vypnute, tak to sviha jak ma ... a kdyz jede televize, tak ani nenactu www stranku. Nemohl by byt pes zakopan uplne nekde jinde ?
-
Kreny: jo, sorry, to je deformace :D
8472: nápad dobrý, ale s tímhle trochu bacha - řekl bych, že se na to AP chce alespoň z vnitřku ještě někdy dostat :)
takže bych to minimálně trochu upravil:
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Ještě dodám, že by asi bylo fajn dát si to do nějakého .sh scriptu, aby nedošlo ke vtipu, že se po prvním řádku odříznete od AP :)
místo eth0 samosebou dejte název rozhraní na kterém je vnitřní rozsah - mám pocit, že openwrt to nějak bridguje, tak fakt nevím.
ad. předchozí příspěvek - problém je, že multicast jsou miliardy maličkých UDP paketů, protože je snaha, aby případná ztráta paketu měla co nejmenší dopad na výsledný obraz/zvuk. Narozdíl od TCP se nevyžaduje ověření přijetí paketu (a z toho plynoucí snížení rychlosti vysílání protistrany atp. - viz. specifikace TCP a UDP). Proto se UDP provoz špatně tvaruje a dělá ISP problémy, protože jediné, co může udělat je pakety zahazovat tak, aby rychlost přenosu odpovídala tomu, co garantuje, ale bohužel nesníží vytíženost vlastních spojů, protože UDP prostě "teče co to dá". Takže u vašeho AP není problém v rychlosti přenosu dat, ale v množství paketů přenesených.
-
Prijde mi, ze jakekoliv zahazovani paketu tvuj problem nevyresi. Uzkym hrdlem je evidentne ta cast site mezi televizema, internetem a tvym AP. Pakety muzes zahazovat jak chces (a mozna to ten AP dela uz ted, jelikoz proc by je posilal do jine site, ze?), nicmene dokud budou ty televize zahlcovat prenosove pasmo, tak tam moc jinych paketu neprocpes. Ja byt tebou, tak se obratim na toho providera, co vam takove skvele reseni nabidnul.
-
kkaarreell: prosím, přečtěte si první příspěvek, kde je popsáno, kterak jsou všechna zařízení propojena - 10/100 switchem, úzké hrdlo dozajista tento switch nebude (samosebou pokud není umřetý, což nepředpokládám). Tuším, že hrdlem nebude ani Internet, neb to by bezproblémově nefungovaly televize. Než začnete osočovat providera, podívejte se prosím na řešení ostatních providerů poskytujících zároveň TV - mimo jiné i o2 - kterak mají toto řešené. Zjistíte, že naprosto identicky (jen u o2 je místo switche externího switch integrovaný v routeru). Pokud máte jiné řešení, kterak na jednom UTP kabelu (omezme se na 4 žíly) poslat pomocí klasického protokolu IP TV/radio/VoIP a oddělit je na straně zákazníka dříve, podělte se prosím o tuto zkušenost. Jsem si jist, že za nějaké jiné řešení Vám ISP utrhají ruce (a já budu v čele), protože síť je multicastem opravdu vytěžována a řešení bývá problematické.
Kreny: Nicméně jednu myšlenku opravdu předchozí příspěvek přinesl - zkuste místo AP připojit do switche přímo libovolný PC a nastavit jej tak, jako by to bylo AP (tj. nastavit IP adresu, případně jen klonovat MAC, pokud získáváte IP od ISP ze serveru DHCP).
-
8472: nápad dobrý, ale s tímhle trochu bacha - řekl bych, že se na to AP chce alespoň z vnitřku ještě někdy dostat :)
samozrejme, som to bral akosi automaticky, a zabudol napisat upozornenie k tomuto moznemu problemu, aby si absolutne neodfajcil pristup k AP.
kazdopadne, experimentovat s tym moze, ak prida do crontabu ulohu aby sa mu napr. po pol hodine zrusili iptables nastavenia - prikazmi:
iptables -F && iptables -X
je to dobra "zaloha" pre pripad ze by si fakt odfajcil ten pristup k AP
-
Petr Merlin Vaněček:
No, tak to zkusim jeste jednou. Pochopil jsem, ze sit vypada nasledovne:
|---- TV1
|
internet-------------- TV2
|____ telefon
|
|------ AP --> LAN (s WiFi)
Chcete rict, ze ty multicast pakety putuji i do jeho LAN site (skrz AP)?
Pokud ano, tak to mi prijde opravdu divne (dle meho nazoru by se to tak chovat nemelo) a v tom pripade jsem neco nepochopil.
Pokud ne, tak jakekoliv nastavovani zahazovani paketu na AP nema smysl, jelikoz to jiz AP davno dela (proste ty pakety dal do LAN neposila).
A pak je otazkou, proc se pakety z LAN nedostanou ven (a naopak). A napada me jedine vysvetleni a to, ze to proste nestihaji, jelikoz je sit na druhe strane zahlcena (treba i kvuli umretemu switchi).
Btw, ja bych nezkousel zapojovat pc misto AP, ale naopak bych vrazil jedno PC misto jedne televize a zkousel pri zapnute telce rychlost komunikace PC<->LAN (pres AP), PC<->internet a LAN (pres AP)<->internet.
A co se tyce osocovani providera, tak oni casto naslibuji hory doly. Nebyl by to prvni pripad, kdy sluzba nedosahuje slibenych parametru. A co se poptat u sousedu, jak jsou na tom oni?
-
Dobry rano,
sit vypada presne tak, jak kkaarreell "nakreslil".
Vcera jsem zkousel misto AP pripojit PC s pevnou IP, zapnout obe televize a internet bezel jak mel (plnou rychlosti, takze ten switch zvladne utahnout dve telky s internetem).
Az se dnes vratim z prace, tak zkusim dat misto telefonu PC a zjistit, jak rychle mi to jede PC#1 --> AP --> PC#2 pri zapnutych televizich, ale obavam se, ze se ani nepingnu.
Ohledne myslenky, kterou psal Petr Merlin Vanecek (miliarda paketu), ma cenu zkusit vygenerovat traffic na vnitrni siti nebo pri propojeni PC#1 --> AP --> PC#2 a pak to same zkusit s pouzitim jineho AP (samozrejme lidoveho, muzu mit jedno AP od Linksysu) ? Mam na mysli to, jestli AP v cenovych relacich kolem 1500 se mohou lisit tak vyrazne, ze treba Linksys to zvladne levou zadni ? Pokud to cenu ma, tak mohl byste nekdo napsat skriptik, jak toho dosahnout (posilat UDP pakety porad dokola) ?
Jinak provider se divil, ze si nekdo dovolil mit doma lokalni sit a na internet pristupovat pres AP. Tuhle sluzbu ted zavadeji a nemaji s tim zkusenosti, takze se vlastne ani nemam kde poptat :)
Vsem moc dekuji za stavajici a budouci reakce
-
Petr Merlin Vaněček:
No, tak to zkusim jeste jednou. Pochopil jsem, ze sit vypada nasledovne:
|---- TV1
|
internet-------------- TV2
|____ telefon
|
|------ AP --> LAN (s WiFi)
Chcete rict, ze ty multicast pakety putuji i do jeho LAN site (skrz AP)?
Pokud ano, tak to mi prijde opravdu divne (dle meho nazoru by se to tak chovat nemelo) a v tom pripade jsem neco nepochopil.
Ale kdepak - multicast packety se do LAN sítě vůbec nedostanou, problém je řekněme zjednodušeně na WAN portu AP. Prostě to nezvládá.
Switch i vše ostatní bude ok (což potvrdil test s připojeným PC místo AP), jen to AP bohužel nedokáže na portu zpracovat tak velký počet UDP paketů (proč jsou tam a ne jen na portech s TV je snad jasné - pokud ne, přečtěte si pár věcí ohledně UDP provozu a multicastu).
-
ano, souhlasim, nyni je evidentni, ze nezvlada AP. a stejne tak je evidentni, ze jakekoliv zahazovani paketu na AP nic neresi a je treba vykonejsi AP.
-
Moje stavajici AP je ASUS WL500G DeLuxe. Muzete mi prosim poradit neco vykonnejsiho ? Nebo nesel by nahradit switch providera nejakym routerem, kteremu bych rekl, aby na port, na kterem je AP, nic takoveho neposilal ? Nezahti to prozmenu ten router ?Z prace si muzu pujcit Linksys WRT45GL ,ale to asi bude vykonove velice podobne :(
-
Tuším, že nebude problém přímo s výkonem WL500G, ale nastavením iptables na dané iface. Pošlete sem prosím výpis
iptables -L
iptables -t nat -L
Možná tam bude nějaký burst kvůli ochraně před DoS. Teoreticky by se dal vypnout. Myslím, že pokud použijete originální FW, nebo jiný router, vše pojede. Ale je to jen odhad.
-
Tady jsou (snad to pisu spravne do kodu, teprve se ucim:) )
iptables - L
Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP tcp -- anywhere anywhere tcp option=!2 flags:SYN/SYN
input_rule all -- anywhere anywhere
input_wan all -- anywhere anywhere
LAN_ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
ACCEPT gre -- anywhere anywhere
REJECT tcp -- anywhere anywhere reject-with tcp-reset
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
DROP udp -- anywhere 172.20.0.222
Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
forwarding_rule all -- anywhere anywhere
forwarding_wan all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain LAN_ACCEPT (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy DROP)
target prot opt source destination
DROP all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
output_rule all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
REJECT tcp -- anywhere anywhere reject-with tcp-reset
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain forwarding_rule (1 references)
target prot opt source destination
Chain forwarding_wan (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere 192.168.1.101 tcp dpt:20001
Chain input_rule (1 references)
target prot opt source destination
Chain input_wan (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:22
Chain output_rule (1 references)
target prot opt source destination
iptables -t nat -L
Chain NEW (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere limit: avg 50/sec burst 100
DROP all -- anywhere anywhere
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
NEW all -- anywhere anywhere state NEW
prerouting_rule all -- anywhere anywhere
prerouting_wan all -- anywhere anywhere
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
postrouting_rule all -- anywhere anywhere
MASQUERADE all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain postrouting_rule (1 references)
target prot opt source destination
Chain prerouting_rule (1 references)
target prot opt source destination
Chain prerouting_wan (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:22
DNAT tcp -- anywhere anywhere tcp dpt:20001 to:192.168.1.101:20001
jedine, co tam mam ja navic oproti defaultu je forwardovani na 192.168.1.101
-
Zkusíme to tedy trochu "popohnat"
Když pominu ty synflagy atp. tak by mohlo pomoci toto:
iptables -t nat -D NEW -j RETURN -m limit --limit 50/s --limit-burst 100
iptables -t nat -I NEW -j RETURN -m limit --limit 10000/s --limit-burst 10000
-
Ja to zkusim jakmile se dostanu domu z prace. Neni problem to dat do AP, ale bohuzel ty televize odsud nezapnu :) Kolem 16-17 hodiny to zkusim a pak sem zareportuji vysledek. Mockrat diky za pomoc, zatim preji hezky den :)
-
Jede to !!!
iptables -t nat -I NEW -j RETURN -m limit --limit 10000/s --limit-burst 10000je lek na nemoc, kterou melo moje AP. Mockrat dekuju vsem, kteri se do tohoto fora zapojili, proste tohle forum je v nasich luzich a hajich nejlepsi :)
btw, jak mam ted nastavit, ze je to vyreseno ?
-
.. proste tohle forum je v nasich luzich a hajich nejlepsi :)
<< ;) ok .. uz se tesim, az ti budu moct priste odpovedet nejake zverstvo typu UTFG a nebo RTFM
btw.)
merlin je tu nejlepsi pres sitovani
khareel je zase obavany expert na bash
ja jsem zde nejlepsi pres zkratky (znam i jine ;)) misto odpovedi ..
ps. ale je tu i par dalsich dalsich expertu se svymi nou-hau .. ono takove `dpkg-reconfigure xserver-xorg` casto pomuze i na problemy se siti
-
no ne, vazne, moc si te pomoci vazim, protoze bez tehle lidi (a tech, co pisou RTFM a neprimo tak nuti ostatni cist manualy, aby jim na foru nekdo takhle nevynadal ) by ten Linux byl neprekonatelny pro vetsinu beznych lidi (ikdyz ktery bezny clovek pouziva Unix/Linux, ze jo :) ) Kazdopadne kde mam teda kliknout, aby se tam napsalo "(vyreseno)" ? :)
-
Kreny:
super :) Ani netušíte, jakou mám radost ;) :D
S dovolením jsem [vyřešeno] nastavil sám. Mimochodem, dělá se to tak, že se upraví nadpis u prvního příspěvku.
nettezzaumana:
haha, nepovídej, jak je to dlouho, co jsme dávali dokupy prosté otevření portu?
btw. netušil jsem, že tenhle thread sleduješ? ;)
-
sleduju vsechny thready, diky nimz se mam sanci neco dozvedet ;)
jakmile se jedna o iptables a zamichas se do toho ty .. no, sak jsem si i zaguglil co to vlastne pises za odpovedi ;)
btw .. proste otevreni portu jsme davali dohromady, pac jsem jak male dite trval na tom, aby to bylo on-the-fly .. umel jsem sam od zacatku editovat svuj firewall a otocit ho ..
-
Já? Prostý pobíječ much?
-
.. a imho se nam to nepovedlo, pac ja stale nevim, jak si otevrit port na mem bezicim fw bez toho, aniz bych musel zapsat prislusne pravidlo na prislusnou pozici ve skriptu a restartovat celou sluzbu ..
-
Kurňa nezlob :)
Napíšu ti to tedy ještě jednou:
iptables -A INPUT -p [proto] --dport [port] -i [iface] -j ACCEPT
proto = tcp/udp/icmp/all
port = buď číslo, nebo název protokolu dle iana http://www.iana.org/assignments/protocol-numbers
iface = lo,ethX,wlanX,athX,...
přičemž pokud máš na serveru jen jedno rozhraní (nebo dvě a více, ale to druhé a ostatní je/jsou bez nebezpečí), můžeš vynechat -i ...
Akorát nemůžeš testovat otevřenost portu bez služby, která ho obslouží.
-
Kurňa nezlob :)
Napíšu ti to tedy ještě jednou:
iptables -A INPUT -p [proto] --dport [port] -i [iface] -j ACCEPT
proto = tcp/udp/icmp/all
port = buď číslo, nebo název protokolu dle iana http://www.iana.org/assignments/protocol-numbers
iface = lo,ethX,wlanX,athX,...
přičemž pokud máš na serveru jen jedno rozhraní (nebo dvě a více, ale to druhé a ostatní je/jsou bez nebezpečí), můžeš vynechat -i ...
Akorát nemůžeš testovat otevřenost portu bez služby, která ho obslouží.
hmm .. mas pravdu ty parchante ;)
njn. mam se jeste co ucit
-
hmm .. mas pravdu ty parchante ;)
njn. mam se jeste co ucit
Učit ode mne? Já nic neumím. Jen jsem občas něco pochytil :)
-
Kreny:
super Úsměv Ani netušíte, jakou mám radost Mrknutí Smích
S dovolením jsem [vyřešeno] nastavil sám. Mimochodem, dělá se to tak, že se upraví nadpis u prvního příspěvku.
vyborne, dekuji :) Nebudu Vas dva rusit, preji hezky vecer a jeste jednou diky !
-
Kreny:
super Úsměv Ani netušíte, jakou mám radost Mrknutí Smích
S dovolením jsem [vyřešeno] nastavil sám. Mimochodem, dělá se to tak, že se upraví nadpis u prvního příspěvku.
vyborne, dekuji :) Nebudu Vas dva rusit, preji hezky vecer a jeste jednou diky !
Už jsme OT vyřešili :)
-
Petr Merlin Vanecek:
Teda koukam, co vsechno se v konfiguracich AP objevuje za zverstva. Ale aspon jsem zase o neco moudrejsi. Nicmene rad bych vyuzil teto prilezitosti a take si neco vyjasnil.
iptables -t nat -I NEW -j RETURN -m limit --limit 10000/s --limit-burst 10000Jaky ma smysl nastavovat --limit na 10000? Asi ti slo o to, abys dostatecne naddimenzovat ten limit pro burst, ale v takovem pripade by melo smysl prave navyseni pouze toho --limit-burst, ne? Vzdyt ten --limit nastavuje interval behem ktereho se ten burst vyhodnocuje, takze cim delsi jej zvolis, tim nizsi vlastne klades podminky na "pocet novych spojeni". Ja bych prave jen zvysoval hodnotu --limit-burst, ale nemenil --limit. Nebo se pletu?
Ntz:
khareel je zase obavany expert na bashHa ha, hledam v tom radku ironii, ale asi jsem zrovna prilis opit. Nicmene, jak jiz jiste dlouho tusis, ja zadny expert nejsem. Snazim se byt jen dva odstavce v man bash pred ostatnimi.
-
Petr Merlin Vanecek:
Teda koukam, co vsechno se v konfiguracich AP objevuje za zverstva. Ale aspon jsem zase o neco moudrejsi. Nicmene rad bych vyuzil teto prilezitosti a take si neco vyjasnil.
iptables -t nat -I NEW -j RETURN -m limit --limit 10000/s --limit-burst 10000Jaky ma smysl nastavovat --limit na 10000? Asi ti slo o to, abys dostatecne naddimenzovat ten limit pro burst, ale v takovem pripade by melo smysl prave navyseni pouze toho --limit-burst, ne? Vzdyt ten --limit nastavuje interval behem ktereho se ten burst vyhodnocuje, takze cim delsi jej zvolis, tim nizsi vlastne klades podminky na "pocet novych spojeni". Ja bych prave jen zvysoval hodnotu --limit-burst, ale nemenil --limit. Nebo se pletu?
Ne, nepleteš, jen jsem popadl první hodnoty, které mne napadly :D
-
Ne, nepleteš, jen jsem popadl první hodnoty, které mne napadly :D
no jo, stastnych deset (tisic). nemas jeste nejaky tipy? ze bych si vsadil. ted, kdyz je ta krize, tak by chechtaky prisly vhod.. teda vlastne uplne kdykoliv, krize nekrize.
-
7,15,22,23,40,48,55,57,76,79 - stačí? :) lepší jak random, ne? :)
-
7,15,22,23,40,48,55,57,76,79 - stačí? :) lepší jak random, ne? :)
Tak prd. Stalo me to tricet korun, ale trefil jsi jen jedno cislo. :-(
Petrovi Vaneckovi nikdo neverte. :-D
-
Ty jsi to vážně vsázel??? :D :D :D To vědět, tak poradím lépe :D
-
Vůbec se nemusím jednat o HUB, ale klidně o switch, jen je TV šířena jako stream nad multicastem na 224.0.0.1 - tím pádem by router měl takovou komunikaci poslat všem multicastovým strojům, o což se docela klidně může snažit.
Routování multicastu bych vynechal, to není zrovna triviální věc. V reálu se místo toho dost používá VLAN. Takže se z pohledu multicastu dostaneme jen na switchování. Zajímavé je to v okamžiku kdy do switche přichází na některém portu multicast stream. Průšvih většiny levných switchů je že se k němu chovají jako k broadcastu, tedy že stream přeposílají na všechny své porty. Normálně by si switch měl držet tabulku multicastových group které má na portech k dispozici, a teprv až na některém portu dostane přes IGMP join žádost tak sestaví cestu a začne vysílat vybraný stream i na ten port ze kterého žádost přišla.
Hodně jsem to zjednodušil, podstata je snad ale jasná.
Ještě větší průšvih u domácích krabiček nastane pokud je k tomu broadcastujícímu switchi připojený nebo integrovaný wifi AP. Velké množství krátkých paketů typických pro multimediální streamy ho většinou prostě zahltí.
Je prima že jste to vyřešili softwarově zalevno, jinak switchem který by se korektně choval k multicastu namísto toho za 170,- by se to také vyřešilo.
-
No, podle toho, jak se to vyresilo byl spis problem v tom (muj nazor na vec), ze prislusne pravidlo pro iptables majici mirnit pripadny DOS utok bylo zahlceno pakety pro TV a po dosazeni nastaveneho limitu neumoznovalo navazani novych spojeni iniciovanych z vnitrni site. Osobne si myslim, ze by ani nebylo nutne zvysovat ten limit, ale pouze pravidlo upresnit a pouzivat burst-limit pouze na spojeni prichazejici na rozhrani do WLAN. Pak by nedochazelo k omezovani paketu prichazejicich z vnitrni site. Ale mozna jsem tu situaci spatne pochopil a jsem uplne mimo.