Ratkaistu Mobiilimodeemi->Reititin->Serveri SSH yhteysongelma

[nightlight]

Pakko kirjoittaa ja kysyä viisammilta neuvoa, kun oma pää alkaa olemaan räjähtämispisteessä. Voisin rantata tuhannen riviä miten ku**** pas*** Telia palveluineen on, mutta jätetään se toiseen kertaan. Toinen ongelma on myös se että en vain ymmärrä miten nämä verkkoasiat voi olla näin katastrofaalisia käyttäjäkokemukseltaan edelleen 2022, tai sitten vain olen vähän tyhmä. No oli miten oli niin itse ongelmaan.

Internet yhteys Telia 5g (joka toimii 4g:nä) ja tähän tilattu heidän 'Yhteyspiste' riistopalvelu jolla pitäisi saada oma julkinen IP. Modeemina toimii ZTE MC801A ja se on asetettu 'OpenGate' tilaan kuten ohjeistettu Telian sivuilla. Olkoon julkinen IP 193.3.3.3 ja sisäverkon ip 192.168.1.1. Koska haluaisin pitää 'IOT' laitteet eristettynä omassa verkossaan on minulla sitten liitetty kaksi Asuksen reitintä ZTE lan porteista Asuksien WANeihin. Olen myös 'ohittanut' DHCPn näille Asuksille asettamalla staattisen IPn 192.168.1.2 ja 192.168.1.3. Asuksissa pyörii MerlinWRT. Serveri (Debian 11) on kiinni toisessa näistä Asuksista ja olkoon silloin WAN 192.168.1.2 ja LAN 192.168.2.1 serverille määrättäy myös staattinen ip 192.168.2.2 eli setuppi on kutakuinkin seuraavanlainen:
INTERNET (193.3.3.3)->ZTE(192.168.1.1)->(192.168.1.2)ASUS(192.168.2.1)->SERVERI(192.168.2.2)
Serverillä SSH portissa 666 ja ZTE olen asettanut port forwardin 192.168.1.2:666 ja toisaalta myös Asuksessa port forwardi 192.168.2.2:666. Myös liikenne hyväksytty serverin palomuurista portissa 666.

SSH yhteys pelittää mainiosta LANista käsin mutta ulkoa ei pääse sitten kirveelläkään sisään vaan connection refusea tulee. Yritän myös pingata julkista osotettani ja timeout on tulos. Joten omalla vähäisellä ymmärryksellä päättelisin että reitti tyssää jo ZTE/Telian päässä heti alkuunsa. Teliasta ei kuitenkaan apua saa kuin miljoonia maksavasta Helpistä (joka sekin down lakon takia). Haluaisinkin tietää miten voisin debugata tätä vian lähdettä? Voiko reitittimistä vielä joku palomuuri blokata tämän yhteyden? Tosin täysin sama setup on toiminut vanhassa kämpässä jossa oli DNAn kaapeli.

EDIT: Muokattu IP osoitteet loogisiksi

 

[telcoM]

Pingin toimimattomuus tarkoittaa että joku matkan varrella estää ping-pakettien (ICMP "ping") tai ping-vastauspakettien (ICMP "pong") kulun. Näin tapahtuu nykymaailmassa aika usein, ja siksi pingillä ei ongelmatilanteessa usein teekään paljon mitään.

Sen sijaan kannattaa kokeilla TCP-traceroutea suoraan siihen porttiin jossa palvelun pitäisi olla tavoitettavissa, eli sinun tapauksessasi ulkomaailmasta osoitteeseen 193.3.3.3 ja TCP-porttiin 666.

Maailmalta löytyy webbisivuja joilta voi tehdä TCP-tracerouten, esim.

TCP Traceroute by WebSitePulse

Use this TCP Traceroute to check the route of test packets take from one web destination to another by using TCP packets.

www.websitepulse.com

tai

TCP Traceroute - LetMeCheck.it

Online TCP Traceroute tool to check the path to a server, device or other IP connected device or service.

www.letmecheck.it

Testattavan nettiliittymän ulkopuoliselta Linux-koneella voi sanoa:

traceroute -T -p 666 193.3.3.3

Tuosta pitäisi syntyä tuloste jossa on niin monta riviä kuin matkalla testikoneestasi reitittimeesi on välipysäkkejä. Jos viimeisellä rivillä ei näy modeemisi julkista osoitetta 193.3.3.3 ja järkevän oloisia pakettien kulkuaikoja, silloin viimeinen rivi josta kulkuajat näkyvät kertoo mihin asti varmuudella päästiin.

