Halacs

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

Kérdés

Posztolva ekkor: (szerkesztve)

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

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon

11 válasz erre a kérdésre

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.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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é.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon

Posztolva: (szerkesztve)

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

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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)?

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon

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ó.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon

Posztolva: (szerkesztve)

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

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon
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.

Bejegyzés megosztása


Link a bejegyzéshez
Megosztás más oldalakon

Hozz létre egy fiókot vagy jelentkezz be a kommenteléshez

Ahhoz, hogy kommentelhess, tagnak kell lenned.

Fiók létrehozása

Hozz létre a közösségünkben egy új fiókot. Igazán egyszerű!


Új fiók regisztrálása

Bejelentkezés

Már van fiókod? Jelentkezz be itt!


Bejelentkezés most