btz

Úgy értettem hogy azzal "elhagyhatjuk" az alkalmazást, de "kilőni" csak abban az esetben célszerű, ha nem megfelelően működik. Amúgy erre az esetben alkalmazható, a Beállítások menüben az alkalmazás beállításokban kikeresni az adott alkalmazást, majd a "Kényszerített leállítás" lehetőséget választani. Szóval Android esetén használjuk inkább az alkalmazás elhagyásához inkább a Home vagy a vissza gombot, az alkalmazás választót is inkább csak választásra használjuk ne kilövésre.

Home gomb megnyomása esetleg?

A SIM is T amit beletettél?

Szerintem a legegyszerűbben úgy jársz, hogy lereseteled és az usmer manulál instrukciói alapján újból beállítod az egészet.

Adsl net HGW-vel? Akkor légyszives mellékelj egy képernyőmentést a HGW admindelületén található vonali információkról.

És akkor itt is az ígért módosítás, mostmár jobban hasonlít az openwrt tűzfalkeretrendszerében található szabályokhoz. ip6tables -F ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT ip6tables -A FORWARD -p tcp -m tcp --destination [IDE: IPV6 CÍM] --dport 8080 -j DROP #(Vagy ACCEPT ha meg akarom nyitni a portot a destination résznél megjelölt ip címmel rendelkező gépen) ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A INPUT --protocol udp --src fe80::/10 --source-port 547 --destination fe80::/10 --destination-port 546 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT #(Drop ha nem akarjuk a pinget) ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type bad-header -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type unknown-header-type -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT ip6tables -A FORWARD -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT ip6tables -A FORWARD -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT ip6tables -A FORWARD -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT ip6tables -A FORWARD -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT ip6tables -A FORWARD -p icmpv6 --icmpv6-type echo-request -j ACCEPT #(Drop ha nem akarjuk a pinget) ip6tables -A FORWARD -p icmpv6 --icmpv6-type echo-reply -j ACCEPT ip6tables -A FORWARD -p icmpv6 --icmpv6-type unknown-header-type -j ACCEPT Több szabályt fel lehet venni, különböző gépek portjaira, nyitni és zárni lehet őket, akár mind a ~65000 portot le lehet zárni, mintha NAT mögött lenne a gép.

@Tamas586 Nem tudja a router, hogy melyiken van a webszerver. A tesztelés ideje alatt gyakran változtattam a tabletem ipv6 ip címén és nem volt kedvem átirogatni a célgép címét a szabályban, ezért inkább ezt nem szabályoztam le egy gépre, szóval ha lett volna 10 webszerveres gépem, akkor ezzel mind a 10-re nyitott lenne a 8080-as port. A FE80 kommunikáció a dhcpv6-hoz kell, ahogy az openwrt-s tűzfal szabályban is benne van, elég lenne csak source portnak az 547 célportnak pedig az 546, de ahogy a fenti hszben is írtam, az egyszerűsíés kevéért kihagytam az iptables szabályból. Később ha több időm lesz foglalkozni vele akkor bele rakom az iptables szabályba is a portokat, és azt is hogy a cél ip range is csak FE80....lehet. Szerintem érdemes brkapcsolva hagyni mind a kettőt, mert ha van Android 5 alatti oprendszerrel rendelkező telefonod, tableted, akkor az csak slaac-al kaphat ipv6 címet, én is stateless + stateful beállításon hagytam a routerem dhcpv6 beállításait.

