Kedves fórum!
Szeretném kívülről SSH-n keresztül elérni néhány belső eszközömet. Ehhez beállítotam egy dinamikusan frissülő domaint. A router beállításaiban a létrehoztam port forwarding szabályokat (kettőt, de mindkét eszköz esetében azonos tünetek vannak, úgyhogy csak az egyiket fogom részletezni).
Custom service name: winloo
Service: Other
External host: *
Internal host: 192.168.1.68
Protocol: TCP - UDP
External Port: 5951
Internal Port: 22
(ha a service-nek SSH-t állítok be, akkor kiszürkítve beállítja a 22-es portot külsőnek, amit nem szeretnék - de nem hiszem, hogy ez bármi mást csinálna ezen kívül)
Mindenek előtt: az SSH működik, ha a lokális IP-címre csatlakozom a kliensről, sőt, még lokális (mdns) domainnel is. Viszont ha a külső domainen keresztül megyek, akkor nem. Debug log a klienstől: Paste.ee - ssh -p 5951 -vvv tamas@azendomain.em
A láthatóan csatlakozik, elindul a handshake, majd `debug1: expecting SSH2_MSG_KEX_ECDH_REPLY` soron elég sokat várakozik, de végül nem érkezik meg a várt válasz. Az a gyanúm, hogy a router egyszerűen eldobja ezt a paketet. Megpróbáltam még a telnetet a domainen keresztül, és feljön az SSH banner: Paste.ee - telnet azendomain.em 5951
Próbáltam mindenféle alacsony MTU beállítást a kliensen és a szerveren is, de nem segít. Továbbá, amit még találtam erre a hibára, hogy megmondani az SSH-nak, hogy pontosan milyen KEX algoritmust használjon, de szintén nem segített. A router firewallját is kikapcsoltam teljesen, de ez sem segített.
Amit még szívesen kipróbálnék, hogy bridge módba állítom a routert és utána rakom a sajátomat. Van ilyen opció ebben a routerben, de nem csinál semmit, illetve ha újraindítom, akkor vissza is állítja magát. Más topicban láttam, hogy a 1414-en kell kérni a bridge módot más routereknél, ez itt is igaz? (nincs iptv-m). Előre is köszönöm a segítséget.
Hozzászólások
Hali!
Ha belülről próbálsz csatlakozni a doménnel, akkor talán a NAT Loopback hiánya okozhat ilyen problémát.
A bridged mód az valóban nem azt csinálja itt, amire gondolsz. Az internetnél a PPPoE passtrough-t kapcsold be, majd csatlakozz a saját routerrel. Már enged a Telekom két PPPoE session-t, így nem kell lelőni a Sagem-en (ha új fajta IPTV-d van, nem is szabad).
TheAdam
> Ha belülről próbálsz csatlakozni a doménnel, akkor talán a NAT Loopback hiánya okozhat ilyen problémát.
Köszi, ez egy jó tipp. Valóban belülről próbáltam csatlakozni. Összelövöm újra úgy és megnézem mobilnetről.
> A bridged mód az valóban nem azt csinálja itt, amire gondolsz. Az internetnél a PPPoE passtrough-t kapcsold be
Igen, a PPPoE passthrough működik (így van most), de sajnos a routerem nem tudja tartani a lépést a gigabittel (kb. 2/3-ra leesik a sebesség). Igazából azt szeretném, hogy a Sagemcom csak modemként funkcionáljon. Nekem úgy tűnik, hogy a bridge mód beállítást teljesen figyelmen kívül hagyja és továbbra is natol.
Még nem tudtam kísérletezni, de jobban belegondolva nem a NAT loopback lesz a baj. Ugyanis eljut a login folyamatban egész sokáig, csak elmarad egy csomag a válaszból és timeoutol.
en szerver oldalon csinalnek TCP dumpot, mert nagyon ugy tunik, hogy a reply eltunik az eterben (tuzfal/router). Olyan nem szokott lenni, hogy a router csak ugy eldob egy package-et, annak kell, hogy oka legyen (tuzfal, roussz routing, stb.).
Kozben szetneztem, es egy ilyenbe botlottam bele, hatha segit :)
https://serverfault.com/questions/210408/cannot-ssh-debug1-expecting-ss…
Path MTU hibaba annyira regen futottam bele, hogy eszembe sem jutott mint lehetoseg
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085