Halacs

Tag
  • Tartalmak

    25
  • Csatlakozás időpontja

  • Utolsó látogatás

Halacs a fórumon

  • Rang
    Tudományos főtag
  1. Igen, most ezt tervezem. Ahogy a gyerek engedi Tök jó lenne itt valaki akinek lenne ezzel kapcsolatban megosztható tapasztalata.
  2. Van rá lehetőségem igen: ami linuxon fut azt meg tudom próbálni. Annyi, hogy mindenképp GRE (és lehetőleg +IPsec) alapú protokoll kellene Layer2-ben. SoftEther-t nézegettem eddig én is, de annál ilyen protokollt nem láttam. Az OpenVPN az saját TCP/UDP alapú protokollt használ. Azért lenne szerintem fontos a közel azonos protokoll használata, hogy a Telekomos forgalom alakítást is ki lehessen zárni egyúttal. A SoftEther amúgy tetszik, mert úgy látom az http fölött viszi át a VPN-t. Jó lenne ha menne Mikrotiken is. HTTP(s)-t nem igen fognak korlátozni sose, míg torrent-el, vpn-el, egyebekkel ez könnyedén előfordulhat ahogy mobilnet esetén már nyíltan teszik is.
  3. Melyik HGW-s VLAN ID-t kell kirakni a boxnak? Nekem perpill nem kell ugyan IP TV, de egyszer már passzoltuk a T-s IP TV-t pont ilyen bajok miatt, aztán fene tudja mit hoz a jövő. Nekem itthon minden hálózati elem (routerek, switchek) mikrotik. Publikus IP a routeren alap, de esetleg majd TV is kellhet. Gonodlom a PPPOE akkor is megy ha van IP TV. Ugye? Egyelőre még koax van végig húzva a házban de lassacskán ideje lesz megszabadulni tőle és UTP-t tenni csak a TV-hez mert csak a baj van a koaxal.
  4. A CPU terhelés 10% alatt van folyamatosan másolás közben is, pedig az egyik routeren van radius server is. Néztem core-onként is a CPU használatot, úgy az egyik core magasabb (0-100% közt mászkál) de csak időnként ugrik fel magasra aztán "visszanyugszik". Az MTU-val én is rengeteget játszottam. Mikrotik manual alapján épp 1500 -as MTU-t állítottam be a tunel-re, mondván hogy a tunnelben semmiképpen se legyen a csomag újra fregmentálva de nem segített. Ha nincs mangle szabály akkor nem mennek a TCP kapcsolatok szinte egyáltalán, hiába van ott a tunnelen a "Clamp TCP MSS". Hasonló gondolatmenet vezérelt amikor a két host gép MTU -ját kézzel levittem 1250-re de attól se lett gyorsabb hiába számítottam erre.
  5. Ha samba protokol helyett HTTP-t használok (ugyanúgy VPN felett) akkor kicsivel gyorsabb, de még így is csak 100 Mbps -re kúszik fel a sebesség. Layer 2-es a VPN és 192.168.0.0/16 subnetben van minden gép a hálózaton. Ha routerek közti speedtestet csinálok, azaz érdekes, hogy 1300 byte méretű UDP csomagokkal van 400 Mbps körüli speed, TCP-vel viszont már csak az a fentebb is említett 100 Mbps körüli jön ki. Nem értem hol van a kutya elásva.
  6. Szia! Jelen pillanatban 30 Mbps körüli a tunnel forgalom miközben egy nagy fájlt másolok keresztül rajta Windows fájlmegosztáson (smbd) keresztül egyik Ubuntu gépről a másikra. Ha egy 500 Mbps körüli átvitelt látnék már boldog lennék. Eddig a saját VPN beállításokban kerestem a hibát (lehet ott is van), de a fenti idézet felkeltette az érdeklődésemet. Pár technikai adat hátha valamiből kilóg a lóláb hogy én vagyok a ludas és nincs forgalom alakítás Telekom oldalon (adná az ég): Eszközök: Mikrotik RB4011iGS+RM Mikrotik CCR1009-7G-1C-1S+PC IPsec hardveres támogatás mindkét oldalon Tunnel beállítások (mindkét oldal azonos): Mikrotik EoIP (GRE + IPsec) IPv4 fölött "Clamp TCP MSS" bekapcsolva Tunnel MTU: 1300 Change MSS mangle firewall rule: 1250 Tunnelen bellül VLAN trunk megy Aktuális IPsec settings: Auth.Algorithm: sha256 Encr.Algorithm: aes cbc Encr. Key size: 256 Telekom eszközök bridge módban Optika esetén PPPOE kapcsolódás Koax esetén sima bridge DHCP klienssel
  7. Sziasztok! Családon belüli kommunikációhoz és napi otthonról történő munkához is használunk VPN kapcsolatokat. Adott két lakás Telekomos internettel. Az egyikben optika a másikban koax van. Azt tapasztaljuk hogy a VPN kapcsolatok lassúak. Az egyik fajta VPN-ről biztosan tudjuk, hogy a Mikrotik EoIP protokollját használja ami egy GRE+IPsec alapú saját protokollja a Mikrotiknek. Kezd egyre gyanúsabb lenni, hogy a Telekomnak van valami sávészélesség korlátozás (forgalom alakítás) beállítva ezekre a protokollokra. Hiába kéne 1Gbps -el menni a másolásnak egyik lakásból a másikba az kb sose történik meg VPN-en keresztül. VPN nélkül is több szál szükséges a teljes sebességhez, míg lakáson belül nincs semmi probléma ezzel. A hup.hu -n pl van épp egy a Telekomot érintő hálózat semlegességes topic ahol linkeltek is egy elég durva kijelentését a Telekomnak. Igaz, az mobil hálózatokra vonatkozik. https://hup.hu/node/174291 "Jó ha tudod, hogy a Gigaerős Net és Gigaerős Net + csomagok esetén a Peer-to-peer jellegű fájl megosztás és letöltés (különösen Bittorrent), illetve egyéb folyamatos, hálózati túlterhelést jelentő forgalomtípusok használata esetén a letöltési/feltöltési sebesség 2/0,2 Mbit/s. Virtuális magánhálózat (VPN) használata vagy egyéb titkosított csatornákon keresztül történő forgalmazás (pl. SSH) esetén 10/5 Mbit/s." Tud erről bárki bármit? Az egyéb titkosított csatornákon keresztüli forgalmazásba már ennek az oldalnak a látogatása is belefér a https miatt. Az általános titkosítás ma már elég alap úgy általában az interneten.
  8. Szerintem mindenképp érdemes jelezni a hibát és szerintem érdemes azt is elmondani, hogy a dolog nem egyedi és itt ezen a fórumon van róla több infó. Ez szerintem segít átlendíteni az első szintű supporton és egyúttal segít annak is kitalálni mi a fene van aki azátn ténylegesen meg tudja esetleg oldani hiszen így nem veszik el és nem torzul a szakmai infó. Sanszos egyébként, hogy elsőre pikk-pakk le fogják zárni a hibát, de ha nem oldják meg vagy nem adnak érdemi választ akkor a My Telekom (vagy mi a hóhér a neve) oldalra belépve a hibajegyeknél megtalálod és kommenttel újra lehet nyitni aminek biztos örülni fognak de ha szakmailag korrekt meg illedelmes a dolog akkor ez így fer
  9. Szia! Nekem szerencsém van mert voltak olyan jó fejek annó és nekem külön bekapcsolták hogy nálam működjön a dual stack, de rövid ideig most vissza kapcsoltam a HE tunnel interfészt a routeremben. Eredmény: - tunnel interfész azt mondja magáról hogy "enabled" meg hogy "running" - ugyanakkor a ping nem megy: ping 2a00:1450:4016:801::200e interface=HE-IPv6-broker --> no route to host Megeshet, hogy valamit én szúrok el, most nincs agyam utána gondolni, de ez alapján nem megy és ha jól emlékszem nekem is Sagemcom ONT-m van ebben a lakásban. Azt még gyorsan megnéztem, hogy a HE oldalán a client IP az stimmel azzal amim van - script frissíti időnként úgy fest azóta is
  10. Igen, nekem egy prefixem van ami /56-os és én abból osztok /64-eket. Ezek szerint neked kisebb van, de attól még lehet menni fog. Kipróbálnám aztán kiderül A konfigod alapján van egy DHCPv6 kliensed ami csinál neked egy defaultv6 nevű IPv6 poolt. Ez a prefixed ugye ami neked /60 és nálam /56. /ipv6 dhcp-client add add-default-route=yes default-route-distance=2 dhcp-options=hostname interface=ether5 pool-name=defaultv6 prefix-hint=::/58 request=prefix use-peer-dns=no Ha jól látom te kézzel vetttél fel IP-t több interfészedre is. Ezeket én kitörölném és az alábbi módon vennék fel a defaultv6 IPv6 poolból címet. Nem bogarásztam nagyon végig a konfigod, de úgy látom az ether5 lehet a WAN portod és a többi egyforma LAN portok L2-be switchelve. /ipv6 address add advertise=no from-pool=defaultv6 interface=ether5 /ipv6 address add from-pool=defaultv6 interface=ether1 Ha minden oké akkor szerintem ezek utána ha megnézed az IPv6 címeidet a /ipv6 address print paranccsal akkor kell majd legyen a WAN és a LAN interfészeden is egy-egy /64-es cím a szolgáltatódtól kapott prefixel. A LAN oldalon ha van kliensed akkor az SLAAC-al kap is majd rögtön címet.
  11. WAN és LAN oldalra is vettél fel IP-t a kapott prefixel (poolból) ? Ha igen, esetleg egy config exportot csinálhatnál terminálból és azt feltölthetnéd természetesen a szenzitív adatokra vigyázva: /export hide-sensitive terse
  12. Köszi a kommentet és a segítséget is a háttérből ha te oldottad meg a problémám
  13. Munkaidő végeztével gyorsan át is állítottam mind a két helyen a routereket, hogy csak prefixet kérjen és kézzel vettem fel WAN és LAN oldalra is a v6 címeket a DHCPv6 poolból. Minden faín DNS-t nem néztem adnak e, mert az DNS over TLS alapon megy más szolgáltatótól, de ez nem is olyan fontos tulajdonképpen. Szóval megerősíthetem: Eger térségében optikai hálózaton és Budapesten koaxon is megy a dual stack IPv6 DHCPv6-al Telekom hálózaton. Eger térségében úgy értettem a kollégát telefonon, hogy csak engem vettek le a területi IPv6 tiltásról ami az előfizetési IPv6 beállítástól független. Így akkor már tényleg csak annyi maradt, hogy egyformán legyen beállítva a Telekom oldalán is, hogy DHCPv6-on lehet e címet is kérni vagy csak prefixet, egyébként stimmel úgy néz ki minden. Pacsi nekik! Ami még szerintem tök jó lenne (hátha olvassa valaki a Telekomtól is), hogy lehetne egy oldaluk ahol leírják, hogy melyik térségbe és melyik technológián működik már az IPv6 és hol nem. Ha odaírják mi a terv az plusz piros pont, bár tudjuk a terv és a valóság sokszor nem esnek egybe ilyen-olyan okokból (pl COVID).
  14. Lehet tudnék osztani abból valóban. Mivel koaxon így ment így állítottam be és azóta is megy szépen. Este tudom csak megpróbálni, hogy a routerem internet felé néző lábára is ugyanabból a prefixből vegyek fel címet, de bárhogyis szerintem egyformán lenne praktikus működni mindenhol. Koaxon ezt mondja a DHCPv6 kliens: [admin@mydomain] > /ipv6 dhcp-client print value-list interface: ether1-gateway status: bound duid: 0x00030001744d288d2f30 dhcp-server-v6: fe80::2ca:e5ff:fe3d:d419 request: address,prefix add-default-route: yes default-route-distance: 1 use-peer-dns: no pool-name: wan-pool pool-prefix-length: 64 prefix-hint: ::/0 dhcp-options: prefix: 2001:4c4c:1ee0:xxxx::/56, 1w2d1h17m59s address: 2001:4c4c:202:xx:xxxx:xxxx:xxxx:xxxx, 1w2d1h17m59s
  15. Örömmel jelentem, hogy valami történik IPv6 szinten optikán. Pár perce hívtak a Telekomtól, hogy próbáljam meg újraindítani az ONT-t és a Mikrotikem és nézzük meg van e változás. Odáig jutottunk, hogy link local címet már kapok a PPPOE interfészen, valamint DHCPv6-al prefixet is, címet viszont egyelőre nem. Koaxon címet is kapok ugyanígy, ezért jeleztem a kollégának, hogy már majdnem jó, de jó lenne ha egyformán tudna a kettő működni, ha egyformán tudnám a routeolást megcsinálni : address-t kapja a mikrotik és a kapott másik (prefix) subnetből kapnak a mikrotik mögötti gépek. Ezt ő továbbítja a megfelelő helyre. Szóval örülünk, valami történik még akkor is ha ez egyelőre úgy fest nem általános változás csak az én előfizetésemre vonatkozik. Várjuk ki a végét, eddig nagyon biztató a dolog.