Jos jonkin hypyn jälkeen tulee kulkuajan paikalle pelkkiä tähtiä listauksen loppuun asti, silloin viimeisen pisteen josta kulkuajat saatiin jälkeen tulee yhteysväli joka syystä tai toisesta tiputtaa TCP paketit lattialle.

Yksittäinen tähtirivi tai pari listauksen välissä ei välttämättä haittaa, jos sen jälkeen tulee rivi josta kulkuajat on saatu.

 

[mikajh]

Kun teet sisäverkosta palomuurin testin millä tahansa web-browserilla/testerillä (esim. grc.com ShieldsUp custom port), niin sen pitäisi näyttää tcp portti 666 ok-tapauksessa avoimeksi, tai suljetuksi jos kukaan ei kuuntele ja nuo port forwardit muuten toimivat.

nmap voisi olla tässä parempi työkalu kuin traceroute, mutta vaatii toisen internet-yhteyden testaukseen

EDIT: Koska opengate on uusi käyttöönotettu palvelu, niin kaipa tarkistit että ZTE ja ip4.me näyttää samaa julkista IPv4-osoitetta eikä CGNAT:in vastaavaa
EDIT2: Ehkä kannattaa aluksi ZTE:n päässä vaihtaa portti vaikka 1666:een siltä varalta, että 1-1024 eivät toimi Telian puolesta

 

[minapamina]

Toinen vaihtoehto telnetillä tuohon porttiin 666 ulkoverkosta, sekin osaa kertoa vähän enemmän kuni pelkkä pingi. Kuten sanoit, johonkin vaikuttaisi paketit pysähtyvän, jos et muuta keksi, voit aina debugata wiresharkilla, jos ei reitittimet osaa sniffata liikennettä tai ottaa packet capturea. Esim. jos annat läppärille tuon julkiosoitteen, ja siltaat mobiilibitin siihen, pitäisi pakettien osua läppäriin jos 4g modeemi on ihan aidosti siltaavana.

 

[Prefect]

Kuvaus miten olet toteuttanut yhteyden palvelimelle vaikutta ihan oikealta ja sen pitäisi toimia. Kaksois nat ei ole paras ratkaisu mutta sen ei pitäisi aiheuttaa ongelmia ja on ainakin helppo asentaa.

Voisit koittaa tilapäisesti asentaa palvelimen suoraan zte:n perään niin saisi rajattua ongelmaa.

Sanoit että otit dhcp:n pois asuksen reitittimiltä ja astit niille staattiset osoitteet. Jos laitoit kiinteät osoitteet suoraan asuksille niin zte ei välttämättä suostu reitittämään/porttiohjaamaan itselleen tuntemattomiin osoitteisiin. Parempi tapa olisi määritellä zte:n dhcplle kiinteät osoitteet noille asuksen reitittimille. Eli osoitteet tulisivat dhcp:ltä mutta annetut osoitteet olisivat aina ne samat.

Minulla on jokin muistikuva että portti 666 taisi olla tunnetusti jossain haittaohjelmakäytössä joten on mahdollista että varmuustoimena tuon portin käyttö olisi estetty operaattorin palomuurin toimesta.

Osassa reitittimistä pelkkä satunnaisen portin porttiohjaus ei välttämättä riitä vaan reitittimelle voi joutua määrittelemään myös avoimen palomuurisäännön että se päästää liikenteen porttiin läpi. Monissa reitittimissä tuo hoituu helposti kun valitaan minkä tyyppinen palvelu halutaan sallia (ssh / sshd) jolloin reititin osaa hoitaa palomuurin ja porttiohjuaksen samalla kertaa. Palomuuri pitäisi siis avata sekä zte ja asuksen reitittimistä.

 

[hsalonen]

Pakko kirjoittaa ja kysyä viisammilta neuvoa, kun oma pää alkaa olemaan räjähtämispisteessä. Voisin rantata tuhannen riviä miten ku**** pas*** Telia palveluineen on, mutta jätetään se toiseen kertaan. Toinen ongelma on myös se että en vain ymmärrä miten nämä verkkoasiat voi olla näin katastrofaalisia käyttäjäkokemukseltaan edelleen 2022, tai sitten vain olen vähän tyhmä. No oli miten oli niin itse ongelmaan.

Internet yhteys Telia 5g (joka toimii 4g:nä) ja tähän tilattu heidän 'Yhteyspiste' riistopalvelu jolla pitäisi saada oma julkinen IP. Modeemina toimii ZTE MC801A ja se on asetettu 'OpenGate' tilaan kuten ohjeistettu Telian sivuilla. Olkoon julkinen IP 193.3.3.3 ja sisäverkon ip 192.168.1.1. Koska haluaisin pitää 'IOT' laitteet eristettynä omassa verkossaan on minulla sitten liitetty kaksi Asuksen reitintä ZTE lan porteista Asuksien WANeihin. Olen myös 'ohittanut' DHCPn näille Asuksille asettamalla staattisen IPn 192.168.1.2 ja 192.168.1.3. Asuksissa pyörii MerlinWRT. Serveri (Debian 11) on kiinni toisessa näistä Asuksista ja olkoon silloin WAN 192.168.1.2 ja LAN 192.168.2.1 serverille määrättäy myös staattinen ip 192.168.2.2 eli setuppi on kutakuinkin seuraavanlainen:
INTERNET (193.3.3.3)->ZTE(192.168.1.1)->(192.168.1.2)ASUS(192.168.2.1)->SERVERI(192.168.2.2)
Serverillä SSH portissa 666 ja ZTE olen asettanut port forwardin 192.168.1.2:666 ja toisaalta myös Asuksessa port forwardi 192.168.2.2:666. Myös liikenne hyväksytty serverin palomuurista portissa 666.

SSH yhteys pelittää mainiosta LANista käsin mutta ulkoa ei pääse sitten kirveelläkään sisään vaan connection refusea tulee. Yritän myös pingata julkista osotettani ja timeout on tulos. Joten omalla vähäisellä ymmärryksellä päättelisin että reitti tyssää jo ZTE/Telian päässä heti alkuunsa. Teliasta ei kuitenkaan apua saa kuin miljoonia maksavasta Helpistä (joka sekin down lakon takia). Haluaisinkin tietää miten voisin debugata tätä vian lähdettä? Voiko reitittimistä vielä joku palomuuri blokata tämän yhteyden? Tosin täysin sama setup on toiminut vanhassa kämpässä jossa oli DNAn kaapeli.

EDIT: Muokattu IP osoitteet loogisiksi

Ymmärsinkö oikein?

INTERNET (portti 22)->ZTE(portti 22->666)->ASUS(portti 22 -> 666)->SERVERI(portti 666)

Sinulla näyttäisi olevan kaksi kertaa porttimäppäys 666 ja tuo tulevan Asukselle jo valmiiksi 666-porttiin. Onko siellä toimivat reititys tälle portille vain tuo porttimappaus 22->666 ?

 

[minapamina]

Tohon vielä lisäyksenä, muutenkin nuo kannattaa olla any -> 666, sillä sourceportti ei välttämättä aina ole tuo 22.

 

[nightlight]

Kiitos kaikille vastauksista/avusta. Tietysti olisi taas pitänyt ottaa kierroksia alas ja tehdä kuten Prefect käski, eli koittaa tilapäisesti asentaa palvelimen suoraan zte:n perään niin saisi rajattua ongelmaa...

Tämä johti uuteen kaninkoloon sillä wpa_supplicant alkoi kettuilemaan, eikä suostunut pystyttämään yhteyttä tuohon ZTE:hen syystä jota en vieläkään tiedä (sain yhteyden toimimaan resetoimalla koko boksin, ja määrittelemällä sen tismalleen samaksi kuin ennen ressua).

Tästä päästäänkin asian ytimeen, eli en maininnut ilmeisesti olennaista seikkaa siitä että serverini oli wifin varassa (käytännön syistä). Roikan nokasta homma toimii kuin junan vessa, mutta näemmä wifi sekoittaa pakkaa jotenkin mystisesti eikä sitä kautta ole asiaa ottaa yhteyttä. Jos joku osaa valottaa mikä tähän on syynä niin ilomielin oppisin tämänkin (mitään ip konfliktia tms ei ole).
Kaikenkaikkiaan tuo ZTE purkki on täyttä pas*** eikä sitä voi puukottaa käytännössä mitenkään. Varmaan olisi parempi vain sillata se ja hommata joku uusi purkki, johon sitten openwrt tai pfsense. Pääsisi ainakin taas sekoilemaan lisää.

 

[nightlight]

Ymmärsinkö oikein?

INTERNET (portti 22)->ZTE(portti 22->666)->ASUS(portti 22 -> 666)->SERVERI(portti 666)

Sinulla näyttäisi olevan kaksi kertaa porttimäppäys 666 ja tuo tulevan Asukselle jo valmiiksi 666-porttiin. Onko siellä toimivat reititys tälle portille vain tuo porttimappaus 22->666 ?

SSH portti on muutettu serverillä defaultista (22) arvoon 666 ja reitittimissä on vain tuon portin ohjaus oikeisiin IP osotteisiin. Eli ssh -p 666 user@iposoite on komento jolla otan ylipäätään yhteyttä.