Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: ManNerd 01. 08. 2014, 14:58:55
-
Ahoj,
mel bych takovy dotaz. Mam providera, ktery mi do me vnitrni site dava po ethernetovem kabelu subnet 192.168.1.0/24. Pokud k nemu pripojim jakekoliv klientske zarizeni (pocitac, atd.), dam si IP z jeho rozsahu a pouziji jeho GW (192.168.1.1) jako svou gefault GW, vse funguje jak ma (ping, http provoz, ftp, atd.).
Totez, pokud mezi sve PC a jeho gateeway pripojim zarizeni, ktere pracuje pouze na L2 (switch, APcko v bridge modu).
Problem nastane, pokud dam do sve site cokoliv, co provoz ode me NATuje (treba ja jsem se svym PC v siti 192.168.2.0/24 a NATuji packety na 192.168.1.0/24, ktere mu predavam na jeho GW IP 192.168.1.1). Od tohoto okamziku projde pres providera pouze ping, traceroute, ale provoz z vyssich vrstev, nez L3 neprojde.
Tusim, ze ma zapnute nejake nastaveni na jeho vnitrnim interface, ale netusim co. Neni mi jasny rozdil mezi packetem, ktery vygeneture moje klientske PC a da mu ho primo a timtez packetem, ktery pouze projde routerem a na vystupu se provede NAT tak, aby mel packet SRC IP z rozsahu 192.168.1.0/24.
Proveder pouziva nejaky routerboard od MikroTiku. V mem routeru problem nebude, uz jsem jich zkousel vic (i v jinych sitich), kde funguji bez problemu.
Diky za pripadny tip.
-
Ooops, omlouvam se za nesmyslne preklepy, psano v poklusu. :-)
-
zkus si pohrat s TTL
-
@anonymous:
Diky za odpoved, ale mohl bys s tim TTLkem byt prosim trochu konkretnejsi? Mozna uvazuju, nebo ten mechanismus chapu spatne, ale:
Napr. Win klient defaultne u TCP packetu generuje TTL=128.
Pruchodem pres kazdy router by se mel TTL snizit o 1. Pokud se snazim pristoupit k cili, ktery je ode me cca 20 hopu(coz zkousim), tak nemam sanci TTL vycerpat. Nebo to chapu spatne?
Predtim jsem to neuvedl, ale takhle ta komunikace zhruba vypada. Muze byt tedy tou pricinou nizky TTL?
-
To byl dobrej tip, nejde o to, že by se vyčerpal počet, ale někteří poskytovatelé tak zjišťují, jestli uživatel
nesdílí připojení a ten provoz poté zahazují. Zvednul bych experimentálně o jedna.
-
Aha, diky za vysvetleni. V tomhle to ale nebude, ted jsem to zkousel a muzu mit TTL prakticky libovolny, nahoru i dolu od defaultnich hodnot a nic se nezmeni. Zkousel jsem to i na klientovi, ktery funguje, protoze je pripojeny naprimo do toho subnetu providera (192.168.1.0/24) a i tam muzu s TTLkem menit co chci nahoru i dolu (TTL jsem overoval i wiresharkem), ale kiksne to, az dam TTL fakt nizkou hodnotu, ktera je nizsi, nez pocet hopu k tomu serveru. :-(
Moc mi k tehle teorii nehraje ani to, ze mi provider pousti domu cely /24 subnet a muzu si tam z DHCP vzit kolik adres chci. Ale diky za tip.
-
Pak mi ještě napadá zkusit raději úplně jiný rozsah. Neexistuje ten 192.168.2.0/24 přímo v jeho síti také?
Pak by čistě teoreticky se ta adresa mohla objevit na WAN rozhraní s jinou MAC adresou.
Co takhle 10.x.x.x nebo 172.24.16.x pro klid duše.
-
Když projde traceroute, jaký je výsledek ICMP traceroute na 8.8.8.8? Zajímají mě první tři hopy. To napoví daleko více o síti providera než cokoliv jiného.
Dále - zřejmě jsi před jeden NAT vsadil další NAT, a to ne vždy a ne všude dokáže spolehlivě fungovat. Prostě nedokáže. Nevím, jak moc zde zabředávat do teorie, jak funguje NAT (PAT, SNAT), takže nechám u konstatování, že vkládat jakýkoliv NAT do sítě, o které jinak vůbec nic nevím (= nevím, kolik dalších a jakých NATů v ní je), není úplně rozumné a často to vede ke stavu, jaký jsi popsal.
A poslední věc - může konkretizovat, na co přesně potřebuješ NATovat v síti, ve které máš 254 adres od ISP?
-
@Jan Forman: Nene, tim to neni, zkusil jsem prenastavit vnitrni sit na 10.1.1.0/24 a tentyz vysledek. Ono by to ona nemelo mit vliv, po SNATu je v odchozim paketu stejne zdrojova IP z rozsahu 192.168.1.0/24, z puvodniho packetu by se mela zmenit pouze src IP a sekvencni cislo paketu.
@luk: Ty tracerouty jsem zkousel jak ICMP, tak UDP.
Vysledek prepisu, na tom testovacim prostredi mi nejde net :-)
Takze ty pocatecni HOPy jsou:
10.1.1.1 odezva je OK jak UDP tak ICMP (moje vnitrni eth na routeru - v puvodnim postu jako 192.168.2.1)
192.168.1.1 odezva je OK pouze u ICMP, UDP neprojde (toto je klientska eth providera)
172.22.132.1 odezva je OK jak UDP tak ICMP
172.22.128.1 odezva je OK jak UDP tak ICMP
atd...
Na tom routeru providera, kde je eth rozhrani 192.168.1.1 SNAT bezi, myslim si. Proc by nemely fungovat dva SNATy za sebou? Principielne by to nemel byt problem podle me. Budu rad za jakekoliv nastineni problematickeho scenare. Provozuju tyhle typy konfigurace celkem bezne na ruznych mistech a technologiich a nikde jsem zatim problem nemel, krome tohoto jednoho.
Vice subnetu potrebuji kvuli oddeleni ruznych typu zarizeni (jejich urceni). Na to se routovane subnety hodi pomerne dobre.
-
to je fakt dost podivny
schvalne vem ping z primo pripojenyho stroje a ping ze stroje za NATem (kterej upravuje TTL). podle toho co rikas jeden dostane odpoved a druhej ne, ale podle me by mely bejt uplne stejny (pokud ten primo pripojenej stroj dela ten NAT)
-
10.1.1.1 odezva je OK jak UDP tak ICMP (moje vnitrni eth na routeru - v puvodnim postu jako 192.168.2.1)
192.168.1.1 odezva je OK pouze u ICMP, UDP neprojde (toto je klientska eth providera)
172.22.132.1 odezva je OK jak UDP tak ICMP
172.22.128.1 odezva je OK jak UDP tak ICMP
atd...
Takže je tam aktuálně (minimálně) trojitej NAT, jo? No, já bych šel hledat nového ISP. ::)
-
Tak tak...
Skoro bychom asi chtěli vidět tu trasu celou, tohle opravdu působí extrémně a obvykle už dvojitý NAT na protokolech, které potřebujou nějakou podporu už nefunguje.
Je to hlavně SIP, FTP, RTSP a VPNky apod. tam jsme všichni rádi, že to proleze jedním :)
10.1.1.1 odezva je OK jak UDP tak ICMP (moje vnitrni eth na routeru - v puvodnim postu jako 192.168.2.1)
192.168.1.1 odezva je OK pouze u ICMP, UDP neprojde (toto je klientska eth providera)
172.22.132.1 odezva je OK jak UDP tak ICMP
172.22.128.1 odezva je OK jak UDP tak ICMP
atd...
Takže je tam aktuálně (minimálně) trojitej NAT, jo? No, já bych šel hledat nového ISP. ::)
-
10.1.1.1 odezva je OK jak UDP tak ICMP (moje vnitrni eth na routeru - v puvodnim postu jako 192.168.2.1)
192.168.1.1 odezva je OK pouze u ICMP, UDP neprojde (toto je klientska eth providera)
172.22.132.1 odezva je OK jak UDP tak ICMP
172.22.128.1 odezva je OK jak UDP tak ICMP
atd...
Takže je tam aktuálně (minimálně) trojitej NAT, jo? No, já bych šel hledat nového ISP. ::)
To je rada! Moj ISP je na tom podobne, ale ked nechcem pouzivat velmi nestabilny mobilny internet (signal je slaby), tak nemam na vyber.
Skus sniffnut, co sa deje pri nadvazovani TCP spojenia bez NATu a s NATom. Idealne na nejaky server vonku, kde sniffnes to iste, ale z druhej strany. Potom pohladaj, co chyba a ci si nedostal nejake vysvetlujuce ICMP.
-
Nechápu, proč prostě nezvedneš telefon a svého ISP se nezeptáš. Jaký má smysl nad tím dumat?
-
Nechápu, proč prostě nezvedneš telefon a svého ISP se nezeptáš. Jaký má smysl nad tím dumat?
Taky tomu přestávám rozumět. Lidi už se úplně zbláznili. Viz např. sousední vlákno ohledně zjevně vadného "business" notebooku (http://forum.root.cz/index.php?topic=9489).
-
BTW, v kontraktu s ISP mate napsano, ze se jedna o pripojku k intranetu? Protoze Internet to zretelne byt nemuze.
-
@Mirek Prymek: To uz jsem udelal davno, ale nepochodil jsem. Jedinou odpovedi je, ze podporovane reseni je pouzivat "moje" DHCP. Jenze vzhledem k tomu, ze si o odbornosti tohoto cloveka nedelam valne iluze, litaji mi sem CDP pakety, ikdyz tvrdi, ze STP "nepouziva", navic z brany, kde bezi NAT. Nechci se spolehat na to, ze mi sem jeho vnitrni siti nekdo nepoleze. Ikdyz vzhledem k te "polofunkcnosti", to mozna nebude ani mozne. :-)
Duvodem, proc nehledam jineho providera je to, ze jsem v lokalite, kde jaksi neni vyber. Jsou tu dva, jeden horsi, nez druhy. Druhy ma sice sit pruchozi, ale je to velmi nekorektni spolecnost u ktere se smluvne uvazete i k tomu, kdo konkretne vas v pripade sporu o nefunkcni linku bude soudit (spol. AB-NET, neodpustim si reklamu :-)), mate pravo pouze platit ikdyz vam rychlost lita nahoru a dolu, smlouva se da vypovedet jenom jednou za dva roky. To je ale jina pisnicka a zbytecna diskuse. Spis durazne varovani pro ostatni.
Jak se na to tak koukam, nevim, jestli by nebyl lepsim resenim spise nejaky transparentni firewall.
Zkusim to jeste debugnout proti nejakemu stroji s verejnou IP a napisu, k cemu jsem dospel. Je na to potreba trochu vic casu, ktery ted nemam. Kazdopadne diky za vecne podnety, zejmena Janu Formanovi a a Lukovi.
-
@Jarda P. : Good one! :-)
To tam postupne doskace, intranet je jen prvnich cca 200 hopu. :-)
-
Chápu. Kde nic není, ani smrt nebere :)
Pokud chceš řešit bezpečnost, tak řeš bezpečnost a neřeš NAT. Bezpečnost se řeší firewallem. Co je "transparentní firewall" ale netuším :)
-
Transparentni firewall, resp. transparentni mod firewallu je featura, kterou umi nektere lepsi firewally. Jde o to, ze provadi filtrovani na 2. vrstve a neovlivni stavajicici IP topologii z pohledu 3. vrstvy ISO/OSI. Jsou tam ale nektera omezeni, pramenici z filtrovani ramcu, nikoliv paketu.
Detaily napriklad tady:
http://kb.fortinet.com/kb/viewAttachment.do?attachID=Fortigate_Transparent_Mode_Technical_Guide_FortiOS_4_0_version1.2.pdf&documentID=FD33113
Ze NAT neresi bezpecnost vim, spis mi slo o to, ze jsem potreboval vnitrni sit rozdelit na vice kusu, tedy idealne subnety a routovat mezi nimi. Zaroven odriznout od nechteneho provozu od poskytovatele. Tam je celkem idealnim resenim router ve vnitrni siti, za nim stavovy firewall a NAT, vzhledem k tomu, ze mi provider zpatky nebude routovat moje podsite.
-
Transparentni firewall, resp. transparentni mod firewallu je featura, kterou umi nektere lepsi firewally.
Jo, už jsem si to vygooglil, tenhle termín se ke mně zatím nedostal nebo jsem si ho nezapamatoval, spíš "bridging firewall".
Jde o to, ze provadi filtrovani na 2. vrstve a neovlivni stavajicici IP topologii z pohledu 3. vrstvy ISO/OSI. Jsou tam ale nektera omezeni, pramenici z filtrovani ramcu, nikoliv paketu.
Filtrování čistě L2 rámců by bylo na nic, potřebuješ normální L3 filtrování, akorát ne v rámci routování, ale v rámci bridge. To není žádný problém:
http://www.sjdjweis.com/linux/bridging/
http://people.pharmacy.purdue.edu/~tarrh/Transparent%20Firewall%20-%20Filtering%20Bridge%20-%20William%20Tarrh.pdf
http://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_Firewall
spis mi slo o to, ze jsem potreboval vnitrni sit rozdelit na vice kusu
V tom případě se natu nevyhneš, to je jasný.
Být tebou bych na to šel od podlahy - vysniffovat, jaký pakety od tebe chodí s natem a bez natu a čím se liší. Pokud používáš nějakou pochybnou krabičku na to navtování, je klidně možný, že mění porty na nějakej rozsah, kterej ISP odmítá přijmout... Ověřil bych si, že provoz odchází z "dynamických portů" (49152 až 65535 - viz http://cs.wikipedia.org/wiki/Seznam_%C4%8D%C3%ADsel_port%C5%AF_TCP_a_UDP). Onehdy jsme řešili něco podobnýho - u jednoho ISP nešel odchozí provoz a nakonec se zjistilo, že odcházel z portu, kterej rád používal jakejsi vir, takže ho ISP blokoval... U tebe by to mohlo být něco odbobně stupidního...
-
a nebylo by vůbec nejlepší zmínit jaké zařízení používáš?
-
@Zajdan: Zkousel jsem to uz s vice zarizenima, vsechna se chovala stejne. Ted tady mam Fortigate 60C, u ktereho jsem si pomerne jisty, ze se drzi standardu. Ale souhlasim s Mirkem Prymkem, ze bude potreba vzit to nizkourovnove a porovnat detailne pakety. Dam pak vedet k cemu jsem dosel.
-
Ale souhlasim s Mirkem Prymkem, ze bude potreba vzit to nizkourovnove a porovnat detailne pakety. Dam pak vedet k cemu jsem dosel.
Ono ti ani nic moc jinyho nezbyva - pokud bys koukal na odchozi pakety a na to, jestli ti prijdou nekam na server, tak treba zjistis, ze neprijdou a porad nebudes vedet proc, takze nakonec u inspekce toho odchoziho provozu skoncis...
-
Na tom routeru providera, kde je eth rozhrani 192.168.1.1 SNAT bezi, myslim si. Proc by nemely fungovat dva SNATy za sebou? Principielne by to nemel byt problem podle me. Budu rad za jakekoliv nastineni problematickeho scenare. Provozuju tyhle typy konfigurace celkem bezne na ruznych mistech a technologiich a nikde jsem zatim problem nemel, krome tohoto jednoho.
Vice subnetu potrebuji kvuli oddeleni ruznych typu zarizeni (jejich urceni). Na to se routovane subnety hodi pomerne dobre.
Tak jednak - nenech se zmást, ten výsledek traceroute nic v této situaci neříká o počtu NATů, protože ty další privátní rozsahy mohou být pouze routované, nikoliv NATované (ani není důvod, aby byly, ale věřím, že může existovat "ISP", který takto funguje).
A k více NATům. Opět budu jen stručný - http://en.wikipedia.org/wiki/Carrier-grade_NAT - tohle je velmi záludná věc, která když se neumí správně uchopit, působí velké potíže. Jinak více NATů za sebou postrádá logiku z principu věci - mezi privátními subnety ve své síti je nesmysl NATovat, čistě routované řešení je mnohem výkonnější a transparentnější.
A teď k meritu věci - zapomeň na transparentní firewall. Má různá omezení, dosti pracně se konfiguruje, a zdaleka ne každý firewall umí transparentní režim.
Nevím, jak moc jsi znalý IPv4 adresování a routingu, ale ISP ti poskytuje "velkou" /24 síť (byť privátní rozsah), tak co takhle namísto NATu "rozsekat" subnet /24 na tři menší?
Dejme tomu takhle:
192.168.1.128/26
192.168.1.64/26
192.168.1.0/26
Tyhle sítě nakonfiguruješ na svém routeru a 192.168.1.0/26 necháš jako transit k routeru providera, zbylé dvě jsou pro tvé "izolační" účely, každá zapojená k jinému interface routeru. CIDR zajistí zbytek a mělo by to fungovat jako routovaná, nikoliv NATovaná, topologie. Případně si to můžeš rozkouskovat na ještě více menších kousků, nebo můžeš pro transit vyhradit jenom /30 síť, aby ti zbylo více adres a bloků pro tvoje účely.
A proč to může fungovat?:
Tohle je routovací tabulka na routeru tvého providera platná v tuto chvíli (Cisco-like) - pochopitelně jen ta část, která nás zajímá:
RouterISP#sh ip route
....
....
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/1
L 192.168.1.1/32 is directly connected, GigabitEthernet0/1
Tohle tam prostě je, router musí o prefixu, který ti byl přidělen, vědět. A takhle by vypadala u tebe (Cisco-like):
ManNerdsBox#sh ip route
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
192.168.1.0/24 is variably subnetted, 6 subnets, 2 masks
C 192.168.1.0/26 is directly connected, GigabitEthernet0/1
L 192.168.1.2/32 is directly connected, GigabitEthernet0/1
C 192.168.1.64/26 is directly connected, GigabitEthernet0/0
L 192.168.1.65/32 is directly connected, GigabitEthernet0/0
C 192.168.1.128/26 is directly connected, GigabitEthernet0/2
L 192.168.1.129/32 is directly connected, GigabitEthernet0/2
S* 0.0.0.0/0 [1/0] via 192.168.1.1
Nebudu se pouštět do žádných "velkých akcí" ohledně CIDRu nebo route aggregation, nicméně na CISCO a Linux routerech to mám bezpečně vyzkoušené - běžně se tak segmentují sítě. Navíc tohle bude umět kdejaká krabička z Alzy nebo CZC. Pokud by ani tohle nefungovalo, je zbytečné zkoušet cokoliv dalšího z tohoto ranku - ale to nevím, co by tam musel ISP mít za security.
Závěrem si neodpustím jedno malé "šťouchnutí", ale neber si to osobně - jen konstatování ;) :
CDP, neboli Cisco Discovery Protocol, může běhat i v síti, která o STP (Spanning Tree Protocol) vůbec neslyšela ;). A přítomnost CDP, potažmo LLDP, na routerech není nic zvláštního nebo špatného, protože umí poskytnout poměrně dosti cenné informace o zapojených sousedech, a to se mnoha případech opravdu hodí.
-
A přítomnost CDP, potažmo LLDP, na routerech není nic zvláštního nebo špatného, protože umí poskytnout poměrně dosti cenné informace o zapojených sousedech, a to se mnoha případech opravdu hodí.
A právě proto se na rozhraních, na jejichž druhém konci nejsou "moje" zařízení, zakazuje ;)
-
@Luk: Koukam, ze sis s tim dal praci, diky!
S tim stouchnutim je to na miste, pozdeji jsem si uvedomil, ze jsem placnul blbost, STP samozrejme pouziva BPDU ramce. :-) To je tak, kdyz pisu prispevky s jecicima detma za krkem...
-
A netahá nás tady někdo za nos?
poslouchej....ať si provider vyhrožuje soudama jak chce, ale hned první soud by projel, protože všechny routery pro domácnosti, které se snad i považují jako standard domácích přípojek mají defaultně nastaven NAT a většina z nich neumí fungovat jinak než s NATem, a proto provider nemá šanci obstát a na takového šuli.. bych se okamžitě vy....
-
@Zajdan: To byla jen odbocka k druhemu providerovi, ktery tady pusobi a na ktereho uz jsem se davno vykaslal (AB-NET). Jemu to technicky jakstaks fungovalo, ale parametry linky byly otresne z pohledu kolisani rychlosti, odezvy. A zrusit jeho smlouvu opravdu neni jednoduche, lze to prakticky pouze k dvouletemu vyroci smlouvy, jinak ani rana. Leda ten soudni spor, ale tam mate ve smlouve, ze souhlasite s takovym tim zjednodusenym rizenim, v nemz bude rozhodovat osoba XY. Je otazka nakolik je toto napadnutelne, nejsem pravnik. Kazdopadne na pristup teto firmy si stezuje vicero lidi po internetu a v tomhle vlaknu je to trosku OT. Ten soucasny ISP nema s tim soucasnym, ktereho tady resim nic spolecneho.
-
Eeee, AB-NETem nema nic spolecneho :-)
-
No, tohle chování nemusí být ISPíkem úmyslně konfigurovaný stav.. Bylo psáno, že tam asi má Mikrotik, jakej? Pokud náhodou CRS, tak by mohlo stačit přesvědčit ISPíka, aby udělal uprgade ROSu (nebo ho vyresetoval a nasavit znova). :-)
Pokud tam běhá CDP, které Mikrotik emuluje, tak stačí wireshark a podívat se, co to bonzuje za typ.
Tohle tam prostě je, router musí o prefixu, který ti byl přidělen, vědět. A takhle by vypadala u tebe (Cisco-like):
ManNerdsBox#sh ip route
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
192.168.1.0/24 is variably subnetted, 6 subnets, 2 masks
C 192.168.1.0/26 is directly connected, GigabitEthernet0/1
L 192.168.1.2/32 is directly connected, GigabitEthernet0/1
C 192.168.1.64/26 is directly connected, GigabitEthernet0/0
L 192.168.1.65/32 is directly connected, GigabitEthernet0/0
C 192.168.1.128/26 is directly connected, GigabitEthernet0/2
L 192.168.1.129/32 is directly connected, GigabitEthernet0/2
S* 0.0.0.0/0 [1/0] via 192.168.1.1
Nebudu se pouštět do žádných "velkých akcí" ohledně CIDRu nebo route aggregation, nicméně na CISCO a Linux routerech to mám bezpečně vyzkoušené - běžně se tak segmentují sítě. Navíc tohle bude umět kdejaká krabička z Alzy nebo CZC.
Ano, pokud si tam dá Cisco krabičku, tak to takhle fungovat bude. Pokud si tam dá jakoukoliv z CZC a spol, tak ne. Protože takto nastaveno to předpokládá, že ten domácí router dělá proxy ARP, které je na Ciscu defaultně zapnuto (vypíná se 'no ip proxy-arp' v interface). A spousta krabiček tuhle vlastnost neumí... Bez proxy arp by musel bý ten router u ISP nastaven, aby ty subsegmenty routoval na tu moji 192.168.1.2. Z levných krabiček umí proxy arp třeba ten zmíněný Mikrotik (v základu je vypnuto, zapíná se /interface ethernet set etherX arp=proxy-arp). Jinak detekce a zaříznutí proxy arp je celkem snadné. Tazatel zmiňoval použití nějaké fortinet krabičky, ty proxy arp umí také a asi je v defaultu i zapnuto.
-
Je otazka nakolik je toto napadnutelne, nejsem pravnik.
Pokud vím, tak moc není. Pokud je ve smlouvě určený rozhodce, tak s tím potom už asi nic neuděláš. Ale záleží dost na tom, kdo to je. Pokud nějakej kamarádíček providera, tak je to dost špatný. Občas se ale používá třeba Rozhodčí soud Hospodářské komory - tam asi celkem není čeho se bát.
-
Pokud vím, tak moc není. Pokud je ve smlouvě určený rozhodce, tak s tím potom už asi nic neuděláš. Ale záleží dost na tom, kdo to je. Pokud nějakej kamarádíček providera, tak je to dost špatný. Občas se ale používá třeba Rozhodčí soud Hospodářské komory - tam asi celkem není čeho se bát.
Dnes už platí, že pokud je zákazníkem spotřebitel, musí rozhodčí doložku podepsat samostatně (nemůže to být schované někde ve smlouvě nebo všeobecných podmínkách), a rozhodce musí být zapsaný na seznamu rozhodců Ministerstva spravedlnosti. Nález pak musí být odůvodněn a musí tam být uvedeno poučení o možnosti zrušení soudem.
-
Dnes už platí, že pokud je zákazníkem spotřebitel, musí rozhodčí doložku podepsat samostatně (nemůže to být schované někde ve smlouvě nebo všeobecných podmínkách), a rozhodce musí být zapsaný na seznamu rozhodců Ministerstva spravedlnosti. Nález pak musí být odůvodněn a musí tam být uvedeno poučení o možnosti zrušení soudem.
Jo, vím, že se podmínky nějak měnily, ale nevzpomněl jsem si, jak přesně. Dík za doplnění.
-
@anonymous:
Diky za odpoved, ale mohl bys s tim TTLkem byt prosim trochu konkretnejsi? Mozna uvazuju, nebo ten mechanismus chapu spatne, ale:
Napr. Win klient defaultne u TCP packetu generuje TTL=128.
Pruchodem pres kazdy router by se mel TTL snizit o 1. Pokud se snazim pristoupit k cili, ktery je ode me cca 20 hopu(coz zkousim), tak nemam sanci TTL vycerpat. Nebo to chapu spatne?
Predtim jsem to neuvedl, ale takhle ta komunikace zhruba vypada. Muze byt tedy tou pricinou nizky TTL?
Tak mě napadá, jestli ISP nedělá to, že paketům směřujícím zvenku k tobě nenastavuje TTL=1? Pak by totiž paket dorazil jen ke tvému routeru a ten by ho zahodil a už by se neproNAToval nikam dál. Chtělo by to sniffnout co od ISP vlastně leze.
-
Karle, Ty kluku usata! :-) Je to presne tak jak rikas, koukam na ty pakety a u prichoziho provozu je skoro vsude naprany TTL=1, nechava nemodifikovany jenom DNS dotazy a ICMP. Predtim jsem porad zkoumal hlavne rozdily mezi odchozimi pakety ode me a od routeru, ale nic zasadniho tam nebylo, prichozimu provozu jsem az takovou pozornost nevenoval. Dekuji vsem za pomoc!
-
koukam na ty pakety a u prichoziho provozu je skoro vsude naprany TTL=1
Tyvado, tak to zas posunulo hranice toho, co jsem myslel, že jsou ISPs schopní udělat. A to už jsem myslel, že mě nepřekvapí vůbec nic :) To je teda hlína :))
-
To sis s tím ISP tedy "polepšil"... :o ::) Tohle je na okamžitou výpověď smlouvy.
-
To sis s tím ISP tedy "polepšil"... :o ::) Tohle je na okamžitou výpověď smlouvy.
Zas na druhou stranu se to dá snadno zas zvýšit ;)
-
Jo nastavování TTL na 1 je stará finta, kterou se někteří ISP brání, aby uživatelé nesdíleli net a neschovávali za NAT třeba sousedy :)
Ale jak už se tu píše, jde to snadno obejít - pokud je na routeru např. linux, tak je to otázka jednoho řádku do iptables, který všem příchozím paketům nastaví TTL na nějakou vyšší hodnotu.
-
Jo nastavování TTL na 1 je stará finta
Přiznej se, že tys u nějakýho ISP pracoval? Normálního člověka todle totiž nemůže napadnout :))
-
Normálního člověka todle totiž nemůže napadnout :))
Ne, to opravdu ne. Stálo by za to zveřejnit toho "ISP". ::)
-
Jo nastavování TTL na 1 je stará finta
Přiznej se, že tys u nějakýho ISP pracoval? Normálního člověka todle totiž nemůže napadnout :))
Já u žádného ISP naštěstí nepracoval, jen jsem chodil na školu v tomhle oboru a člověk občas něco pochytí... dělat u nich, tak to tady přece neprozradím, no ne? ;D
-
Jo nastavování TTL na 1 je stará finta, kterou se někteří ISP brání, aby uživatelé nesdíleli net a neschovávali za NAT třeba sousedy :)
jo to je finta nekdy z roku 1998... od takovyho poskytovatele utikej pryc nejrychleji jak muzes.
-
to neni smlouva na internet, ale na kriplnet.
-
dělat u nich, tak to tady přece neprozradím, no ne? ;D
Sem myslel, že seš takovej ten záškodník, co býval kouzelník a teď prozrazuje, jak jsou ty karty cinknutý :)
-
Tedy to ziram, ten ISP je pekny sulin. Neni to nahodou neco proti necemu?
-
Neni to nahodou neco proti necemu?
Jo, je to proti zdravýmu rozumu :)
-
Toz proti zdravemu rozumu to pochopitelne je, nicmene by bylo uzitecnejsi, kdyby to bylo treba proti zakonu nebo nejakemu komunikacnimu predpisu o sitove neutralite. Minimalne to musi byt proti nejakemu RFC, protoze sitove zariceni, kterym pakety prolezaji, ma TTL snizovat o 1, ne na 1. Akorat mam obavy, ze RF v CR neni povazovano za platnou zakonnou normu.
-
Toz proti zdravemu rozumu to pochopitelne je, nicmene by bylo uzitecnejsi, kdyby to bylo treba proti zakonu nebo nejakemu komunikacnimu predpisu o sitove neutralite. Minimalne to musi byt proti nejakemu RFC, protoze sitove zariceni, kterym pakety prolezaji, ma TTL snizovat o 1, ne na 1. Akorat mam obavy, ze RF v CR neni povazovano za platnou zakonnou normu.
Tvé obavy jsou naprosto správné.
-
Duvodem, proc nehledam jineho providera je to, ze jsem v lokalite, kde jaksi neni vyber. Jsou tu dva, jeden horsi, nez druhy. Druhy ma sice sit pruchozi, ale je to velmi nekorektni spolecnost u ktere se smluvne uvazete i k tomu, kdo konkretne vas v pripade sporu o nefunkcni linku bude soudit (spol. AB-NET, neodpustim si reklamu :-)), mate pravo pouze platit ikdyz vam rychlost lita nahoru a dolu, smlouva se da vypovedet jenom jednou za dva roky.
pokud to správně chápu, tzv. "Husákova novela" zákona o elektronických komunikacích se vztahuje také na všechny poskytovatele internetu (= síť elektronických komunikací, http://www.zakonyprolidi.cz/cs/2005-127), tedy i smlouvu uzavřenou na 2 roky lze vypovědět dříve s max. 20% doplatkem a podnikatel musí nabízet také variantu pouze ročního závazku (byť obvykle potom za méně výhodných podmínek).
jiná věc potom je, jestli se vám chce se s nimi o tom dohadovat. i když na podobné rádoby podnikatele často zabírá odkaz na odpovídající paragrafy a naopak jim už nestojí za to něco vymáhat :-)
-
Tato novela se nevztahuje na všechny poskytovatele připojení k Internetu ale jen na sítě veřejných elektronických komunikací. Takže záleží, zda daný ISP se přihlásil k podnikání na ČTU jako síť veřejná a pak pro ni plati tyto podmínky pro předčasné vypovězení smlouvy (a napříkla i povinnost o provozních logách) nebo síť neveřejná, kterou v podstatě zákon o elektronických komunikacích nezajímá a může si do podmínek nasekat co chce (v rámci možností daných NOZ).
Takže je třeba si ještě hlídat, komu se konkrétně upisuji.