Ugrás a tartalomhoz
  • 0

GRE+IPsec alapú VPN Telekolm általi limitáció? (forgalom alakítás?)


Halacs

Kérdés

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.

Szerkesztve ekkor: Szerkesztő: Halacs
Link kommenthez
Megosztás más oldalakon

11 válasz erre a kérdésre

Ajánlott posztok

  • 1
3 órája, uzman írta:

Ha van lehetőséged, tennék próbát hasonló (akár szoftveres GRE szerverrel is) és egy teljesen más, pl SoftEther-el is.

Én azt gondolom, hogy a szolgáltató nem szól bele, hogy milyen csomagokat forgalmazol, lehet az akár titkosított vagy nem. Vannak országok, ahol törvény alapján blokkolják a VPN szolgáltatókat, hazánk szerencsére nem tartozik az ilyen helyek közé, így elvileg mennie kellene akár a saját szervered felé vagy bármilyen VPN szolgáltató felé.

 

Igen, most ezt tervezem. Ahogy a gyerek engedi :)

Tök jó lenne itt valaki akinek lenne ezzel kapcsolatban megosztható tapasztalata.

Link kommenthez
Megosztás más oldalakon

  • 0
2 órája, Halacs írta:

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.

Szia

Mennyi a max sávszélesség, amit elér a VPN kapcsolat?

Ahhoz, hogy 1Gbit legyen a natív átvitel, a tunnel magasabb effektív sávszélességet is igényel.

Link kommenthez
Megosztás más oldalakon

  • 0
37 perce, uzman írta:

Szia

Mennyi a max sávszélesség, amit elér a VPN kapcsolat?

Ahhoz, hogy 1Gbit legyen a natív átvitel, a tunnel magasabb effektív sávszélességet is igényel.

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
Szerkesztve ekkor: Szerkesztő: Halacs
Link kommenthez
Megosztás más oldalakon

  • 0

Szia,

Én inkább a samba protokollban keresném a problémát vagy annak a környékén. Ilyen sávszél limitet én csak mobilnetnél láttam, ami tényleg aktív is volt T-nél, vezetékes neten nem. Ettől függetlenül nem lehetetlen, csak értelmét nem látnám.

Ha eltérő alhálók között másolok VPN-en, nekem is lassú az SMB alapú. Ami gyorsan szokott menni az az FTP, ha nagy fájlokról van szó, de az sem mindig. Ettől függetlenül ha belső szerveren speedtestelek (HTML5 alapú), akkor látható, hogy egyébként a VPN-t nem fogja meg a szolgáltató.

Link kommenthez
Megosztás más oldalakon

  • 0
3 órája, Halacs írta:

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

Nekem az MTU értékek a gyanúsak, de nem vagyok expert a gyártó saját protokolljában. Én anno OpenVPN-el gyengébb routerekkel is magasabb sebességeket tudtam elérni, ez alapján azt gondolom, hogy nincs korlátozás - a szolgáltató csak "bután" routolja a csomagokat.

Az eszközökön nem magas a CPU terhelés (>50%)? Szükség van a mangle szabályra? Akár az is megnövelheti a feldolgozási időt, ezzel csökkentve az átviteli sebességet.

Link kommenthez
Megosztás más oldalakon

  • 0
1 órája, b10up írta:

Szia,

Én inkább a samba protokollban keresném a problémát vagy annak a környékén. Ilyen sávszél limitet én csak mobilnetnél láttam, ami tényleg aktív is volt T-nél, vezetékes neten nem. Ettől függetlenül nem lehetetlen, csak értelmét nem látnám.

Ha eltérő alhálók között másolok VPN-en, nekem is lassú az SMB alapú. Ami gyorsan szokott menni az az FTP, ha nagy fájlokról van szó, de az sem mindig. Ettől függetlenül ha belső szerveren speedtestelek (HTML5 alapú), akkor látható, hogy egyébként a VPN-t nem fogja meg a szolgáltató.

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.

Link kommenthez
Megosztás más oldalakon

  • 0
8 perce, uzman írta:

Nekem az MTU értékek a gyanúsak, de nem vagyok expert a gyártó saját protokolljában. Én anno OpenVPN-el gyengébb routerekkel is magasabb sebességeket tudtam elérni, ez alapján azt gondolom, hogy nincs korlátozás - a szolgáltató csak "bután" routolja a csomagokat.

Az eszközökön nem magas a CPU terhelés (>50%)? Szükség van a mangle szabályra? Akár az is megnövelheti a feldolgozási időt, ezzel csökkentve az átviteli sebességet.

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.

Link kommenthez
Megosztás más oldalakon

  • 0
14 órája, Halacs írta:

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.

UDP-nél nincsen ACK , ezért gyorsabb

Link kommenthez
Megosztás más oldalakon

  • 0
14 órája, Halacs írta:

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.

Én csak arra tudok gondolni, hogy az MTU vagy a tűzfalszabályok környékén lesz valami.

Arra van lehetőséged, hogy a hardveres megoldás helyett, átmenetileg valamilyen szoftveres VPN-el megpróbálod összekapcsolni a két oldalt és úgy csinálsz egy speedtest-et (pl openvpn, softether, stb)?

Link kommenthez
Megosztás más oldalakon

  • 0
4 órája, uzman írta:

Én csak arra tudok gondolni, hogy az MTU vagy a tűzfalszabályok környékén lesz valami.

Arra van lehetőséged, hogy a hardveres megoldás helyett, átmenetileg valamilyen szoftveres VPN-el megpróbálod összekapcsolni a két oldalt és úgy csinálsz egy speedtest-et (pl openvpn, softether, stb)?

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.

Szerkesztve ekkor: Szerkesztő: Halacs
Link kommenthez
Megosztás más oldalakon

  • 0
1 órája, Halacs írta:

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.

Ha van lehetőséged, tennék próbát hasonló (akár szoftveres GRE szerverrel is) és egy teljesen más, pl SoftEther-el is.

Én azt gondolom, hogy a szolgáltató nem szól bele, hogy milyen csomagokat forgalmazol, lehet az akár titkosított vagy nem. Vannak országok, ahol törvény alapján blokkolják a VPN szolgáltatókat, hazánk szerencsére nem tartozik az ilyen helyek közé, így elvileg mennie kellene akár a saját szervered felé vagy bármilyen VPN szolgáltató felé.

Link kommenthez
Megosztás más oldalakon

Csatlakozz a közösséghez!

Posztolhatsz regisztráció előtt is. Ha már van regisztrációd, jelentkezz be itt.

Vendég
Válaszolj a kérdésre...

×   Formázással együtt illesztetted be a tartalmat.   Formázás eltávolítása

  Only 75 emoji are allowed.

×   A linkedet automatikusan beágyaztuk.   Linkként mutatás

×   Az előző tartalmat tároltuk. .   Itt törölhetsz

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Új...