Sziasztok!
Arra a kérdésre szeretnék választ kapni, hogy egy internet szolgáltató ha a saját kihelyezett modemje brigde üzemmódban fut, és én saját routerrel osztom itthon a netet, akkor ebbe a saját router-be bele tud-e piszkálni és IP cím konfigurációkat átállítni?
A történet röviden:
- Szolgáltato modemje router üzemmódban, saját router szépen osztja a netet, az egész család gond nélkúl netezek, mindenki happy.
- Szolgáltató felhív módosítunk a csomagon telefonon keresztül, majd elköszönünk egymástól.
- Jönnek az SMS-ek a változásról, internet lehal. Saját belső routereket nem tudom többé elérni.
- Nyomozás helyben - hoppá a szolgáltató modemje szórná a netet ezerrel, pedig nem kéne neki.
- Technikai segítség felhív: "Ó igen ilyenkor ez teljesen új szerződésként admiinsztrálódik, valóban a router már nem bridgeként megy." Megegyezünk, hogy állítsuk vissza.
- Modem újra indul, net továbbra sincs sehol, saját router-t a szokásos IP-n sehogy sem érem el... Újabb nyomozás itthon, mi a franc van?
- DHCP-n a korábbi 192.168.0.x alháló helyett a kapott IP 10.84.186.x címen van, a DHCP router pedig 10.84.186.212 lett. Mi van? Belépek, ez a saját routerem. Amihez én nem nyúltam egy újjal sem.
- Login a saját routerre az új IP-n. Be tudok lépni a szokásos jelszavammal, és azt látom, hogy minden korábbi 192.168.0.x -es bejegyzés átírva 10.84.186.x-re. Router saját IP-je, DHCP reservationök, minden.
- Újabb telefon, mi a franc van, hogy képzelik, hogy belematatnak a saját eszközöm konfigjába. Ügyfélszolgálat váltg állítja márpedig ők nem. Panasztétel után elválunk, és szívok, hogy visszaállítsak mindent. :(
Mivel én nem nyúltam a router-hez, valamitől át kellett állnia az IP címeknek. Előtte minden ment, utána minden lehalt és itt vigyorogtak ezek a változások. Szoftver fejleszőként dolgozom, találkozom hálózatokkal, de nem ilyen mélységben.
Van rá mód, lehetőseg technikailag, hogy azt a szolgáltató megtehess? Ha igen, milyen alapon nyúl ő bele az én saját rendszerembe? Ti mit tennétek, hogy ezt a jövőben ne tehesse meg a szolgáltató?
Előre is köszönöm a válaszokat.
Üdv, Csaba
- 1611 megtekintés
Hozzászólások
értelemszerűen nem, hiszen nem tudja a te routered jelszavát. Sőt, jobb esetben wan irányból nem is engedélyezett az admin felület elérése
- A hozzászóláshoz be kell jelentkezni
Az alap ötletem nekem is ez volt.
De akkor mitől változtak meg az IP tartományok?
Mert én nem barmoltam szét a működő rendszeremet. Különösen nem pont akkor mikor ez az egész történt. Semmi más érdemi történés nem volt ebben a időben.
- A hozzászóláshoz be kell jelentkezni
mivel nem írtál konkrét router típust, így fogalmam sincs.
Tippelve, talán ugyanabban a 192.168.0.x ip tartományban natolt a szolgáltatói eszköz, amikor nem bridge módban volt és talán van valami okosság a te routeredben, ami olyankor más tartományra (10.84.186.x ) vált, hogy ne legyen ütközés.
Logokat néztél a routeredben?
- A hozzászóláshoz be kell jelentkezni
Linksys EA 7500 v3
Lehet ebben van valami ilyen okosság?
- A hozzászóláshoz be kell jelentkezni
ami manuált láttam neten, abban nem látom. Logok?
- A hozzászóláshoz be kell jelentkezni
Elvileg könnyen letesztelhető, most be van állítva a belső IP tartomány a DHCP serverben, és gondolom, a külső interface is DHCP-n kap IP címet, a külső interface-t össze kéne dugni egy DHCP serverrel, ami a belső címrtartománnyal megegyező subnetben oszt címet. Ha ezután is átáll, akkor megvan a root cause.
- A hozzászóláshoz be kell jelentkezni
Igen, ezzel lehet futok is még egy kört, de nem most, mert végre az egész család netezik újra, illetve én is tudok dolgozni.
Ami viszont nem szép az eszköztől ha van is benne ilyen automatizmus, hogy a konfigot is átírta. Nem csak észrevette a gondot, és az aktuális működést állította át.
Mikor már gyanakodtam akkor újra indítottam úgy hogy mindenről le volt húzva. És így is megtartotta az új 10.54.186.x tartományt. Sőt a konfigot is lecserélte erre mert már ott is csak ezeket láttam. Mikor nem volt már ütközés akkor is az új konfiggal indult. :(
Az rendben, hogy védje ki az ütközést időlegesen, de azért a konfigokat nem szép átírni ilyen módon automatikusan.
- A hozzászóláshoz be kell jelentkezni
hat az ilyen soho cuccok marcsak ilyen magic wizardok, hogy a gamer pistikenek legyen net ha bedugja 0 konfigolassal.
vegyel mikrotiket ha full controlt akarsz...
- A hozzászóláshoz be kell jelentkezni
vagy rakj rá vmi openwrt jellegűt; az se akar gondolkodni helyetted..
- A hozzászóláshoz be kell jelentkezni
Ez a baj ezekkel a zárt forrású consumer szarokkal: nem azt csinálják, amit szeretnél.
Rakjál rá rendes OS-t, azzal nem lesznek ilyen gondjaid.
- A hozzászóláshoz be kell jelentkezni
Miért baj, hogy megvédte a router firmware attól, hogy ne működjön a NAT?
Ha felraksz rá valami open source retket, akkor általában bukod a drivereket és a sebességet, az miért jó?
- A hozzászóláshoz be kell jelentkezni
Openvéerté: not supported... Egyébként meg definiáld a "rendes" OS-t. Számomra a "rendes" OS az, ami az adott hardver nyújtotta lehetőségeket, képességeket ki tudja használni, képes a hardvert optimálisan üzemeltetni.
Na egy átlagos *wrt vagy hasonló megoldás szinte biztos, hogy a NAT-olás teljesítményét növelő hardveres okosságokat nem fogja tudni - azaz innentől kezdve a célhardverre _nem_ nevezném "rendes" OS-nek. Jelen esetben meg nem az OS, hanem az azon futó router/AP funkció dolgozott úgy, hogy a rendszer az elvárt funkcióját teljesítse felhasználói beavatkozás nélkül akkor is, ha IP-cím ütközés lenne a WAN és a LAN oldal között. Ezt egy *wrt vagy más számodra gondolom "rendes"-nek tekintett firmware tudja, vagy sajtreszelőt kell előszedni az élvezetekhez?
"nem azt csinálják, amit szeretnél." - Szerintem meg azt csinálta: a WAN-oldalon megváltozott network okozta címütközést kezelve továbbra is működött a routing, a LAN-oldalon a DHCP, nagyjából minden _is_. Igen, a webes beállítóoldal elérése is - arra ugyanis a legtöbb ilyen eszköznél egy megadott host.domain-t tartalmazó URL is van, amit vagy maga az eszköz old fel a saját LAN-oldali címére, vagy más módon fordul be oda a kérés.
- A hozzászóláshoz be kell jelentkezni
Openvéerté: not supported..
Hardvert kell tudni vásárolni. Ez anno 20-25 évvel ezelőtt egy random linuxos PC-re is igaz volt, mostanra szerencsére sokat fejlődött az iparág ilyen vonatkozásban, de az kétségtelen, hogy ebben a szegmensben azért még mindig nagy a rendetlenség, főleg persze az irreális termékfejlesztési ciklusidő miatt.
Egyébként meg definiáld a "rendes" OS-t. Számomra a "rendes" OS az, ami az adott hardver nyújtotta lehetőségeket, képességeket ki tudja használni, képes a hardvert optimálisan üzemeltetni.
Akkor egy plusz pont a definíciódhoz: van hozzá rendszeres frissítés, a bugokat kijavítják.
És ezen kb. az összes ilyen consumer távol-keleti fostaliga gyártó elbukik. Egy lepratelep szoftveres szempontból az, amit csinálnak. Kijön az eszköz, Csengcsien WLDR 4200, hardver v1, van rajta egy v1.0.0 szoftververzió, és soha a büdös életben nem lesz további verzió (teljesen nyilvánvaló, hogy nem marad örökre ismert bugoktól mentes, hiszen valójában egy Linux ketyeg benne, arról meg azért lehet tudni, hogy nem marad az). Mert mire esetleg frissítenének, addigra az a design már elavult, már nem is gyártják azt a hardvert, persze a nevet reciklálják: fél év múlva már a WLDR 4200 v2-t árulják - természetesen hardverice köze nincs egymáshoz a két készüléknek, és persze az új hardverhez is készül egy v1.0.0 (ami természetesen nem fut a régi hardveren, hiszen ez egy tök más ketyere) - aztán soha többet másik. Esetleg nagyritkán talán kijön még 1, azaz egy darab frissítés az eszköz élete során, mondjuk v1.0.2, ha valami nagyon vállalhatatlan bug maradt a v1.0.0-ban. Egyébként meg ha nem tetszenek a bugok, akkor semmi baj, kúrd ki a kukába, és vedd meg a következő verziót. Ja, és bónusz még, hogy már rég nincs gyártásban a régi, már a weboldalról is eltüntette a gyártó, de a készleteket még hónapokon át árulják a boltok.
Na egy átlagos *wrt vagy hasonló megoldás szinte biztos, hogy a NAT-olás teljesítményét növelő hardveres okosságokat nem fogja tudni
Akkor a megoldás alkalmatlan a használatra. A hozzá adott szoftver így fos, másikkal meg nem lehet rendesen használni a hardvert, ergó az meg úgy nem jó.
úgy, hogy a rendszer az elvárt funkcióját teljesítse felhasználói beavatkozás nélkül akkor is, ha IP-cím ütközés lenne a WAN és a LAN oldal között.
Az elvárt funkció része az is, hogy azzal az IP-vel menjen, ami be lett állítva. Ha az úgy nem lehetséges, akkor már eleve nem lehetséges az elvárt funkciót teljesíteni. Az, hogy ilyenkor mi legyen a workaround, miből akarok engedni, melyik ujjamba akarok harapni, nem egyértelmű, ha többféle megoldás is elképzelhető, és tőlem nem kérdezték meg, hogy melyiket preferálom (pl. preferálhatom, hogy ha meg is változik az IP-cím, a következő rebootnál álljon vissza az általam konfiguráltra). Azaz ezen a ponton a készülék nem tudhatja, hogy valójában mit is várok el, így pedig nagyjából lehetetlen azt teljesíteni.
Ezt egy *wrt vagy más számodra gondolom "rendes"-nek tekintett firmware tudja, vagy sajtreszelőt kell előszedni az élvezetekhez?
Vajon egy Mikrotik RouterOS vagy egy Cisco IOS mit csinál ugyanebben a helyzetben?
- A hozzászóláshoz be kell jelentkezni
"Hardvert kell tudni vásárolni. " - openvéerté-vel a legtöbb soho doboz nem fogja tudni azt a sávszélességet, amit a gyári, hardverre kihegyezett firmware-rel - hogy a többi kellemes szolgáltatást (pl. mesh, tartalomszűrés, problémás kliensek izolálása és hasonlók) ne is melítsem. Oké, össze lehet reszelni sokmindent _is_, de általában ezeket az eszközöket nem barkácsolni meg openvéertével copkodni veszik, hanem használni.
"Akkor egy plusz pont a definíciódhoz: van hozzá rendszeres frissítés, a bugokat kijavítják." Van ilyen, nekem Linksys-ben is volt ilyenem, a TP-Link az eléggé "link" volt, az Asus viszont egészen korrekten ad támogatást/frissítést. Ha úgy akarom, megcsinálja automatice, ha meg úgy, akkor kapom az értesítést, hogy van új fw, frissítéshez lépjek be, és bökjek a frissítés gombra.
"Az elvárt funkció része az is, hogy azzal az IP-vel menjen, ami be lett állítva. Ha az úgy nem lehetséges, akkor már eleve nem lehetséges az elvárt funkciót teljesíteni. "
Részedről az az elvárt, hogy ha ütközik a belső és a külső címtartomány valamiért, akkor f0ssa össze magát, és ne működjön semmi?
"Vajon egy Mikrotik RouterOS vagy egy Cisco IOS mit csinál ugyanebben a helyzetben?" - Gondolom hagyja a címütközést, aztán a user mehet winbox vagy mifene/konzol, ha úgy adódik... De ezek nem SoHo usereknek lettek kitalálva, akiknél az elvárt szolgáltatás az, hogy az otthoni eszközei elérjék az internetet.
- A hozzászóláshoz be kell jelentkezni
Mit csinál a DHCP rezervált IP-kkel vajon ilyenkor? Nyomtatót, NAS-t fix IP-re rakom általában.
Egyébként az ASUS is egy vicc. RT-AX53U-kat vettem nemrég ez egy 2022-es router. Utolsó firmware rá 2023 februári. Egy nap után ment rá az Openwrt. HW nat támogatással az MT7621-es chipseten. A wifi konkrétan ugyanolyan gyors mint a gyári firmware-val (MT76 wifi az egyetlen kb Openwrt-n ami tudja az AX-et a nyílt driverrel). Megy a roaming is több AP között.
Az ASUS-on a 4.9.198-as kernelt (2019 hello! 2023-at írunk) sosem frissítik. Hiába jön frissebb firmware (3 verziót néztem), a kernel marad, persze lehet a drivereket patchelgetik benne,de azért a kernel nem csak driverekből áll.
Élek a gyanúperrel, hogy az Asus is úgy csinálja, hogy a chipsethez adott /megvett SDK-ból csinálgatja a buildeket. Ha az SDK nem frissül az azzal jövő komponensek úgy maradnak.
A routeren van USB port. Samba 4.0.24 -es verzió a "NAS" funkcióhoz. Könyörgöm 2015-ös verzió hemzseg a CVE-ktől.
Még azok a gyártók a jobbak, akik Openwrt alapú firmware-kat (Tp-Link, Xiaomi pl) használnak a saját drivereikkel. De ott is az van általában , hogy az adott típushoz egyszer lebuildelik az aktuális Openwrt verziót és az a termék életciklusa alatt nem változik.
- A hozzászóláshoz be kell jelentkezni
A DHCP-rezervált címekkel azt tudja csinálni, hogy a network részt cseréli, a host részt meg békén hagyja.
"Az ASUS-on a 4.9.198-as kernelt (2019 hello! 2023-at írunk) sosem frissítik." - Van-e olyan kritikus bug az adott kernelben, ami kihasználhatóan érinti az adott eszközre összeállított kernelt? Mennyivel jobb az az eszköz, amin 4.15.0 kernel van...?
A SaMBa CVE-ket nézegetve igen, van belőlük jónéhány - aminek jelentős része heap/buffer túlírás/kezelés probléma, amivel kódfuttatásra lehet rávenni a megtámadott eszközt. Ez egy belső hálózaton, nem x86-os hardveren mekkora valós kockázatot jelent? De a DC funkciók támadhatósága sem igazán számít ebben az esetben kritikusnak. De ha ennyire belemegyünk, akkor ugye az openvéertés szambában a server signing = mandatory és az smb encrypt = required be van állítva/az az alapértelmezett?
"Még azok a gyártók a jobbak, akik Openwrt alapú firmware-kat" - Például az Asus is ilyen, ha jól tévedek...
- A hozzászóláshoz be kell jelentkezni
"Még azok a gyártók a jobbak, akik Openwrt alapú firmware-kat" - Például az Asus is ilyen, ha jól tévedek...
Ha jól tudom Tomato alapúak(ami szintén nagyon jó volt szerintem anno). Van viszont a gyári firmwaren alapuló asuswrt-merlin is, ha valakinek az jobban tetszik.
- A hozzászóláshoz be kell jelentkezni
Nekem megfelel a TrendMicro-s szűréssel érkező gyári Asus firmware is...
- A hozzászóláshoz be kell jelentkezni
Nekem is. Egy nyűgöm van vele az a lassú GUI és a mobil verzió szerintem bugos. Mobil Chromeban asztali nézetet kell kérni hogy megjelenjen rendesen, de ezek már csak kákán csomót keresés.
- A hozzászóláshoz be kell jelentkezni
Nekem az elődjének a GUI-ja volt retek lassú, ez a mostani (AX58U) teljesen korrekten megy, akár Chrome, akár Edge, akár Firefox alól nézem.
- A hozzászóláshoz be kell jelentkezni
Én is néztem a manuált, de nem látom nyomát ilyesminek.
Sajnos a logolás nem volt bekapcsolva, úgyhogy ott nem látom mi történt. :(
Most bekapcsoltam, hogy legközelebb az is használható legyen ha valami előáll.
- A hozzászóláshoz be kell jelentkezni
DHCP bug - ezt adta a szolgaltatod, vagy igy reagalt a routered arra, amit a szolgaltatod mondott neki.
A confighoz nem nyulhat a szolgaltato, de dhcp-n kuldhet hulyeseget a hulyen configolt sajat modemroutere.
- A hozzászóláshoz be kell jelentkezni
Ha viszont a fentiek mellett mégis hozzáférhető (gyenge jelszó, tűzfal hiánya), akkor pont nem a szolgáltatód lesz az, aki belebarmol.
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"
- A hozzászóláshoz be kell jelentkezni
Jelszó át van állítva fejlesztőként erre érzékeny vagyok, van benne minden ami kell.
És az időbeli egybeesést azért nehéz lenne produkálni random betörési kísérlettel ...
Szóval ezt az opciót kizárnám.
- A hozzászóláshoz be kell jelentkezni
A saját routereden valószínűleg dhcp az elsődleges beállítás, fix ip (192.168.0.x) a másodlagos. Ha a szolgáltató eszköze router módban van, a sajátod attól kap ip-t (10.84.186.x).
- A hozzászóláshoz be kell jelentkezni
nem irta melyik isp, de altalaban a bridge modban is dhcp-n kapja a WAN cimet, meg akkor is, ha fixip-s elofizetese van...
- A hozzászóláshoz be kell jelentkezni
Igen a szolgáltató felől DHCP-n kapom az IP-t. Ez rendben is van. Ez a külső interfész.
A problémám az volt, hogy a szolgáltató modemének változásai után (bringe mód --> router mód --> vissza bridge módba) a saját routerem configurációja a belső, lokális hálózatra vonztkozóan megváltozott. És egy teljesen más IP tartományban kezdett el befele dolgozni. És ezek a változások megmaradtak a fenti játék után is és átíródtak a konfigban.
Ez az amire szeretnék magyarázatot találni.
- A hozzászóláshoz be kell jelentkezni
gondolom eddig is dhcp-n kapta a WAN cimet, es most mas kap, ennyi.
- A hozzászóláshoz be kell jelentkezni
Nem a WAN felé néző oldallal volt a gondom, hanme a belső hálózatos IP konfigurációkkal.
- A hozzászóláshoz be kell jelentkezni
> DHCP-n a korábbi 192.168.0.x alháló helyett
gondolom a szolgaltato eszkoze router modban a 192.168.0.x tartomanyt hasznalta, es ezert valtott a router masra belul, mert utkozott volna es ugy nem mukodik.
esetleg a dhcp classless routes option kavarhat be, amit pl. iptv miatt hasznalnak, es ki tudja az ilyen csoda soho routerek mennyire probalnak kompatibilisek lenni vele.
- A hozzászóláshoz be kell jelentkezni
Tp-link routereknél látok olyat, hogy default 192.168.0.1 az ip-je és ha wanon is ebből a poolból kap címet, akkor restartol és 1.1-re módosítja a saját lan oldalát. Manualban én ezt sehol nem láttam feltüntetve
- A hozzászóláshoz be kell jelentkezni
No akkor... Volt a bridge mód, ekkor a szolgáltató DHCP-szerverétől kaptál nem a 192.168.0.0/16-ból a WAN portra címet, a saját routered ekkor a belső oldalra osztott ebből címeket. Jött a szolgáltatói eszköz átbillenése router módba, ami szépen adott a te routerednek olyan tartományból IP-címet DHCP-n, amit ő a belső oldalon használt. Erre a routered a belső címtartományt nemes egyszerűséggel lecserélte olyanra, ami biztosan nem ütközik a 192.168-as priváttal. Ez után a wan oldal a szolgáltatói eszköz bridge módba billenése után újra más címet kapott, de a routered erre már nem állította vissza a belső lábon a címtartományt.
- A hozzászóláshoz be kell jelentkezni
Na pont az ilyen értékes infók miatt nem adtam fel még a HUP látogatását.
- A hozzászóláshoz be kell jelentkezni
Programozóul (csak bele kell nézni a firmwarebe (vagy a logokba) :))
ulog network_functions status "Conflict detected between Lan Networks and Wan Subnet ($PROHIBITED_ADDR)"
elif [ -n "$SYSCFG_lan_ipaddr" -a -z "$PROHIBITED_ADDR" ] ; then
sysevent set lan_ipaddr $SYSCFG_lan_ipaddr
sysevent set lan_prefix_len $LAN_PREFIX_LEN
eval `ipcalc -n ${SYSCFG_lan_ipaddr}/${LAN_PREFIX_LEN}`
sysevent set lan_network $NETWORK
sysevent set firewall-restart
return 0
fi
LAN_NAME=`syscfg get lan_ifname`
BYTE3=0x`ip link show $LAN_NAME | grep link | awk '{print $2}' | awk 'BEGIN { FS = ":" } ; { printf ("%s", $6) }'`
BYTE3=`echo $BYTE3 | awk ' {printf ("%d", $1)}'`
BYTE2=0x`ip link show $LAN_NAME | grep link | awk '{print $2}' | awk 'BEGIN { FS = ":" } ; { printf ("%s", $5) }'`
BYTE2=`echo $BYTE2 | awk ' {printf ("%d", $1)}'`
BYTE1=0x`ip link show $LAN_NAME | grep link | awk '{print $2}' | awk 'BEGIN { FS = ":" } ; { printf ("%s", $4) }'`
BYTE1=`echo $BYTE1 | awk ' {printf ("%d", $1)}'`
make_random_subnets $BYTE1 $BYTE2 $BYTE3 $LAN_PREFIX_LEN $PROHIBITED_ADDR
LAN_SUBNET=$RANDOM_SUBNET_1
GUEST_LAN_SUBNET=$RANDOM_SUBNET_2
GUEST_LAN_PREFIX_LEN=24
RANDOM=`expr $RANDOM - $BYTE3`
OCTET4=`expr $RANDOM % 255`
if [ "0" -eq $OCTET4 ]
then
OCTET4=63
fi
make_ip_using_subnet $LAN_SUBNET $LAN_PREFIX_LEN $OCTET4
syscfg set lan_ipaddr $CREATED_IP_ADDRESS
sysevent set lan_ipaddr $CREATED_IP_ADDRESS
sysevent set lan_prefix_len $LAN_PREFIX_LEN
eval `ipcalc -n ${CREATED_IP_ADDRESS}/${LAN_PREFIX_LEN}`
sysevent set lan_network $NETWORK
make_ip_using_subnet $GUEST_LAN_SUBNET 24 $OCTET4
syscfg set guest_lan_ipaddr $CREATED_IP_ADDRESS
syscfg set guest_subnet $GUEST_LAN_SUBNET
if [ "$SYSCFG_lan_ipaddr" != `syscfg get lan_ipaddr` ]
then
sysevent set firewall-restart
syscfg commit
STATUS=`sysevent get lan-status`
if [ "started" = "$STATUS" ]
then
sysevent set wan_conflict_resolved 1
sysevent set lan-restart
fi
fi
- A hozzászóláshoz be kell jelentkezni
1. Szolgáltato modemje router üzemmódban, saját router szépen osztja a netet
vs.
5. Technikai segítség felhív: "Ó igen ilyenkor ez teljesen új szerződésként admiinsztrálódik, valóban a router már nem bridgeként megy."
Képzavar. Nem segít megfejteni mi történt, de valszeg az eredeti problémának csak a triggere. A kevés infoból megszokott "vélekedéseket" már leírták. Szóval tovább kellene menni azon, hogy miért is csinálja ezt a routered, vagy ha ezt nem lehet a bizalomhiányból fakadóan kukázni.
- A hozzászóláshoz be kell jelentkezni
szerintem elég egyértelmű, hogy bridge üzemmódra gondolt, csak elírta.
- A hozzászóláshoz be kell jelentkezni
Miért lenne egyértelmű? Nem lehetne a második router a router módban felkonfigurált cucc mögött? Elég gyakori, ha több szolgáltatást vesz igénybe.
- A hozzászóláshoz be kell jelentkezni
1) Ha a szolgáltatód a WAN oldal felől hozzá tud piszkálni a routeredhez, akkor talán meg kéne köszönni, hogy rámutattak egy sebezhetőségre, mert ebben az esetben az internet felől bárki hozzá piszkálhat a routeredhez a WAN oldal felől és ez több mint gáz. (Egyébként gyanús, hogy nem ez történt, már csak azért sem, mert akkor fel kéne tenni azt a kérdést is, hogy ugyan miért tenné ezt? Miért akarna kicseszegetni a saját ügyfeleivel? Szembe megy az üzleti érdekeivel.)
2) Ha már "saját kézbe veszed" a belső hálózatod kezelését, akkor miért jó, hogy egyébként pontosan ugyanazt a tartományt használod, amiből majd mindenki oszt alapértelmezetten? Ilyen esetben a 192.168.[0|1|100|200].0/24 tartományt nem használjuk! Csendesen hozzá teszem: jelenleg is van olyan ügyfelünk, aki a céges hálóban ezt a tartományt használja - ha az otthoni vagy saját céges belső hálózat is ezen IP-ket használná,a VPN máris fenn akadna, mert a fogadó mögött is ugyanaz a subnet lenne, mint ami a helyi háló.
3) Nem szeretem azt az okos eszközt, ami helyettem kitalálja, hogy mi jó nekem - esetünkben subnetet vált. Ugyanakkor amiatt, hogy napjainkban közel 0 informatikai tudással mindenki netet akar használni, sajnos van létjogosultsága az ilyen feature-öknek, mert r1 usert nem érdekli, hogy milyen IP címet kapott. Őt az érdekli, hogy működjön. És működni akkor is fog, ha a belső háló hirtelen a 172.16.x.y/z tartományra állt át.
Viszont aki nem r1 user, az a 2. pontban leírtakkal biztosítja, hogy ez a feature még véletlenül se süljön el (de ha igazán szerencséje van, akkor ez a feature kikapcsolható menüből és ki is kapcsolja).
- A hozzászóláshoz be kell jelentkezni
ha az otthoni vagy saját céges belső hálózat is ezen IP-ket használná,a VPN máris fenn akadna, mert a fogadó mögött is ugyanaz a subnet lenne, mint ami a helyi háló
- A hozzászóláshoz be kell jelentkezni
Nem mindenütt mezitlábas openvpn és társai zizegnek... Mondjuk egy chipkártyás vagy más 2FA-s VPN-ed van, ott nem biztos, hogy működik az, hogy valahol egy másik eszközön építed fel a VPN-t és ott mókolod a forgalmat... Arról nem is beszélve, hogy ezzel a saját teljes otthoni hálózatodat annak az internetes kijáratával együtt összerouteolod a céges hálózattal, amit értelmes helyen nem néznek jó szemmel, hogy finoman fogalmazzak...
- A hozzászóláshoz be kell jelentkezni
Látom, sikerült megragadni a lényeget ;-)
Az iptables/netfilter NETMAP target-jén volt a hangsúly, amivel megoldható az, hogy két azonos IP subnetet összeköss (nem feltétlenül OpenVPN-nel).
Az említett céges hálózathoz pedig a júzerek természetesen nem férnek hozzá :-)
- A hozzászóláshoz be kell jelentkezni
"VPN routeren " - mármint szerver oldalon?
- A hozzászóláshoz be kell jelentkezni
Gondolom az otthoni routerén belőtte a vpn kliens funkciót, ami felcsattan a céges hálóra, aztán a routere meg jól összekapcsolja az otthoni teljes hálózatával... Meg az internettel is...
- A hozzászóláshoz be kell jelentkezni
Rendben, megoldható. Igaz.
Azért pár kérdést feltennék ennek kapcsán:
- biztos jó-e, hogy kliens oldalon szöszölni kell azzal, hogy működjön?
- mennyire "egyszerű" ezt a trükköt más OS alatt megoldani?
- hogy kezeled le azt az esetet, amikor mindkét oldalon azonos IP is van és mindkettő elérése szükséges? (pl. 192.168.1.10 a helyi DNS és 192.168.1.10 a ticketing rendszer a céges hálóban.)
- A hozzászóláshoz be kell jelentkezni
- biztos jó-e, hogy kliens oldalon szöszölni kell azzal, hogy működjön?
Kliens oldalon nem kell semmit csinálni, csak más IP címen hivatkozni az adott erőforrásra, dehát ezért van a DNS.
- hogy kezeled le azt az esetet, amikor mindkét oldalon azonos IP is van és mindkettő elérése szükséges? (pl. 192.168.1.10 a helyi DNS és 192.168.1.10 a ticketing rendszer a céges hálóban.)
Úgy volt elképzelve, hogy a VPN amúgy is a céges DNS-t használja, hogy a céges szerverek nevét fel tudja oldani. Ha nem akarod a VPN-en a céges DNS-t használni, akkor marad a hosts file.
Amúgy pedig ha el akarod érni a helyi hálón levő 192.168.1.10 gépet, akkor a valódi IP-vel hivatkozol rá, ha meg a ticketing.céges.hu-t akarod elérni, arra a DNS/hosts file nem a valódi IP-t (192.168.1.10) adja vissza, hanem mondjuk a 192.168.254.10-et, a céges VPN szerver pedig ezt az IP-t visszaalakítja (a NETMAP target-tel) a valódi IP-re.
- A hozzászóláshoz be kell jelentkezni
A VPN-t egy darab kliens gép _és_ a céges VPN-kiszolgáló között kell kihúzni, ez az egyik. A DNS-szerver, ami a céges hálón, a VPN túloldalán található, az neked a 192.168.0/24-ből fogja visszaadni a címét a céges hálón lévő gépnek, úgyhogy vagy megmókolod a DNS-választ, hogy olyan címre próbáljon a géped kapcsolódni, ami nem lokálisan connected hálóban van, _és_ valahol a postroute-ban ezt a címet lecseréled, miután már megvan, hogy a vpn-tunnel felé kell mennie, vagy elviszed a 192.168.1.0/24-ből a gépedet.
- A hozzászóláshoz be kell jelentkezni
Kliens oldalon nem kell semmit csinálni, csak más IP címen hivatkozni az adott erőforrásra, dehát ezért van a DNS.
Értem, hogy így is megoldható - de ez nem erőltetett kicsit? Kezdjük azon, hogy melyik DNS trükközzön? A kliensé nyilván nem fog, mert az a céges oldali bejegyzésekről mit se tud. A céges DNS viszont miért adna rossz IP-t vissza? Mert onnastól a nem VPN-ből jövő forgalom fog csuklani.
Igen, tudom, lehet többfejű DNS-t is készíteni és ha a lekérdezés VPN-ből jön, akkor kamu IP-t ad vissza, ami a VPN fogadó-n meg map-elésre kerül a jó cél IP-re - de erre sem feltétlenül lesz szükség, ha a kliens nem átfedő tartományban van, hiszen akkor az egész trükközésre nincs szükség.
Szóval normális esetben az ilyen bonyolítás helyett inkább a nem ütköző LAN-okra érdemes átállni - már csak azért is, mert az általad vázolt esetben a konfiguráció bonyolultsága jelentősen megnöveli a hiba esélylét és a nyomkövetést sem fogja egyszerűsíteni. Persze értem én, hogy a sajtreszelővel is lehet nemi életet élni és az élvezetet a művelet befejezése jelenti, de én inkább kihagyom ezt az irányt.
- A hozzászóláshoz be kell jelentkezni
Ez volt a kiindulás:
ha az otthoni vagy saját céges belső hálózat is ezen IP-ket használná,a VPN máris fenn akadna, mert a fogadó mögött is ugyanaz a subnet lenne, mint ami a helyi háló
Erre írtam, hogy ha nincs más lehetőség, akkor meg lehet oldani, és nem pedig azt, hogy ez a legjobb megoldás :-)
- A hozzászóláshoz be kell jelentkezni
A home hálózatot pikk-pakk át lehet állítani más címtartományra szükség esetén. Még rezervált IP-kkel sem túl nagy ügy. Amíg meg nincs ütközés, nem mindegy, mi a saját címtartományom?
- A hozzászóláshoz be kell jelentkezni
Ehhez meg hozzavennem a 192.168.88.0/24-et, amit a Mikrotik hasznal alapbol.
- A hozzászóláshoz be kell jelentkezni
TP-LINK és ASUS esetében ez teljesen normális működés, gondolom a Linksys is felült erre a vonatra. Ha a WAN oldali cím ütközik a LAN oldali DHCP pool-lal, a router rögvest intenzív állítgatásba kezd.
Engem zavar, nincs is ilyen eszközöm. MikroTik-et illetve OpenWRT-t használok (utóbbit MT7621 chipset-tel, így van IPv4 és IPv6 HW offload, tehát bírja a gigabitet 0% CPU terheléssel). Maga a funkció viszont hasznos, az ismerettségi kör hálózatban járatlan tagjait mentette már meg amikor az ISP cserélte vagy módosította az eszközét. A TP-LINK-nél elvileg ezért van a tplinklogin.net, valami ilyen az ASUS-nak is van, hogy ha megváltozik a LAN oldali subnet, akkor a felhasználónak ne kelljen túrnia az átjáró címét (ami a routeré is).
TheAdam
- A hozzászóláshoz be kell jelentkezni
9. Újabb telefon, mi a franc van, hogy képzelik, hogy belematatnak a saját eszközöm konfigjába. Ügyfélszolgálat váltg állítja márpedig ők nem. Panasztétel után elválunk, és szívok, hogy visszaállítsak mindent. :(
Hogy a lofaszba allitott volna barki barmit a te sajat tulajdonu routereden anelkul hogy tudna az admin usert/jelszot hozza?
Fantasztikus elmeny lehettel az ugyfelszolgalatosnak, egy agressziv anyazo hulye aki azt hiszi hogy okos. A letezo legrosszabb fajta.
- A hozzászóláshoz be kell jelentkezni
Jobb helyen elég hamar át lehet billenni abba a kategóriába, ahol az üfsz. sértegetése (az anyázás már ebbe a körbe tartozik) okán felmondja a szolgáltató a szerződést... (Mivel az internet szolgáltatót nem terheli szerződési kötelezettség, így elhajthatja a nagyon bunkó és problémás ügyfeleket...)
- A hozzászóláshoz be kell jelentkezni
es mi lesz olyankor az egyebkent felmondhattalan husegidokkel?
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben az üf. szegett szerződést (ahol erre (üfsz. sértegetése és hasonlók) kitérnek, ott annak minősül ugyanis), így a szolgáltató jogszerűen mondja fel a szerződést. Mivel pedig az üf.-nek felróható okból történik, az üf. viseli a felmondás valamennyi hátrányos következményét - ide értve a hűségidő előtti felmondásra kikötött kötbér megfizetését is. (A hűségidős szerződés sem felmondhatatlan, csak a felmondásának vannak anyagi és akár egyéb (pl. adott létesítési címre x időn belül nem köt új szerződést a szolgáltató) hátrányos következményei.)
- A hozzászóláshoz be kell jelentkezni
(Nem, semmi közöm hozzá :D )
- A hozzászóláshoz be kell jelentkezni
Mennyivel egyszerűbb lett volna előbb kérdezni itt, nem a szolgáltatót gyanúsítgatni és vádaskodni... A hozzá nem értő ügyfélnél sokkal rosszabb típus, aki hozzáértőnek gondolja magát és tartja magát az igazához, még ha mindenki szembe is jön az autópályán.
Nyilván a szemét szolgáltató mást sem csinál, mint gyanútlan ügyfelek saját eszközeibe nyúl bele (először persze jól fel is töri őket, ha nem admin/admin a user/pass) és átállítgatja őket, hadd szívjanak vele az előfizetők :-)
- A hozzászóláshoz be kell jelentkezni
Így van, nem is értem, hogy merül fel valakiben, hogy az lehet a magyarázat, hogy a szolgáltató nyúlt bele az előfizető saját routerébe. Azon túl, hogy technikailag sem igazán lehetséges ilyesmi, az is elképzelhetetlen hogy ember meg idő legyen arra, hogy ennek nekiálljanak.
- A hozzászóláshoz be kell jelentkezni