@Tamas586 Iptables az iptables mindkét rendszeren, Linux alapú rendszer a Dd-wrt és az Openwrt is. Az Openwrt-nek van egyfajta külön tűzfal keretrendszere, ami áttudja kicsit bolygatni az iptables dolgait, de én most magamnak megoldottam (igaz csak áttmenetileg), hogy csak az iptables adja a szabályokat a saját routeremben. Így néz ki az iptables parancssor, amit hozzáadtam annak érdekében hogy ne szűnjön meg az ipv6 ip6tables -F ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT ip6tables -A FORWARD -p tcp -m tcp --dport 8080 -j DROP #(Vagy ACCEPT ha meg akarom nyitni a portot) ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A INPUT -s fe80::/10 -j ACCEPT ip6tables -A INPUT -p IPv6-icmp -j ACCEPT ip6tables -A OUTPUT -p IPv6-icmp -j ACCEPT ip6tables -A FORWARD -p IPv6-icmp -j ACCEPT Lényegében csak az ICMPv6 forgalmat engedélyeztem újra mind az INPUT, FORWARD, OUTPUT láncon, plusz a FE80::/10 kommunikációt. Plusz tesztelés képpen a 8080-as port nyitásához, zárásához egy sort, ez másnak nem kell, ezt csak azért raktam bele, hogy teszteljem vele, mikor és milyen iptables szabályok alapján érhető el a tabletemre telepített teszt webszerver, amit ipv6-on keresztül lehet csak elérni, ipv4 esetén nem, mivel le van NAT-olva. Az openwrt-s forgalmi szabály beállításoknak az analógiájára csináltam, mondjuk én kicsit egyszerűsítettem az iptables parancs formát, hogy átláthatóbb legyen most a tesztelésnél (később majd teljesen finomhangolom az openwrts beállítás szerint, különbontva az icmpv6 fajtákat, stb)... ...de a lényeg, hogy működik, kapok ipv6-ot és tudom zárni nyitni a portokat openwrt alatt annak tűzfalkeretrendszerét megkerülve (a képen látszik, hogy ki van lőve az engedélyezés az openwrts szabályok mellöl, helyettük az Iptables szabályai vannak életben). ip6tables -A FORWARD -p tcp -m tcp --dport 8080 -j DROP hatására filterezi a 8080-as webszerverem portját ip6tables -A FORWARD -p tcp -m tcp --dport 8080 -j ACCEPT Hatására pedig engedélyezzük Később ha érdekel valakit /lesz rá igény, akkor megcsinálom az iptables parancsok teljes hozzáigazítát az openwrt féle szabályokhoz.

Megcsináltam ezekszerint a szabályok szerint, ugyan ilyen ip6tables parancsokkal, de mint sejtettem nem kapta meg a tabletem az ipv6 címét. Ezért raktam bele plusz pár sort, így most megkapja a címet, de most meg azzal szenvedek, hogy nem tudok portot nyitni a tabletemen futó teszt webszervernek, de még utána kérdezek pár dolognak.

@Tamas586 Ha nincs grafikus felület, akkor sajnos maradnak a parancsok. Openwrt esetén szerencsére a konfigurációs állományok szerkesztése sem túl bonyolult, így grafikus felület nélkül sem kell parancsozni, elég csak szerkeszteni a konfig állományt. DD-WRT esetén nemtudom, hogy milyen lehetőségek vannak konfigurációs állomány szerkesztésére.

@Tamas586 A fenti példában, ha elindítanék a tabletemen, mondjuk egy FTP szolgáltatást, akkor rögtön zöldre váltana a portscannaren a 21-es port, ezért ha tudod, hogy x ipv6 című gépeden ezt akarsz futtatni, de nem szeretnéd, hogy wan felől is elérhető legyen, akkor csak fel kell venni egy új szabályt a 21-es (FTP szolgáltatáshoz dedikált) port szűrésére Ekkor a port scanneren kívülről csak annyi látszik, hogy le van filterezve az a port, de belülről elérheted, mert a forrás nem a wanból jön. A wanból filtered-et kap mindenki Publikus ipv6 alatt ugyanúgy biztonságban lehet tartani egy eszközt, mintha ipv4 nat mögött lenne.

@Tamas586 Szivesen segítek, ezért vagyok/vagyunk itt. Szerintem a SOHO routereken a lehető legjobb választás az Openwrt, amennyiben a felhasználónak nincs szüksége hardveres NAT-ra. A többi már csak ízlés kérdése. Közben utána néztem és úgy olvastam, hogy a DD-WRT-ben is van iptables, szóval lehet azt is tűzfalazni. Teljesen igazad van, a számodra a 18/20 az ideális, nálam engedélyezve volt az echo, így hoztam egy új szabályt, ami így néz ki: Ezzel a routerrel lezártam az összes eszközöm ezirányú továbbítását a routeren keresztül (Discard forward). Majd felmentem az ipv6 tesztoldalra a kliens tabletemmel. Itt látható, hogy már csak 18/20 pontot kaptam, mivel a routerem kiszűri az icmp echo-requestet. Nem fog válaszolni a pingre. Felmentem egy online ipv6 ping oldalra. Látható (lenne ha véletlen nem satíroztam volna ki, de az alján valamennyire látszik), hogy 100% packet loss az ipv6 címemre, pedig a tabletem kint van a publikus neten az ipv6 címével. Majd az egészet ellenőriztem egy ipv6 online portszkennerel is. Látható, hogy a tabletem az összes fontos portja amit kívülről nagyon szeretnek birizgálni, az zárva van. Persze megnézhettem volna mind a 65ezer valahányra, de most idő hiányában ezt nem tettem, de biztos, hogy mind zárva van. Tehát akik hekkelni akarnak, azok nem találják meg a tabletem. Miközben én kiscicás képeket nézek a Google ipv6 only keresőjében vele. Összegezve: kívülről zártak a portjaim, pingre nem válaszolok, de az eszközömnek publikus ipv6 címe van, amivel látom az ipv6-only oldalakat is. Van még valami amivel ki tudják még deríteni az esetleges támadók, hogy a tabletem publikus ip címmel fent van a neten? Amint pedig nyitok egy portot, azt ugyan így a router tűzfalán lezárhatom, ha nem akarom használni, annak ellenére, hogy a tabletemen nyitott az adott port, wan felől zártnak fogja mutatni a port scanner, de a tabletemen is lezárhatom a portot, de akkor már a routerrel hiába nyitom meg a lehetőséget, akkor is zárva marad, csak a tabletemmel tudom megnyitni.

Bocs elírtam, Teredo

@fgabor87 A Teredo a windows egy szolgáltatása, IPV4 hálózati címfordító IPV6-ba. Szerintem kikapcsol a szolgáltatás, ha globális címet (GUA) címet kap a Windows.

Ipv6 esetén, ha a routerben nincs normális tűzfalazási lehetőség, akkor lehetőség van a kliens eszközöknél is külön beállítani a forgalmi szabályokat (pl windows tűzfal, nas fw-jében található tűzfal, stb...), mert ilyenkor nat nélkül kint van a publikus neten. Ipv4 esetén is van olyan, hogy a gépünk direktben kap publikus ip címet, ekkor is kint van a publikus hálózaton, ezért van külön tűzfaluk. Most hogy sok eszköz lesz az ipv6-nak köszönhetően a piblikus neten, így ismét fontos szerepet fog betölteni az eszközünk saját tűzfal rendszere. De ettől függetlenül célszerű routeres központi tűzfallal kordában tartani a klienseket.

@Tamas586 Mutatsz képet a routered tűzfal részről? Látom DD-WRT-d van azt annyira nem ismerem, de ha nincs benne vagy nem telepíthető hozzá normális tűzfal, akkor érdemes lecserélni Openwrt-re (ha a router típusodra elérhető), azt ismerem, használom sok helyen, tudok benne screenshoot képek segítségével segíteni, és ilyen szép finomhangolási lehetőségek állnak rendelkezésre a forgalom szabályozás terén: Az intefacek is könnyen beállíthatók, hogy ipv6-ot használjanak, akár pppoe shared sessionnal is. (Nem Telekomos netről készült a kép, hanem egy konkurens pppoe-t használó ipv6-ot már élesben alkalmazó cég internet szolgáltásáról). A saját routerre kapcsolódó klienseknek pedig a LAN interfacen futtatott dhcpv6 szerver által megkapják az ip címüket, amelyikek pedig csak a SLAAC-ot támogatják, azok pedig azáltal. Ha pedig a kliensünk (laptop, tablet, nas, stb...) megkapta az ipv6 címét, akkor ezt kell látni a teszt weboldalakon.

Nem FE80-as címmel nem tudsz elérni ipv6 only weboldalakat, azzal csak egy hálózati szegmensen belül lehet kommunikálni. Ha van 2001* címed az eszközödön (laptop, tablet, telefon, nas, router) akkor van rá esély, hogy kívülről elérhető legyen egy azon futó szolgáltatás de csak ipv6-al rendelkező hálózatról, ipv4 onlyról nem. Ugxanekkor tudsz csak ipv6 only oldalakat elérni az eszközödről. Nem kell letiltani a dhcpv6-ot egyszerű tűzfalszabállyal lehet szabályozni a forgalmat. Ha jól tudom, ha kikapcsolod a dhcpv6 servert attól még a következő újrakapcsolódásig az ipv6 cím megmarad, akárcsak ipv4-nél sem tűnik el a kliens dhcpv4-en kapott ipje rögtön, csak ha lejár az érvényessége vagy újra akarsz kapcsolódni. Attól hogy kapsz ipv6-ot, nem feltétlenül jár együtt azzal, hogy ipv4-en NAT mögé tegyenek.

FE80 (LLA) címük van akkor is ha van ha van globálisan routolható prefixes (GUA) címük is, tehát az mindíg jelen van. Ha nics globális unicast (GUA) címük, akkor pedig marad az FE80, de az nem routolható cím, így kívülről elérhetetlenek. De attól hogy a routered tűzfalában egy eszköz elérését letiltod a GUA cím alapján Wan felől, attól még megmarad az eszköz GUA ip címe.

Én ki szoktam várni a netes véleményeket és tapasztalatokat egy új típussal kapcsolatban, kb 2-3 hónapot érdemes olvasgatni a kiszemelt telóról (pl a Note 7-el történtek nagyon rávilágítanak ennek a fontosságára), ha ezután sem lehet kirívó dolgokról olvasni az adott termék kapcsán, akkor nyugodtan meg lehet venni, a kisebb gondokra pedig ott a garanciapapír

@Tamas586 IPV6 esetén a router tűzfalának segítségével lehet szabályozni, hogy melyik géped melyik portja legyen nyilvánosan elérhető az internet felől, úgy minha NAT mögött lenne. Attól hogy egy eszköz kívülről elérhető vagy nem, attól nem változik meg az ip címe.

De közben mégegyszer elolvastam a kritériumot és abban az van, hogy a HGW-re kapcsolódó eszköznek kell dhcpv6 kliensként kapcsolódnia a HGW-re a wan oldaról, SLAAC-al nem, így akkor ezt akár hagyhatod stateless módban is, mert ez a rész már a saját eszközre kapcsolódó klienseket szabályozza.

@fgabor87 Igen oda majd automatikusan felveszi a LAN-nak adott prefixet, majd ha lesz, az utótagot pedig te szabályozhatod aszerint, hogy mennyi címre van szükséged a helyi hálózaton.

Szerintem az autokonfigurációt állítsd át Statelefulra. A Stateless Address Autoconfiguration az pont a SLAAC, ami a leírás szerint saját eszközzel nem lesz támogatott. A DHCP-PD az a prefix delegációt jelenti, azaz ez továbbíja a LAN-os eszközök felé a prefixet, azaz ez jó ha Enabled módban van. Ha jönni fog a szolgáltatótól az ipv6 akkor az WAN IPv6 is címet fog kapnoi, szerintem a LAN oldal is kap külön címet, ehhez hasonló címmel fognak rendelkezni a LAN-ra kapcsolt eszközök. Mi a pontos típusa a routernek? Más beállítási lehetőségek vannak még benne IPV6 szempontjából? Pl külön ipv6 tűzfalrész nincs benne?

@Deino Volt *****es primer pstn telefon területeken, főleg nagyvárosokban is jellemző még Telekom koax hálózat, pl Esztergomban, Szegeden, Hódbemzővásárhelyen, Békéscsabán.

Általában újraindítás vagy szinkronnbontás után nullázza a CRC error értéket, tehát ha nem restartoltad, akkor volt egy szinkronbontásod, ami nem túl jó jel. Erre mindíg figyelj oda mert néha olyan gyorsan újraszinkronizál, hogy észre sem veszed hogy szakadt a vonal.