-
Fototrend
Ebben a témában VPN-el kapcsolatos kérdéseket lehet megbeszélni, különféle VPN szolgáltatók, és VPN képes eszközök, pl. VPN-t is tudó routereken, NAS-okon a VPN használata. Különféle VPN típusok (PPTP, L2TP, OVPN, WG, SSTP, stb...), pl. melyiket érdemes, mik a különbségek, előnyök-hátrányok.
Új hozzászólás Aktív témák
-
#3554
mrots
tag
ArthurShelby
#3553
mrots
tag
válasz
ArthurShelby
#3553
üzenetére
"Már a vdsl-nél sem használhatsz saját modemet."
Egyreszt nekem VDSL van es a sajat cisco routerembe rakott EHWIC interfesz modul a modem, tehat de, sajat modemet hasznalok, nem szolgaltatoit.Masreszt 15 eve amikor nem volt ennyire elavult es meg fejlesztettek, akkor is hasznalhattal sajat modemet, meg 20 evvel ez elott is. Ha annyira problema lett volna a vegfelhasznaloi support es komplexitas csokkentese, mar akkor sem engedtek volna.
-
#3552
mrots
tag
ArthurShelby
#3550
mrots
tag
válasz
ArthurShelby
#3550
üzenetére
"Rengeteg user errort ki tudsz szűrni, ha szolgáltatói eszközt osztogatsz (jók e a beállítások pl), könnyebb a hibát behatárolni."
Ha ez lenne az ok, akkor a DSL-nel a mai napig csak a szolgaltato modemjet / routeret lehetne hasznalni. -
mrots
tag
vagy cel, vagy forras alapu routinggal, felteve, hogy a vpn tunnel amugy mar el es mukodik, csak forgalmat kell bele kuldeni.
Ha tobb eszkozon kell, amelyek maguk egyeb forgalmat is generalnak, akkor szukseged van az ip tartomanyokra amelyek a cel ip cimek amikor a forrasok a netflixet hasznaljak. Ezek az IP cimek idovel valtozhatnak. Nem biztos, hogy van publikus lista az IP cimekrol, nyilvan regionkent ezek kulonbozoek lehetnek.
Ha az eszkozok, amik netflixet neznek amugy mast nem nagyon csinalnak az internet kapcsolattal - peldaul tevek - akkor elkepzelheto, hogy egyszerubb forras IP cim alapu routingot (policy routingot) hasznalni es minden forgalmat az adott forras IP cimrol a vpn tunnelbe terelni.
Igy olyan forgalom is belemehet, ami nem netflix forgalom, cserebe nem kell allandoan nyomozni, hogy megvaltozik-e a netflix altal hasznalt IP tartomany.
Ha IPv6 is van, akkor arra ugyancsak meg kell csinalnod a fentieket, mert dual stack eseten a vegpontok a v6 forgalmat preferaljak. Hiaba van v4 vpn-ed es kuldod arra a netflix v4 forgalmat, ha a teve v6-on kilep a lokalis internet kijaraton.
-
mrots
tag
válasz
4Grider
#3514
üzenetére
Elkepzelheto, hogy az illetot az zavarja, ha megtudjak, hol van az emailje. Az SMTP es IMAP/POP valoban TLS felett megy mar jo regen, tehat azt nem fejtik vissza, de a TLS handshake-ben megtalalhato a hostnev amihez csatlakozik, igy felfedi hol van az emailje, amibol akar mar maga az email cim is kovetkezhet, legalabbis a domain resze.
Ezen tulmenoen, ha valamilyen hitvany szolgaltatonal van, ahol nem patcheltek regi TLS hibakat, akar meg alanya lehet egy TLS downgrade tamadasnak is, ami ellen a vpn vedene.
Amugy a legtobb ingyen wifin engem se szokott erdekelni a vpn az emailek miatt, mert valoban tls-ben kozlekedik es kit erdekel, ha a hosting szervert valaki kifigyeli a TLS adatokbol.
-
mrots
tag
Ma egy kicsit jatszottam VPN titkositasi algoritmusokkal. Hatha erdekel valakit:
A meresek egy sima DSL kapcsolaton tortentek, amit egy 1941-es cisco router terminal egy EHWIC VDSL adapteren. A titkositas es mindenfajta vpn kapcsolat nelkuli meres az, amit a DSL kapcsolat lehetove tesz, ez tenylegesen a szolgaltato altal vallalt maximum. A meres celja a router terhelesenek megfigyelese volt kulonbozo algoritmusokkal. A meres wifin keresztul tortent, nem kabelen, azert, mert a szolgaltato altal biztositott savszelesseg messze alatta van wifi nevleges teljesitmenyenek, magyarul nem a wifi a szuk keresztmetszet.
A meresek soran a VPN vegpont vegig ugyanaz volt, semmi mas valtozas nem tortent, mint a titkositashoz hasznalt algoritmus valtoztatasa. A VPN oldalon egy strongswan terminalta a titkositott kapcsolatot es iptables PATolta ki az internetre a forgalmat, a hasznalt protokoll IKEv1 volt, tanusitvany alapu azonositassal (bar ez utobbinak nincs hatasa a sebessegre).Az eredmeny ertekelese soran erdemes tudni, hogy a 'show proc cpu hist' parancs 10%-ra kerekitve adja meg a CPU terheleset, igy a 100% barmi lehet 95 es 100 kozott, a 90% pedig barmi lehet 85 es 94 kozott. Magyarul az eredmenyeket ertelmezve en ugy gondolom, hogy a CPU terhelesben annak ellenere, hogy egy helyen 90% van, en ugy gondolom nincs relevans elteres, valoszinuleg itt 94% lehetett a mert ertek, a tobbinel meg 96%.
Az ugyfel kerdese az volt, hogy erdemes-e atternie valami masik VPN algoritmusra, hogy a meglevo eszkozeivel jobb teljesitmenyt erjen el. Tekintettel arra, hogy a kurrensen hasznalt algoritmusa AES CBC volt, a valasz egyertelmuen igen. Mivel ritkan lehet valos kornyezetben mert szamokkal talalkozni, gondoltam megosztom az ertekeket, hatha erdekel valakit. A sebessegmeres speedtest.net -en at tortent, ugyanazon szervert hasznalva minden VPN kapcsolatnal egy masik, lokalisat, VPN nelkul. A crypto ACL szamara az erdekes forgalom a 0/0 volt, tehat minden forgalmat a tunnelbe kuldott.
A routerben nem volt ISM VPN modul.
download upload cpu
no encryption, no vpn 71 mbit/s 18 mbit/s 60%
aes256 + sha512 44 mbit/s 17 mbit/s 100%
aes128 + sha1 54 mbit/s 17 mbit/s 100%
aes256gcm128 58 mbit/s 18 mbit/s 90%
aes192gcm128 59 mbit/s 18 mbit/s 100%
aes128gcm128 59 mbit/s 18 mbit/s 100% -
mrots
tag
válasz
tobias40
#3391
üzenetére
"ide már nem szemetelek tovább."
VPN-t akarsz csinalni, ez pedig egy VPN topik. Nem szemeteles ez. Mondjuk inditasnak szerintem eros volt, hogy lenyegeben azt irtad: van ket asusom de nem akarom elolvasni a doksijukat, igy nem tudom milyen vpn-t tamogatnak, valaki olvassa el helyettem es mondja meg milyet vagy milyeneket tamogat, es ha tobbet, akkor melyiket es hogyan konfiguraljam be.
-
mrots
tag
válasz
Edgar2621
#3361
üzenetére
Amit akarsz, nem fog menni, tapasztalatbol tudom. Regen meg mukodott - nekem is igy van torok netflix elofizetesem, havi ezer forintert. Amikor csinaltam, durvan 4-5 eve, akkor meg nem ellenoriztek azt, hogy a bankkartya milyen orszagbol van. Ma mar igen.
A revolut, amit valaki ajanlott, teljesen rossz javaslat. A revolut kartya orszaghoz van kotve, meghozza ahhoz az orszaghoz amelyben / amilyen iratokkal regisztraltal. A kartya szamabol lehet tudni, hogy melyik orszagba tartozik es mivel nem lesz torok, ezert a torok netflix nem fogja elfogadni.
Ezt onnan tudom, hogy amikor elofizettem a netflixre, siman mukodott, de par evvel kesobb lejart a kartya. Ki akartam cserelni a kurrens revolut kartyara es nem engedte, mondvan, hogy nem torok a kartya. Es tenyleg nem.
A korlatozas megkerulese nem illegalis, de szerintem nem is egyertelmuen tamogatott, amolyan szurke zonas megoldas.
A csaladban mi is tobben hasznaljuk az elofizetest es ez alapjan nekunk ugy tunik, hogy a netflix az alapjan allapitja meg, hogy mi a szokasos tartozkodasi hely, hogy honnan nezted eloszor teven. Mi sosem nezzuk teven (nincs is tevenk) es nincs belole problema. Viszont amint a sogoromek belepnek a sajat tevejukon a mi accountunkba, nem sokkal kesobb jon egy level a netflixtol, hogy latjak ket helyen hasznaljuk. Ilyenkor csak ki kell leptetni a tevet. Ha a masik foldrajzi hely laptopon, telefonon, tableten nezi, akkor soha nem jon ilyen level toluk.
A szolgaltatok mar regota rajottek, hogy IP cimet barki olyat szerez amilyet csak akar, de bankkartyat vagy telefonszamot az adott orszagbol mar nem mindig trivialis. Ha amerikai szeretnel lenni, akkor igazabol 20 perc szerezni egy amerikai telefonszamot es tovabbi ot perc szerezni egy amerikai bankkartyat, tehat a korlatozas siman megkerulheto. De peldaul magyar telefonszamot mar problemasabb szerezni, illetve barmilyen orszagban lehetetlen, ahol iratellenorzeshez kotik es kulfoldi iratokat nem fogadnak el online.
-
mrots
tag
Par napos debuggolas es doksi olvasas utan a megoldas az, hogy a problema nem VPN problema. A VPN kezdemenyezo oldalon az eszkoz nem tamogatja, hogy az ipsec kapcsolat inditasa egy dedikalt routing tablaban tortenjen, mindenkeppen a GRT-ben vagy main-ben akarja azt inditani. Errol mangle szabalyok sem tudjak lebeszelni:
14:05:56 firewall,info [mangle] output: in:(unknown 0) out:vlan_bud-wan, connection-mark:oob connection-state:established proto UDP, 10.7.20.2:500->*VPS IP*:500, len 328a fenti sorban az erdekes az out: resz, ahol a vezetekes ISP-hez tartozo SVI szerepel, ami hibas. A helyes egy masik interfesz lenne (ether4), ahova a mangle szabalyoknak kellene atterelni a forgalmat connection markinggal, de a meglevo beallitasok ellenere ez nem mukodik.
A megoldas most rovid tavon az lesz, hogy elengedem az ipsec VPN-t es atterek openvpn-re, mivel az openvpn tamogatja a VRF-ek hasznalatat ezen a platformon, ellentetben az ipsec vpn-nel. Ha pedig az openvpn egy masik VRF-ben tud letezni, akkor nincs szukseg a connection markingra sem.
-
mrots
tag
Nalam tapasztaltabbakat kerdezek, hogy egy elso ranezesre sikeresen felelpult ipsec kapcsolat, ahol mindket iranyu SA megvan, mitol szimplex megis? Egy strongswan terminal tobb ipsec-et, mind mukodik, kiveve egyet. Az ipsec-en beluli egyik vegpont (10.7.20.2) probalna pingelni a masik vegpontot (10.7.20.13)
ping address=10.7.20.13 src-address=10.7.20.2
SEQ HOST SIZE TTL TIME STATUS
0 10.7.20.13 timeout
1 10.7.20.13 timeout
Ez lathatoan sikertelen, mikozben a celponton latszik a bejovo ICMP request tcpdump-pal:12:26:11.549021 IP (tos 0x0, ttl 255, id 17536, offset 0, flags [none], proto ICMP (1), length 56)
10.7.20.2 > 10.7.20.13: ICMP echo request, id 45930, seq 0, length 36
12:26:12.462573 IP (tos 0x0, ttl 255, id 17618, offset 0, flags [none], proto ICMP (1), length 56)
10.7.20.2 > 10.7.20.13: ICMP echo request, id 45930, seq 256, length 36
12:26:13.460050 IP (tos 0x0, ttl 255, id 17715, offset 0, flags [none], proto ICMP (1), length 56)
10.7.20.2 > 10.7.20.13: ICMP echo request, id 45930, seq 512, length 36a 10.7.20.2 oldalon az SA-k:
14 HE 0x37C1BA0 mature *VPS IP* 10.7.20.2 sha256 aes-cbc 128
15 SHE 0xCDE0A824 mature 10.7.20.2 *VPS IP* sha256 aes-cbc 128Lathato, hogy a pingeles generalt forglamat (S flag a 15-os sorban), de visszairanyban nincs forgalom (hianyzik az S flag a 14-es sorban).
a 10.7.20.13 oldalon az SA-k:
d_gw1-cube[32]: ESTABLISHED 14 minutes ago, *VPS IP*[*VPS IP*]...82.132.246.238[10.7.20.2]
d_gw1-cube{12}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cde0a824_i 037c1ba0_o
d_gw1-cube{12}: 10.7.20.13/32 === 10.7.20.2/32A benne hagyott publikus IP cim egy mobilnetes cim, most epp arrol latszik a router erkezni. Az SPI-k ott vannak de valahogy megsem ketiranyu a forgalom.
A VPN parametereinek (titkositas, hashing, PSK) a hibajat kizarnam, mert kulonben eddig sem jutnek el. A konfiguracio hibaja termeszetesen lehetseges. Ugyanakkor, ha a routeren a VPN forgalmat nem iranyitom a mobilnet fele, hanem hagyom a vezetekes iranyba menni, mint minden forgalmat (kiveszek egy /32 static route-ot ami a mobilnet fele mutat) akkor a kapcsolat felepul es mukodik a vezetekes internetet hasznalva.
ping address=10.7.20.13 src-address=10.7.20.2
SEQ HOST SIZE TTL TIME STATUS
0 10.7.20.13 56 64 113ms661us
1 10.7.20.13 56 64 122ms419usA strongswan oldalon is latszik a felepult kapcsolat, nyilvan az erkezo router most nem mobil internet WAN IP cimrol erkezik, hanem a rendes vezetekes IP cimrol. Tehat a strongswan konfiguracios hibat ugy kompletten kizarnam (a kapcsolat mindket iranybol felepulhet, mert right = %any van).
A mobilszolgaltato hibajat is kizarnam, mert 2 sim van 2 kulon eszkozben (migralok a regi 3G (most mar csak 2G) eszkozrol egy masik 4G eszkozre), a regi eszkozon ugyanehhez a strongswanhoz felepul az ipsec es duplex forgalom megy rajta, az uj eszkozon pedig mobilneten nem, csak vezetekes iranyban.
Marad ket hibalehetoseg. Az egyik a buta 4G router, a masik az uj vpn vegpont esetleg hibas konfiguracioja. Valami mas esetleg, amire nem gondoltam?
-
mrots
tag
válasz
MCGaiwer
#3337
üzenetére
Nalam pont ez tortenik, mint amit te is akarsz. Hasonloan hozzad, van lerakva ket router, kozottuk ipsec vpn. Mindket vegen van tobb vlan, egy a normal vegpontoknak akik helyben lepnek ki az internetre, es egy masik vlan azoknak, akik a szembe oldalon. Mindket vlan-hoz kulon ssid-t szor az AP. De nalam is van olyan vegpont aki az egyik vlanban van, de a masikba tartozna, csak kulonfele okok miatt nem tud beletartozni. Az o szamara egy route-map van letrehozva, amivel policy routing mukodik:
gw#show route-map rm_tunnel
route-map rm_tunnel, permit, sequence 100
Match clauses:
ip address (access-lists): acl_tunnel
Set clauses:
ip next-hop 172.31.255.82 172.31.255.65A fenti route-map, amennyiben a forgalom match-el az ACL-re, a next hopot nem a routing tablabol veszi, hanem a felsorolt ket IP cim kozul az elsot, ha elerheto, valamint a masodikat, ha az elso nem. A default route, ami a tobbi vegpontra vonatkozik egy harmadik, a fenti ket cim az ipsec tunnelekben van (ket tunnel, ket routerhez, redundancia miatt).
gw#sh access-list acl_tunnel
Extended IP access list acl_tunnel
10 permit ip 10.8.30.0 0.0.0.31 anyA fenti a /24 subnet also /27-es tartomanyat jelenti, tehat az elso 32 cim (minusz a halozati cim, stb), elteroen a maradek 224 cimtol nem az alapertelmezett atjarot hasznalja, hanem a vpn-en at kozlekedik. Az egeszet pedig a route-map illeszti a vegpontok fele nezo interfeszre:
gw#sh run int gi 0/1.9 | i policy
ip policy route-map rm_tunnelIgy tehat ha egy adott halozatban egy vegpontnak specialis kezeles kell, akkor elegendo DHCP-n vagy kezzel az also 32 cim kozul valasztani egyet. Ha nem, akkor meg 32 felettieket.
Tipikus use-case: a netflixet futtato tevenek egy halozatban kelll lennie a csaladtagok egyeb cuccaival, hogy parosodni tudjon veluk, de internetre nem helyben kell kilepnie, viszont mindenki masnak igen.
Termeszetesen ez egy kitalalt use-case, hiszen senki nem akarna ket haztartasban hasznalni netflixet, ha egyszer nem szabad megosztani...
-
mrots
tag
A kerdesednel azt irtad, hogy szlovak kartyad van es magyarorszagon hasznaltad, tehat nyilvan roamingoltal. Lehet butasagot mondok, de amikor roamingolsz, akkor az idegen orszagban (ez esetben HU) a mobilszolgaltato csak a hordozo halozat. Az IP konfiguraciot es szureseket a honos halozat (ebben az esetben SK) biztositja, tehat ha barki is szurne barmit, akkor is az SK halozatban keresnem a szurest, hiszen az IP cimet is onnan kapod.
De mivel VPN is volt a dologban - persze nem mindegy milyen VPN - en semmilyen szurest nem tartok valoszinunek szolgaltatoi oldalrol.
Új hozzászólás Aktív témák
ekkold- Telefon felváráslás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- ÁRGARANCIA! Épített KomPhone Ultra 7 265KF 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- Asus TUF Gaming F15 FX507 - 15,6"FHD 144Hz - i5-12500H - 8GB - 512GB SSD - RTX 3050 - 1 év garancia
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7500F 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 12 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3883, 100% Akkumulátor
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest