Plex Media Server toimii virheettömästi lähiverkossa, mutta etäyhteys toimii heikommin. Netin mukaan ongelma voisi johtua Double NATista. Olen itse suht käsi näiden kanssa, joten osaisiko joku neuvoa, mitä ja miten pitäisi säätää, jotta double natista pääsisi eroon? Minulla on siis valokuituyhteys, joka tulee Technicolouriin (wifi pois päältä), josta RJ45 Asuksen RT-AX86U:hun, jossa 2.4 ja 5GHz wifit sekä uusin firmware päivitettynä. Technicolour antaa lähiverkon ip:t ja Asu on Access Pointina. Alla kuvia, joiden pitäisi selventää.
E: Plexin portti on ohjattu Technicolorista oikein, mutta tämä ei auta.
Tuossa Technicolour selvästi tekee yhden NATtauksen, ja Asus on pelkkänä access pointtina, mikä on tässä tilanteessa aivan oikein. Jos tuossa tapauksessa on toinen NATtauskerros, se on sitten jossain valokuidun puolella.
Eli komppaan Miksaa: jotta saadaan selville onko kysymys Double NATista vai ei, pitäisi saada selville onko Technicolourin WAN-puolelle DHCP:llä saatu IP-osoite aito julkinen IP vai kuuluuko se johonkin privaattiverkkojen IP-osoitesarjaan, mikä kertoisi että jokin valokuidun toisessa päässä tekee jo yhden NATtauksen.
Tuon WAN Settings-kuvan mukaan tuo Technicolour ei paljoa DHCP-asetuksistaan kerro, ainakaan tuolla sivulla. Löytyisiköhän Diagnostics-sivulta mitään hyödyllistä?
Tuossa Technicolour selvästi tekee yhden NATtauksen, ja Asus on pelkkänä access pointtina, mikä on tässä tilanteessa aivan oikein. Jos tuossa tapauksessa on toinen NATtauskerros, se on sitten jossain valokuidun puolella.
Eli komppaan Miksaa: jotta saadaan selville onko kysymys Double NATista vai ei, pitäisi saada selville onko Technicolourin WAN-puolelle DHCP:llä saatu IP-osoite aito julkinen IP vai kuuluuko se johonkin privaattiverkkojen IP-osoitesarjaan, mikä kertoisi että jokin valokuidun toisessa päässä tekee jo yhden NATtauksen.
Tuon WAN Settings-kuvan mukaan tuo Technicolour ei paljoa DHCP-asetuksistaan kerro, ainakaan tuolla sivulla. Löytyisiköhän Diagnostics-sivulta mitään hyödyllistä?
Julkinen ip-osoite on kyllä eli ei ole tuplanattia. Laita technicolourin firewall asetuksista ja siitä porttiohjauksesta kuva. Mistä testaat sitä etäyhteyttä?
Julkinen ip-osoite on kyllä eli ei ole tuplanattia. Laita technicolourin firewall asetuksista ja siitä porttiohjauksesta kuva. Mistä testaat sitä etäyhteyttä?
Nyt nassin kiinteä sisäverkon ip on asetettu sekä Technicolorista mac-osoitteen perusteella että nassista itsestään. Onko merkitystä? Pitäisikö tuo jättää vain Technicolorin hommaksi?
Äkkiseltään näyttäisi asetukset oikeilta olettaen että porttiohjaukset raottaa palomuuria automaattisesti ja nuo kuvassa olevat palomuurisäännöt on ainoat mitä pystyy muuttamaan. Passthrough kannattaa jättää pois. Todennäköisesti se rikkoi nassin/plexin yhteydet julkiverkkoon päin. Vastaatko vielä tuohon aiempaan eli mistä testaat etäyhteyttä? Technicolourin/wlan ap:n perässä olevalta koneelta julkiverkon osoitteella vai jollain mobiililaitteella mikä ei käytä samaa yhteyttä? Ensimmäinen ei välttämättä toimikaan jos reititin ei tee ns. hairpin nattia.
Äkkiseltään näyttäisi asetukset oikeilta. Passthrough kannattaa jättää pois. Todennäköisesti se rikkoi nassin/pleskin yhteydet julkiverkkoon päin. Vastaatko vielä tuohon aiempaan eli mistä testaat etäyhteyttä? Techicolourin/wlan ap:n perässä olevalta koneelta julkiverkon osoitteella vai jollain mobiililaitteella mikä ei käytä samaa yhteyttä? Ensimmäinen ei välttämättä toimikaan jos reititin ei tee ns. hairpin nattia.
Tuon IP Passthrough'n laitoin tuossa parikymmentä minuuttia sitten eli se ei ole aiheuttanut ongelmaa alunperin.
Testaan luurilla yhteyttä etänä (mobiiliverkko). Välillä oli niinkin, että puhelimella toimi mobiiliverkon kautta hetken mutta samaan aikaan tabletilla ei toiminut mökin wifi-yhteyden kautta.
Lähiverkossa toimii virheettömästi kaikilla laitteilla tällä hetkellä.
Tuosta on hyvinkin apua. Oleellinen kohta on WAN IP Address: koska osoite alkaa 80:lla, se ei kuulu mihinkään tunnettujen privaatti-IP:iden sarjaan joten nyt näyttäisi että kysymyksessä ei taida olla Double NAT vaan jokin muu ongelma.
Valokuituoperaattori saattaa esimerkiksi torpata yhteyden avaukset ulkoa sisäänpäin koska heidän perus-kuluttajaliittymäsopimuksensa ei salli julkisten serverien pitoa.
Tai sitten ongelmana on se, että kotiverkon ulkopuolelta yhteyttä ottavan laitteen pitää jotenkin saada tietoonsa se, että yhteys pitää ottaa juuri tuohon WAN IP Address-osoitteeseen ja porttiohjauksessa määritettyyn porttiin. Kotiverkon sisällä oikea osoite löytyy esim. MDNS-kyselyllä tai muulla broadcast-tekniikalla (eli joko Plex itse ilmoittelee itsestään kotiverkkoon tai sitten se vastaa kun joku laite verkossa kysyy "hei kaikki, onko täällä jossain Plex-palvelinta?").
Kotiverkon ulkopuolella tällaiset systeemit eivät toimi koska kaikkien maailman laitteiden osoitekyselyistä ja -ilmoituksista tulisi valtavasti turhaa liikennettä, vaan yhteyden ottajan täytyy joko itse tietää oikea IP-osoite tai saada se selville jostain julkisesta DNS-palvelusta. Jälkimmäinen edellyttää että olet rekisteröinyt WAN IP:lle jonkin nimen: helpoimmin tämä onnistuu erilaisia Dynamic DNS-palveluita käyttämällä, esim. suomalaisille ilmainen dy.fi jota muistaakseni Synology osaa käyttää suoraan:
dy.fi - lyhyimmät ilmaiset ja mainoksettomat dynaamiset domain-nimet kotisivuillesi tai palvelimellesi
www.dy.fi
Se porttiohjaus pitää tietysti olla muotoa "mikä tahansa IP-osoite + valittu portti => NASin sisäverkon osoite + Plexin käyttämä portti". Jos porttiohjauksen lähtöpään IP-osoitteena on esim. WAN IP Address, se tarkoittaisi että vain Technicolour-reititin itse saa ottaa yhteyttä porttiohjauksen läpi.
Lisäksi jos tuossa Technicolourissa on palomuuritoimintoja, se että porttiohjaus on olemassa ei välttämättä tarkoita että liikenne ulkopuolelta porttiohjauksen läpi olisi automaattisesti sallittua, vaan ulkoa saapuva yhteys porttiohjauksessa määriteltyyn porttiin saattaa olla tarpeen sallia myös palomuuriasetusten puolella.
Tuosta on hyvinkin apua. Oleellinen kohta on WAN IP Address: koska osoite alkaa 80:lla, se ei kuulu mihinkään tunnettujen privaatti-IP:iden sarjaan joten nyt näyttäisi että kysymyksessä ei taida olla Double NAT vaan jokin muu ongelma.
Valokuituoperaattori saattaa esimerkiksi torpata yhteyden avaukset ulkoa sisäänpäin koska heidän perus-kuluttajaliittymäsopimuksensa ei salli julkisten serverien pitoa.
Tai sitten ongelmana on se, että kotiverkon ulkopuolelta yhteyttä ottavan laitteen pitää jotenkin saada tietoonsa se, että yhteys pitää ottaa juuri tuohon WAN IP Address-osoitteeseen ja porttiohjauksessa määritettyyn porttiin. Kotiverkon sisällä oikea osoite löytyy esim. MDNS-kyselyllä tai muulla broadcast-tekniikalla (eli joko Plex itse ilmoittelee itsestään kotiverkkoon tai sitten se vastaa kun joku laite verkossa kysyy "hei kaikki, onko täällä jossain Plex-palvelinta?").
Kotiverkon ulkopuolella tällaiset systeemit eivät toimi koska kaikkien maailman laitteiden osoitekyselyistä ja -ilmoituksista tulisi valtavasti turhaa liikennettä, vaan yhteyden ottajan täytyy joko itse tietää oikea IP-osoite tai saada se selville jostain julkisesta DNS-palvelusta. Jälkimmäinen edellyttää että olet rekisteröinyt WAN IP:lle jonkin nimen: helpoimmin tämä onnistuu erilaisia Dynamic DNS-palveluita käyttämällä, esim. suomalaisille ilmainen dy.fi jota muistaakseni Synology osaa käyttää suoraan:
dy.fi - lyhyimmät ilmaiset ja mainoksettomat dynaamiset domain-nimet kotisivuillesi tai palvelimellesi
www.dy.fi
Se porttiohjaus pitää tietysti olla muotoa "mikä tahansa IP-osoite + valittu portti => NASin sisäverkon osoite + Plexin käyttämä portti". Jos porttiohjauksen lähtöpään IP-osoitteena on esim. WAN IP Address, se tarkoittaisi että vain Technicolour-reititin itse saa ottaa yhteyttä porttiohjauksen läpi.
Lisäksi jos tuossa Technicolourissa on palomuuritoimintoja, se että porttiohjaus on olemassa ei välttämättä tarkoita että liikenne ulkopuolelta porttiohjauksen läpi olisi automaattisesti sallittua, vaan ulkoa saapuva yhteys porttiohjauksessa määriteltyyn porttiin saattaa olla tarpeen sallia myös palomuuriasetusten puolella.
DDNS on tällä hetkellä säädetty Technicoloriin (ks. alla) sekä nassiin (ks. aiemmat kuvat). Vastaavat DDNS-osoitteet (ddns.net sekä synologyn oma) on lisätty myös Plexin asetuksiin. Pitäisikö tuo DDNS ottaa Technicolorista pois? Tuota ohjausta käytetään vain Plexin Media Serverin takia - mitään muuta tarkoitusta sillä ei ole. Eli ts. esim. desktopiin minulla ei ole tarvetta ottaa noiden kautta yhteyttä.
E: Myös nimipalvelin on eri Technicolorissa (Telian oma, ei voi vaihtaa) ja nassissa (9.9.9.9). Onko tällä merkitystä?
Yksi asia, mitä mietin, on se, että voiko olla, että nas (tai technicolor tai nuo DDNS-sivustot) eivät päivitä ip:tä riittävän usein ja ohjaus ei näin toimi?
Tuo "WAN Blocking" Firewall-osiossa näyttäisi jonkin Googlella löytämäni Technicolor-reitittimen ohjekirjan mukaan estävän kaikki ulkomaailmasta sisään tulevat yhteydet, eli voisi kokeilla sen laittamista off-asentoon.
DDNS:n päivittymisnopeus on tuskin ongelmana, koska näyttäisi että ainakin NASsi taitaa itse valvoa että osoitteet ovat päivittyneet oikein. Se luultavasti ilmoittaisi virheestä jos osoite olisi väärin.
Eri nimipalvelimen käytöllä ei pitäisi olla merkitystä, paitsi jos jompikumpi käytetyistä palvelimista on rikki ja toinen ei.
Nykyisillä asetuksilla Port Range Forwardingin neljäs rivi näyttäisi tarkoittavan että jos ulkomaailmasta otetaan TCP-yhteys IP-osoitteeseen 80.X.X.X porttiin 12394, se välitetään edelleen NASsin sisäverkon IP-osoitteeseen porttiin 32400, mikä olisi ilmeisesti juuri se mitä haluat.
Mutta tuossa on sitten lisäksi Port Range Triggering-määritys joka näyttäisi tarkoittavan "jos jokin sisäverkon laite liikennöi TCP:llä ulkomaailmaan porttiin 32222, sille laitteelle avataan portinohjaus sisäänpäin portissa 32400". Tuo saattaa huonolla tuurilla mennä päällekkäin tuon Port Range Forwarding-määrityksen kanssa ja aiheuttaa jotain sotkua, eli tuo triggering-määritys kannattanee poistaa ellet erityisesti tarvitse sitä.
Tuo "WAN Blocking" Firewall-osiossa näyttäisi jonkin Googlella löytämäni Technicolor-reitittimen ohjekirjan mukaan estävän kaikki ulkomaailmasta sisään tulevat yhteydet, eli voisi kokeilla sen laittamista off-asentoon.
DDNS:n päivittymisnopeus on tuskin ongelmana, koska näyttäisi että ainakin NASsi taitaa itse valvoa että osoitteet ovat päivittyneet oikein. Se luultavasti ilmoittaisi virheestä jos osoite olisi väärin.
Eri nimipalvelimen käytöllä ei pitäisi olla merkitystä, paitsi jos jompikumpi käytetyistä palvelimista on rikki ja toinen ei.
Nykyisillä asetuksilla Port Range Forwardingin neljäs rivi näyttäisi tarkoittavan että jos ulkomaailmasta otetaan TCP-yhteys IP-osoitteeseen 80.X.X.X porttiin 12394, se välitetään edelleen NASsin sisäverkon IP-osoitteeseen porttiin 32400, mikä olisi ilmeisesti juuri se mitä haluat.
Mutta tuossa on sitten lisäksi Port Range Triggering-määritys joka näyttäisi tarkoittavan "jos jokin sisäverkon laite liikennöi TCP:llä ulkomaailmaan porttiin 32222, sille laitteelle avataan portinohjaus sisäänpäin portissa 32400". Tuo saattaa huonolla tuurilla mennä päällekkäin tuon Port Range Forwarding-määrityksen kanssa ja aiheuttaa jotain sotkua, eli tuo triggering-määritys kannattanee poistaa ellet erityisesti tarvitse sitä.
Operaattori on oletettavasti Telia, perustuen siihen kun Ensimmäiset kaksi numeroa julkisesta osoitteesta on 80? Telia ei käsittääkseni harrasta sisäänpäin tulevan liikenteen blockkausta paitsi tietyt portit, eli esim portti 25.
Ilmeisesti nyt on käsitelty ongelmaa serverin päässä, tuosta "heikommin" sanasta tulee mieleen että voisiko ongelma johtua asiakas päästä ? (eli osalla toimii, osalla ei)
Sori, en lukenut kaikkea tarkkaan, eli jos jotain UDP yhteyksiä, niin serveriltä oiken lähtenyt data ei pääse kaikille oikein perille.
DDNS palvelu mainittu, onko ongelma se että kun toimii, niin toimii jokapaikassa, mutta IPn vaihduttua ei toimi kaikkialle johonkin aikaan ? Eli varmistaa että onko ongelma asiakkaalla vielä vanha IP valimuistissa, verrata sen laitteen , ja sen käyttämän DNS palvelun ja varsinaisen DDNS palvelun IPtä ja laitteen todellista . Tarkistaa ne DNS palveluiden vanhenemisajat, vaikka yleensä DDSN palvaluissa on lyhyt.
Jotkin yhteydet (operaattorit) on estäneet jotain liikennettä palvelunestohyökkäyksen hengessä, ja miksei oma laitteistokin voisi sitä tehdä.
Onko VPN tunnelli vaihtoehto, niin ei tarvitsisi varsinaisen palvelimen olla suoraan julki netissä.
Ilmeisesti nyt on käsitelty ongelmaa serverin päässä, tuosta "heikommin" sanasta tulee mieleen että voisiko ongelma johtua asiakas päästä ? (eli osalla toimii, osalla ei)
Sori, en lukenut kaikkea tarkkaan, eli jos jotain UDP yhteyksiä, niin serveriltä oiken lähtenyt data ei pääse kaikille oikein perille.
DDNS palvelu mainittu, onko ongelma se että kun toimii, niin toimii jokapaikassa, mutta IPn vaihduttua ei toimi kaikkialle johonkin aikaan ? Eli varmistaa että onko ongelma asiakkaalla vielä vanha IP valimuistissa, verrata sen laitteen , ja sen käyttämän DNS palvelun ja varsinaisen DDNS palvelun IPtä ja laitteen todellista . Tarkistaa ne DNS palveluiden vanhenemisajat, vaikka yleensä DDSN palvaluissa on lyhyt.
Jotkin yhteydet (operaattorit) on estäneet jotain liikennettä palvelunestohyökkäyksen hengessä, ja miksei oma laitteistokin voisi sitä tehdä.
Onko VPN tunnelli vaihtoehto, niin ei tarvitsisi varsinaisen palvelimen olla suoraan julki netissä.
Ongelmaa on sekä kaverillani että minulla. Kotona lanissa Plex toimii hyvin. Ei kaveri varmaan osaa noita IP:itä verrata (vai pitäisikö minun tehdä se?). Ärsyttää, kun välillä toimii etänä kuin junan vessan ja sitten taas välillä pelkkää virheilmoa.
Miten tuo VPN-tunneli toimii/miten se tehdään? Olen valmis oikeastaan testailemaan mitä vain, kunhan nyt saisi toimimaan. Voisin kotoa copypasteta portforwardit, jos joku osaavampi katsoisi ovatko ne oikein.
Palataan alkujuurille. Olet kirjautunut plex.tv:hen, lisännyt sinne käyttäjät ja he ovat sen sähköpostin vahvistaneet?
Edit.
Tämän jälkeen he ovat kirjautuneet plex.tv:hen, mahdollisesti lisänneet sinne käytettävät laitteet, kirjautuneet niihin tunnuksillaan ja sen jälkeen ovat koittaneet kirjastoosi?
Ja plexin asetuksissa etäkäyttö kohdassa on vihreä oikeinmerkki, ja sen avaamalla löytyy teksti
-- Täysin käytettävissä verkkosi ulkopuolelta
Voit käyttää tätä palvelinta kirjautuneilla Plex-sovelluksilla tai selaimellasi osoitteessa Plex.
--
Plexiä ei käytetä selaimen kautta, vaan appilla (lanissa Windows, ShieldTV Pro ja Andoidin appi, josta chromecastillä toiseen telkkuun). Etänä kännykällä (android app) ja telkusta AndroidTV-appi.
Plexiä ei käytetä selaimen kautta, vaan appilla (lanissa Windows, ShieldTV Pro ja Andoidin appi, josta chromecastillä toiseen telkkuun). Etänä kännykällä (android app) ja telkusta AndroidTV-appi.
Kuten samip mainitsi, voi käyttää selaimella, itseasiassa android app oli ainakin jossain vaiheessa maksullinen, ilmaisella ei nähnyt kuin pienen pätkän kerrallaan.
Kuten samip mainitsi, voi käyttää selaimella, itseasiassa android app oli ainakin jossain vaiheessa maksullinen, ilmaisella ei nähnyt kuin pienen pätkän kerrallaan.
Palataan alkujuurille. Olet kirjautunut plex.tv:hen, lisännyt sinne käyttäjät ja he ovat sen sähköpostin vahvistaneet?
Edit.
Tämän jälkeen he ovat kirjautuneet plex.tv:hen, mahdollisesti lisänneet sinne käytettävät laitteet, kirjautuneet niihin tunnuksillaan ja sen jälkeen ovat koittaneet kirjastoosi?
Ja plexin asetuksissa etäkäyttö kohdassa on vihreä oikeinmerkki, ja sen avaamalla löytyy teksti
-- Täysin käytettävissä verkkosi ulkopuolelta
Voit käyttää tätä palvelinta kirjautuneilla Plex-sovelluksilla tai selaimellasi osoitteessa Plex.
--
Siis on tehty tunnus, vahvistettu ja sen jälkeen ovat koittaneet kirjastoa. Toimi alkuun, sitten ei. Haki Shield TV:n jopa, kun sanoin, että voisiko olla kodekkiongelma ja sama jatkuu. Välillä 4K:kin pyörii hyvin, välillä ei lähde mikään pyörimään. Välillä Plexin uudelleenkäynnistys auttaa, toisinaan ei. Nettinopeuksista ei pitäisi olla kiinni, kun serverin päässä 1000/100 ja toisessa päässä 1000/100 wanissa, vahva signaali ja Asuksen RT-AX92U. Ja ongelmat olivat sitä ennen myös, kun toisessa päässä oli Asuksen sijaan DNA:n oma laite.
E: Ja Plex näyttää tosiaan jatkuvasti etäyhteyden olevan kunnossa.
Siis on tehty tunnus, vahvistettu ja sen jälkeen ovat koittaneet kirjastoa. Toimi alkuun, sitten ei. Haki Shield TV:n jopa, kun sanoin, että voisiko olla kodekkiongelma ja sama jatkuu. Välillä 4K:kin pyörii hyvin, välillä ei lähde mikään pyörimään. Välillä Plexin uudelleenkäynnistys auttaa, toisinaan ei. Nettinopeuksista ei pitäisi olla kiinni, kun serverin päässä 1000/100 ja toisessa päässä 1000/100 wanissa, vahva signaali ja Asuksen RT-AX92U. Ja ongelmat olivat sitä ennen myös, kun toisessa päässä oli Asuksen sijaan DNA:n oma laite.
Nyt otin custom server urlit pois ja käynnistin Plexin uudelleen. Kännykällä appilla etänä toimii virheettömästi (kuten myös kännykällä etänä selaimen kautta), pöytäkoneella tai läppärillä (etänä) ei lähde pyörittään eikä löydä serveriä ilmeisesti.
Jos otit custom server urlit pois, niin se ei ainakaan tossa screenshotissa näytä tyhjältä...
Millä clientilla yrität tietokoneella?
Onko toi asennettuna Dockerin konttiin vai suoraan palvelimelle esim deb pakettina?
Jos otit custom server urlit pois, niin se ei ainakaan tossa screenshotissa näytä tyhjältä...
Millä clientilla yrität tietokoneella?
Onko toi asennettuna Dockerin konttiin vai suoraan palvelimelle esim deb pakettina?
En tiedä voiko vaikuttaa ongelmaasi mutta sulla on tuolla DHCP range .10 - .244 ja serverin IP on .100. Tuossa voi käydä niin että koku DHCP clientti saa tuon .100 osoitteen ja sitten on kaksi laitetta samalla IP osoitteella verkossa.
En tiedä voiko vaikuttaa ongelmaasi mutta sulla on tuolla DHCP range .10 - .244 ja serverin IP on .100. Tuossa voi käydä niin että koku DHCP clientti saa tuon .100 osoitteen ja sitten on kaksi laitetta samalla IP osoitteella verkossa.
Tämä ongelma näyttäisi nyt ratkenneen. Eli ongelma oli joko DDNS-palveluiden käyttämisessä Plexissä tai tuo sisäverkon portinohjaus, joka oli muuttunut inactiveksi.
