Utolért a végzet

 ( scineram | 2017. január 25., szerda - 19:54 )

Ma, 3 óra körül.

IPv4 WAN Status

pppoe-wan Type: pppoe
Address: 100.65.142.46
Netmask: 255.255.255.255
Gateway: 10.0.0.1
DNS 1: 193.110.57.4
DNS 2: 193.110.56.8
Connected: 16h 41m 17s

A publikus IPv4 címed 178.164.175.139

Egyelőre nem követelem vissza, megnézem mi lesz a performansz. Illetve a publikus cím így vajon állandó lesz? Az nem jönne rosszul egyik szolgáltatóm miatt, bár nagy gondnak eddig sem neveztem volna a váltásokat. Vajon a mobilszolgáltatásuk miatt is osztják újra? Ha kihoznak egy IPv4-es mobilinternetet, akkor kurvára csalódott leszek. Akkor vissza is követelem majd.


A végzet bizonytalan időre elhalasztva. Szombaton visszakértem és kaptam a publikusat. Többször volt gond kapcsolatokkal, ping is kiszámíthatatlanul viselkedett. De amire végképp nem számítottam, hogy a korábbi másodpercre egy hetes kapcsolat helyett teljesen össze-vissza lett bontva a pppoe, egy-két naponta kellett újrakapcsolódni. És ráadásul a publikus átjáró címe is változott, így az említett szolgáltatásommal is rosszabb lett a helyzet. Ráadásul minden csatlakozáskor az új delegált prefixnek ugyanaz a 604800 élettartam volt hirdetve. Ezért ilyenkor két prefix élt LAN oldalon is egy rövid ideig, amíg a router visszavonta a régit.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

És mivel az IPv4 cím alapján (178.164.x.x) Digi hálózat van nálad, IPv6 felé célszerű nyitni. Ha a túloldal is tudja, akkor nincs NAT és egyéb eddigi hülyeség a végpont - végpont között.

$ ping youtube.com
PING youtube.com(bud02s21-in-x0e.1e100.net (2a00:1450:400d:806::200e)) 56 data bytes
64 bytes from bud02s21-in-x0e.1e100.net (2a00:1450:400d:806::200e): icmp_seq=1 ttl=56 time=2.14 ms
64 bytes from bud02s21-in-x0e.1e100.net (2a00:1450:400d:806::200e): icmp_seq=2 ttl=56 time=2.33 ms

$ ping hup.hu
PING hup.hu(hup.rackforest.hu (2a01:6ee0:1::bad:c0de:113)) 56 data bytes
64 bytes from hup.rackforest.hu (2a01:6ee0:1::bad:c0de:113): icmp_seq=1 ttl=58 time=2.54 ms
64 bytes from hup.rackforest.hu (2a01:6ee0:1::bad:c0de:113): icmp_seq=2 ttl=58 time=2.82 ms

+1, nálam amióta lehet ipv6-ot natívan használni náluk, használom is. Jó dolog, már csak a nat nélküli működés okán is.

Érdekes, én pont a nat okozta "tűzfal" miatt tiltom frankón az ipv6-ot, szintén digi. :) Nem szeretem, ha kinnt vannak direkte a neten az eszközeim.

ip6tables és öröm meg bódottá, meg normális sávszélesség van, miközben ipv4-en a nat miatt erősen hörögve tud 130-150Mbit-et kipréselni magából a router.

Nade a routeren is megtuzfalazhatod az ipv6 tartomanyod, es korlatozhatod, hogy milyen forgalom haladhat tovabb es mi az amit megallitassz. Ez miert nem jo megoldas?

---
Apple iMac 27"
áéíóöőúüű

conntrack a tűzfalazás terén ismerős?
Röviden: meg tudod vele adni, hogy csak arra jöhet be válaszcsomag, amelyről az elmúlt percben kifelé ment kérés.

ip6tables -A FORWARD -i WANIF -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# ---> ide írod azokat a kivételeket, amikre mégis be akarsz engedni kéréseket ... pl. torrent port
ip6tables -A FORWARD -i WANIF -j DROP
ip6tables -A FORWARD ! -i WANIF -j ACCEPT

terjed a hrogyizmus, hajrá

Majd mit csinálsz, ha nem lesz más.

Ó, persze. Bevezetése óta űzöm én is Hatot. Csak nem említettem, mert annyira magától értetődő.