UPC modemcsere után a 80 és a 443 port nem megy

Hálózatok általános

Hello,

A következő a problémám.
Két hete cserélt a UPC modemet (CGNV4-EU). A modem mögött egy Mikrotik router van. A router fix ip-t kap a modemtől DHCP-vel. A router-en nyitva van pár port ami NAT-olva van. Ezek közül a 80-as és a 443-as is nyitva van, de ezek valamiért nem működnek. Konkrétan egy csomag sem jut el a router-ig belőlük.

A router helyére egy gépet rádugva Wireshark-al sem jön be csomag erre a két portra.
A UPC ügyfélszolgálat széttárja a karját, hogy ők nem korlátozzák ezeket a portokat. Mindent elhiszek, de valahol csak elakadnak azok a csomagok és nem nagyon tudom merre tovább.
Plusz adalék, hogy config hiba miatt 3 napig sikerült open proxy-t üzemeltetnem :(, így fel is került az említett ip pár feketelistára, de sikeresen leküzdöttem magam róluk.
Kb. eddig jutottam.
Ha van ötletetek ne kíméljetek!
Köszönöm előre is!

  • 6629 megtekintés

( KicsiBocs | 2018. 06. 20., sze – 22:01 )

Established és a Releted engedélyezve vannak a Connection State-nél a MikroTik tűzfalában? DNS redirect be van állítva? Ping megy pl: dns névre? stb.

( blackluck v | 2018. 06. 20., sze – 22:21 )

Modemben mit allitottal be, port forwardokat, dmz-t, netan upnp-vel akarod megoldani?

Beszéltem az ügyfélszolgálattal. A modem szerintük bridge módban van, de úgy tesz, mintha gw módban lenne. :(. Tehát lehet rajta állítani port forwardot meg mindent amit egy jóképű routeren állíthat az ember, de nincs hatása. Kipróbáltam, így is van.
A factory reset is megvolt, de most sem működik.

Megzavart az nyito kiirasban levo modem ad fix ip-t szoveg, abbol arra gondoltam dhcp range-bol reservalt privat ip-t oszt a modem, egyebkent ha publikus fix ip-d van azt nem a modem osztja hanem a kozponti dhcp szerver vagy felveszed kezzel, de akkor ezek szerint valami business szolgaltatasod van.
Ezesetben viszont erosen ketlem hogy modem limitalna teged, miket teszteltel amibol arra gondolsz hogy 80,443-as portod a publikus fix ip-den szurve van?

Nos. Két független külső gépről próbálom az említett két portot. Egy mikrotik routerem van, egy bit sem jelenik meg ezen a porton. A routert lecseréltem egy másikra, amin természetesen korábban működött, azzal sem megy. Leszedtem a routert, tettem rá egy pc-t. Indítottam Wireshark-ot. Semmi. Ha ugyanerre az ip-re egy másik porton, pl. 26,33389, 8443 (ami ekvivalens esetemben a 443-al, mert ugyanarra a gépre mutat és ugyanarra a portra) kapcsolódok, akkor működik.

Elkepzelheto hogy tud ilyet is, de azert furcsalnam hogy latszolag egy uzleti szolgaltatas reszekent ahol fix ip-t adnak rajta ilyeneket leszurne defaultban, mint http vagy ssh eleres.
Legalabbis gondolom nem csak par elofizetonek adja ezt az eszkozt a szolgaltato es sokan kozuluk ha fix ip-t kernek akkor fenti hiba nagy esellyel elokerult volna tobbseguknel.
Persze ettol megprobalhat kerni masik eszkozt, gondolom megfelelo ugyintezo vagy szerelo nem fog ezen problemazni, csak nehezen hiszem hogy kompletten a modem tipus a baj es nem valami egyeb egyedibb konfiguracios dolog okozza.

Milyen megfelelo valaszt varnal?
Ha latatlanban toredekinfokbol ki tudnam talalni mi lehet a problema forrasa akkor jo esellyel most lottoszelvenyt szorongatva azon otletelnek mikre koltsem a leendo milliokat.

"Úgy néz ki, nem kapcsolható bridge módba"
Nem, ugy nez ki mivel publikus fix ip-t kap igy bridge modban van!

Beszéltem az ügyfélszolgálattal. A modem szerintük bridge módban van, de úgy tesz, mintha gw módban lenne. :(. Tehát lehet rajta állítani port forwardot meg mindent amit egy jóképű routeren állíthat az ember, de nincs hatása. Kipróbáltam, így is van.
A factory reset is megvolt, de most sem működik.

Csak UPNP IGD van. A Residential Gateway Function nem látható.

Ezeket úgy morzsolgasd egy kicsit!
Az első alapján gw módban van (és kap a ((modem=router)) fix ip címet).
A második alapján nem is lehet bridge módba kapcsolni.
Az ügyfélszolgálatnak meg lila fingja sincsen semmiről.

Nem kell nekem elhinni semmit. Itt egy szolgáltatói leírás.

Az UPC esetén meg lehet módosított fw rajta. Ekkor lehet a fw vagy a modem cseréjét kérni.

"Az első alapján gw módban van (és kap a ((modem=router)) fix ip címet)."

Ehhez morzsold hozza, hogy:
"A modem mögött egy Mikrotik router van. A router fix ip-t kap a modemtől"
Illetve:
"Milyen ip-t kapsz a modemtol, publikus vagy privatot? "
"Publikust."

Tehat nem a modem kapja azt az ip-t, hanem mogotte az sajat routere vagy amit rakot, ergo bridge modban van a modem.

Az hogy nem lehet kapcsolni a bridge modot illetve hogy az angliai doksiban azt irjak kb semmit nem jelent.
Nem biztos hogy a hazai modemeken ugyanugy konfiguraljak, lehet nalunk azt letiltjak, vagy az is lehet nem csak egy fajta konfiggal (szolgaltatoi konfig, mert ezeknek van olyan resze is ami konfigolhato de nem ugyfel szamara) vagy mas firmware-el adjak idehaza is, lehet vannak eltero csomagok eltero beallitasokkal es az ovenel fixen be van kapcsolva a bridge mod ezert nem adja fel opcios valasztasnak.

Ugyhogy en tovabbra is fenntartom, hogy sokkal inkabb konfiguracios gondnak tunik ez nekem, mint altalanos hibanak (pl. lehet hogy a lent emlitet wan oldali management eleres beallitas irja felul).

( bucko | 2018. 06. 20., sze – 22:24 )

Ez a modem egy router. ;)
Bridge módba van kapcsolva?

Ha nem, akkor
Residential Gateway Function -> Disabled.
(Doksi 49. oldal.)

Tegnap óta van a hiba. Annyi történt hogy bekapcsoltam tegnap előtt a 25-ös portot.

Percekkel ezelőtt a UPC azt ígérte hogy mélyre ásnak és visszahívnak.

Megemlítettem hogy látom az interneten fórumokban (itt füllentettem a többes számot) gondolom ezért intézkednek.

( azbest | 2018. 06. 21., cs – 10:56 )

Ahogy már mások is írták, ha a upc eszköz routerként megy, akkor natol, természetesen nem fog magától menni a port átirányítást rajta, hanem be kell állítani. Vagy bridge módot kérni, ha lehet.
Azt sem lenne hülyeség megnézni, hogy a upc eszköz publikus ip címet kap-e, mert ha natoltat oszt (nem tudom) a upc, akkor esetleg már az az eszköz sem érhető el kívülről. Az eszköz csere miatt benne lehet a pakliban, hogyha külön kell kérni a publikus címet, akkor az új eszközhöz megint kérni kell.

( vlezlee | 2018. 06. 21., cs – 19:17 )

Cserélj szolgáltatót!
Nekem nem egy ügyfelemnél egyszerűen blokkolják a VPN forgalmat (pptp be sem jön, l2tp/ipsec-nél az auth átmegy de utána egy bitet sem enged át). Ebből kiindulva bármi mást is simán blokkolhatnak.

Szívtam nem keveset az ügyfélszolgálattal és a technikusaikkal, kötik az ebet a karóhoz, hogy márpedig ők semmit nem blokkolnak...

( royal v | 2018. 06. 22., p – 14:54 )

Nem lehet, hogy a CGNV4-EU a saját webes admin felületére számára fogja le a 80 és 443 portokat, mert engedve van neki a WAN felőli adminisztrációs hozzáférés?

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

( gyengus | 2018. 06. 24., v – 08:40 )

Sziasztok!

Nekem se érhető el a 80-as és a 443-as portom: ERR_CONNECTION_REFUSED
Nálam annyiban másabb a helyzet, hogy nem volt modem csere, az éjszaka 00:32-kor jött az értesítés, hogy nem elérhető az oldalam. Régóta működik megfelelően a jelenlegi konfiguráció. A modem (TC7200.U) bridge módban, mögötte a routerem, azon portforward beállítva. Az emailek megjönnek (az itthoni szerveremen van a mail szerver), a Seafile is elérhető kívülről). Valószínűleg 'csak' a webes portokkal van a gond. Ez a problémája megoldódott már valakinek? Mi volt a megoldás?

Off, de ennek kapcsán derült ki:
A házi szerveremen Dockerben fut egy Bind9 (már hajlok rá, hogy csomagkezelővel feltelepítem, esetleg egy RPI Zerora), beállítottam, hogy a domainjeim a szerverem belső IP-jére mutassanak. Ha a desktop gépről próbálom feloldani ezeket a domaineket, akkor a külső IP-met kapom, de, ha megadom neki, hogy a szerveremen futó Bind9-ről kérje le, akkor a belső IP-t kapom meg. A routeren beállítottam, hogy DHCP-nél a szerevem IP-jét és egy OpenDNS-t adjon névkiszolgálónak. A dig szerint az 127.0.0.53-as IP-n próbálja az ubuntu a névfeloldást. Miért nem a szerveremet használja?

MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'

Beszéltem az ügyfélszolgálattal, elmondtam, hogy mi a hibaüzenet, hogy csak az a 2 port rossz és, hogy másnál is van/volt ilyen probléma. Ő ellenben nem látott semmi problémát, szerinte nem az ő oldalukon van a probléma.
Mi lehet a megoldás? Merre induljak?

MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'

Tényleg nem náluk volt a gond. Az apache2-al volt valami, újraindítottam és most jó.
Ez van az error.log-ban:
[Sun Jun 24 00:26:39.439804 2018] [mpm_prefork:notice] [pid 9734] AH00169: caught SIGTERM, shutting down
Csakhogy én nem állítottam le.

Rossz irányba indultam el a hibakereséskor. A héten olvastam ezt a témát és egyből arra gondoltam, hogy nálam is hasonló a hiba.

MODding | Asztali PC | Személyes weboldalam
'Everybody loves LEDs'

( VincentV | 2018. 06. 24., v – 11:27 )

Le kell sorjázni baltával, vissza kell menni a kályhához:

- Mikrotik kiszed, kikapcsol
- UPC modem restart
- UPC modem router módba átrak, ha bridge-ben volt eddig, majd ismét vissza bridge-be (hátha ettől magához tér, ha ő volt a hunyó)
- laptop modemre ráköt, kapott IP cím megnéz, ellenőríz (publikus e, illetve ha igen, akkor azt a fixet kapod e ami a tiéd)
- laptopon netcat-el a problémás portokra echo-zni valamit
- külső gépről telnet a portokra
- közben tcpdump

Nyilván a laptopon valamilyen faék egyszerű dolog fusson, csomagszűrő/tűzfal nélkül, valamilyen egyszerűbb live linux, akár egy telepítő rescue módja tökéletes.

Ha megy minden: Mikrotik vissza, túrás/javítás abban (ha kell).
Ha nem megy: egyértelműen a UPC sara, és ezt se te, sem a jelenlevők nem fogják tudni megoldani, őket kell ütni.

Én az utóbbit eléggé különösnek tartanám. Ugyanis ez azt jelenti, hogy valamilyen UPC-s eszköz belenyúl alkalmazás szinten is a forgalomba. Bár manapság már nem szabad meglepődni semmin, azért ez mégis egy kissé meredek lenne.

Egyik ügyfelünknél kb 2 hónapja van az, h a két szervere között nem tudunk ssh-zni. Miközben a két szerverre bárhonnan, a két szerver is bárhová. UPC kavart valamit az egyik oldalon, és azóta nem mennek. Fix ip, üzleti előfizu. Üffél meg szomorú, én meg lesz@rom, mert dugja be a szervert hosting szolgáltatóhoz, vagy vívja le az upc-vel most a baját.

Ilyen nekünk is volt egyszer, de Telekommal. Fizikailag kb. 300 méterre egymástól, 2 külön előfizetés között sehogy nem lehetett IP kapcsolatot létesíteni. Versmondólány nem is értette, hogy mit szeretnék bejelenteni hibára, szerinte ha böngészni tudok, akkor az internet szolgáltatás működik, szóval minden rendben van. Ajánlgatták a szuperszervizt, térítés ellenében, de inkább a szolgáltatóváltás lett a megoldás... :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

telekom egy sima 25-os port tiltast sem birt feloldani modemcsere utan. 2 hetig konyogortunk nekik, 15x felvettek a hibajegyet, mindig valaszoltak hogy beallitottak, de megse ment. aztan 15.-re meg valahogy sikerult nekik. (ceges elofiz, fixip, mail server van mogotte. tiszta mazli hogy volt egy backup mikros netkapcsolatuk is es kuldeni azon at tudtak addig)

mi minden alkalommal amikor mondtak hogy kesz, ujrainditottuk, de megse ment. 2 hetig hivogatta naponta az ugyvezeto oket mig vegul egyszercsak sikerult beallitaniuk. elozo modemmel ment, szerintem olyasmi lehetett hogy naluk a rendszer azt mutatta hogy nincs tiltva, ezert nem is tudtak allitani, de az uj modem konfigjaban meg tiltva volt.

Végigjátszottam, ahogy írtam is a topic nyitóban. Nem lehet bridge módba kapcsolni (abba van már, de nem azt mutatja ??). UPC által módosított fw. Ügyfélszolgálat s/nem hiszi el/nem érdekli/, hogy nem megy, mert náluk működik. De ki nem jönnek, hogy megnézzék, mert a technikus úgysem tud segíteni rajta. Hívjak informatikust :(.
Belefáradtam ebbe, de rohadtul. Ki fogom kerülni ezt a problémát, húzok egy tunnelt vagy akármi, de nem tudok rá több energiát fordítani :(.

Szívesen megnézek bármit, de nem sok értelme lenne. A kérdést azért tettem fel, mert nyilvánvalóan helyi jelenséggel állsz szemben. Szombathely bizonyára más hálózati szegmensen van, mint a Budapest VII. kerület. Tehát nem lehet a hibát úgy diagnoszizálni, mint amikor átkurjantok a szomszédnak.

Üzleti előfizetésnél üzemeltethetsz szervert, ami eddig ment, most nem megy.
Nem kell eljátszani, hogy ki az okos/nem okos, hanem kérni kell egy modem cserét!
Mivel <=500Mb/s sebességű a kapcsolat, jó választás lehet az alant ajánlott Ubee EVW3226. Ilyet biztosan adnak. De akár a Cisco EPC3212 (bridge) is jó lehet, ha tudsz szerezni.

( arpi_esp v | 2018. 06. 25., h – 18:11 )

amugy szerintem rament az upc a securityre (talan a vpnfilter virus miatt?) mostanaban. kb 1 hete egy nap alatt vagy 5 fw verziot frissitettek a tecnicolor routeremen, egesz nap ujraindulgatott es mindig mas fw verzio latszott. kozbe 2x elfelejtette a beallitasokat is (az tunt fel). valami .21-rol felment .46-ig a fw verzio sok lepcsoben.

csutortokon meg elmult a 3 eve meglevo fix ip-m (dhcp-n forceoltam egy cimet). raadasul most olyan, hogy csak azt az ip-t engedi ki, amit az o dhcp szerveruk ad es csak addig. ha utana ugyanazt az ip-t beallitom staticban mar nem megy, mert amikor a dhcp szervert lelovom az elengedi a cimet. regen ilyen nem volt. (bridge modban hasznalom, linux fw)

( sfeher v | 2018. 06. 26., k – 11:55 )

Friss információk. Megint beszéltem a UPC ügyfélszolgálattal. Ezúttal egy hozzáértőt sikerült kifognom, akinek volt nemrég egy pontosan olyan esete, mint nekem(!). A megoldás az volt, hogy gw módba rakták a modemet és akkor működött az említett két port portforwarddal.
Modem cserére nincs lehetőség, mert ez az egy típus van nekik, ami az 500Mb-os kapcsolatot elviszi.

Ezt a "sajátmárkás" Connect Box nevű izét nem lehet kérni? Most ugrott be, hogy amikor nálam váltottak erre (előtte Technicolor volt), akkor szintén nem ment a bridge mode. Mondjuk itt egyértelmű volt, mert az opció sem létezett a GUI-n. Viszont az üfsz. egyből értette is a problémát, és küldtek új fw.-t. Érdekes módon ebben router és fw mode _is_ van.

Szintén 500M amúgy, de lakossági. A Connect Box egyébként csak modem/router, TV-s dolgokat nem kezel, ahhoz külön STB lenne (vagy CI kártya a TV-hez, ez választható), szóval technikailag nem köthető lakossági csomaghoz, aztán persze ettől még lehet hogy "nem engedi a gép", hiába kéred.

Fél éve váltottam 240Mb/s-ra. Egészen 500Mb/s-ig nincs a fenti problémám a kb. 9 éves Cisco EPC3212 modemmel. Nem lehet bridge módba kapcsolni (mert csak azt tudja :)), és nem jelent gondot a wifi. :-D
Szerencsésnek érzem magam, mert ezt a cserét 60Mb/s váltáskor kértem. Akkor 5000Ft volt az extra modem díja, meg 3 éve 1500Ft egy új, bikább kínai tápegység.

Sokáig én is ragaszkodtam hozzá, tudván hogy milyen retek d-link és egyéb szirszarokat adtak, amelyek aztán a legváltozatosabb hibákat produkálták, állandóan jöttek a szakik csereberélni. Aztán végül megadtam magam, amikor kiderült, hogy valami miatt zavartatott pár csatorna a sáv közepén (kabelhiba), és a 8 csatornás Cisco-ban hiba esetere már nincs tartalék. Egy sagemcom-ot hoztak (3686ac), ami már asszem 12 csatornás, az is megbízható, hibátlanul működik és nem bántam meg a cserét.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Jó ezt tudni! De mégjobb, ha megnézed a modem státusz oldalát!
Néhány éve a UPC csak komoly felkészültségel rendelkező alvállalkozókat alkalmaz. Ráadásul az egyes végpontokat folyamatosan és részletesen monitorozza a rendszer. Egyszer futottam össze egy profi - gondolom sokadik level - ügyfélszolgálatossal, aki egyszerre több javítást és bevizsgálást írt elő a vonalamra. A hiba nem volt egyszerű: A gateway RTT "romlani kezd", és a szokásos 6-8ms helyett elég stabilan eléri az 1000ms-t is. A vonal a központi mérés szerint hosszabb időre "bezajosodik". Mindez a csatorna jel/zaj viszonyban nem látható, a vételi jelszint az előírt +/-15dBmV sáv közepén tartózkodik alacsony szórással.
Bonyolult ez a rendszer! Időközben a következő javítások és módosítások történtek:
- egy kötés javítása
- két hálózati szegmens szétválasztása (az utcai berendezéseknél)
- ELMŰ betáp "rendes bekötése" (Ezt meglőzően egyes hibáknál minden egyes emeleten vissza kellett kapcsolni a biztosítékot. :))
- eszközcsere (az utcán)
- szilánkosra sült a modem tápegysége, cseréltem

Ennek ellenére a fenti hiba nagyon ritkán (mondjuk fél- háromnegyed évente), de még előfordul. Ha gyakrabban, akkor az eleinte hatásos modem újraindítás sem segít. Mindez független az évszaktól, hőmérséklettől, páratartalomtól, stb.
Egyszer-kétszer előfordult hasonló hiba. Az RTT folyamatosan növekedett, majd gyakorlatilag megszűnt a kapcsolat. Cigizés közben a szomszéd telefonján folyamatosan monitoroztuk. Már medig neki olyan modemje van, hogy a telón a speedtest.net 890Mb/s sebességet mutat. Persze csak akkor, ha nincs hiba. A sebesség fokozatos csökkenését ugyanúgy láttuk. A megoldás újabb eszköz cseréje - a modemek maradtak. Azóta van ez a "tényleg ritkán előfordulás". Valószínűleg egy harmadik helyen is ki kellene cserélni valamit. ;)

A modemcsere igazából áthidaló megoldás volt nálam, az időszakos kábelzajosodás okozta rendszeres hálózati hibák miatt kellett a megfelelő tartalék, és ez a készülék már korszerűbb a cisconál. Érdekes volt a jelenség, mert hónapokig nem volt hiba, de aztán a nyári nagy meleg, vagy a téli nagy hideg csak elő-előhozta - ilyenkor értelemszerűen az ip-tv is elcrashelt (egyébként a hiba mindig szépen látszott a modem admin-felületén, a különböző csatornák jel/zaj-viszonyán). Aztán, amikor már más ötlet nem lévén a 60m-es gerinckábelt akarták újrahúzni, kiderült, hogy a padláson, az elosztótól 2m-re egy lakossági toldást eszközölt az alvállalkozó aki anno kötötte, ez a tekerős F-csati/toldó-kombó okozta az egész, évekig tartó bizonytalankodást. De legalább a teljes CTV-alhálózat rendbe van téve nálam, jók a végzárós aljzatok, krimpeltek a csatik, be van szintezve az erősítő, stb.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Nekünk is ilyen modemünk van már 2-3 éve és úgy emlékszem itt is trükközni kellett vele. GW módban van , de a DHCP szervert kikapcsoltam és a kapcsolt mikrotik router a belső DHCP szerver. Az egyetlen trükk, hogy a Mikrotik-nak a default GW-je a CGNV4-EU, ami ugyanabban a /24-es címtartományban van.

A VPN tiltással (L2TP/ipsec) én is találkoztam, de általában 1-2 hét alatt elmúlt. Addig használtam pptp-t. Ráadásul a FIX-ip is kb évente változik. Pont most lett új ezen a héten. Emiatt vettünk egy külső, VPN alapú FIX IP-t mástól. Ezzel legalább kikerültük az IP váltásból és a véletlen port tiltásokból eredő problémákat.

( zolti v | 2020. 11. 05., cs – 21:42 )

Mi lett az ügy vége ?
Nekem egy Ubee EVW3226EU routerem van bridge módban, az ügyfélszolgálat szerint semmilyen korlátozás sincs. A 80-as port nem megy át a 443-as az ok.