verbinding IoT niet stabiel (webserver achter 4G dongle)

[pieterdp]

Beste forumleden,

ik heb volgend probleem waar ik niet uit geraak.

Voor een natuurproject proberen we een Raspberry Pi continu metingen te laten doen in het veld. Graag lezen we die resultaten realtime uit.
Daarom is de Pi raadloos verbonden (afstand < 1m) met een 4G Dongle (merk ZTE). De Pi is als OpenVPN Client verbonden met de NAS die als OpenVPN server ingesteld staat. Via DDNS en correct port-forwarding op mijn router, kan ik dan met Reverse Proxy routing op mijn NAS naar de webpage op de Raspberry Pi surfen, en dit vanaf eender welk public IP.

Dit lukt.

Echter, regelmatig valt de connectie weg (t.t.z. ik kan dan niet naar de pagina van de Raspberry Pi surfen). Soms voor een aantal uren, en soms voor een dag of dagen. Dan krijg ik volgende fout: "Proxy Error The Proxy server received an invalid response from an upstream server The proxy server could not handle the request" (Raspberry Pi webserver draait op Caddy).
Ik kan op dat moment echter wél pingen naar de Raspberry Pi (bv vanaf mijn NAS), evenwel met vertragingen van 1 - 2 s.
De data voor de webpagina zijn beperkt (volgens chrome wordt er ong 300KB getransfered en 1.4MB resources). Site staat hier.

Toen ik vandaag even ter plaatste was, kon ik mijn telefoon verbinden via de WIFI van de ZTE dongle, en kon ik toch (traag) naar bv destandaard surfen. De pagina van de webserver kreeg ik via de DNS niet geladen.

Na de verbinding af en aan te zetten, lukte het wel terug.


Nu heb ik de ZTE dongle ingesteld op 4G verbinding, en de APN handmatig geconfigureerd (globaldata.iot) zoals aangegeven door de aanbieder van de SIM kaart (en roaming geactiveerd). SIM kaart is van Always Connected.

Ik zie dat signaalsterkte ongeveer -107dBm is, en denk/vermoed dat dit het probleem is (nl vlak bij de Nederlandse grens), en hierdoor verbinding soms wél en soms niet werkt.
Al vind ik het gek dat ik daar ter plaatste altijd wel 4G verbinding heb, én ik vind het gek dat de verbinding soms wel werkt (ondanks lage signaalsterkte).


VRAGEN voor het forum:
1) zou een extra externe antenne voor de dongle kunnen helpen?

2) zou ik andere of extra instellingen aan de ZTE dongle moeten geven?

3) zou het eventueel een ander probleem kunnen zijn (bv de reverse proxy server op de NAS)?

(PS, opstelling waarbij de Pi de data doorgeeft aan een andere server die dan op een stabieler netwerk draait, is absoluut niet aan de orde)

[Sethro]

Je hebt een hele keten opgetuigd waar het in iedere schakel mis kan gaan. In dit soort gevallen is meten is weten, gissen is missen.

[laurens0619]

Omdat de ping wel werkt dan gok ik dat er een timeout op de proxy zit. Welke proxy software gebruik je? Kun je een timeout ruimer zetten?

Mbt openvpn: draai je dit op udp of tcp?

Die reverse proxy is niet perse nodig. Je kunt openvpn ook zo configureren dat je direct bij de client uit komt vanuit je portmapping.

Je kunt ook je openvpn techniek vervangen voor tailscale of ngrok. Dan kun je het miss zelf draaiend krijgen zonder je nas.


Edit:
Andere optie is je pi een ssh verbinding laten opbouwen met thuis ip (met reconnect/watchdog script) en dan port te mappen:



Alhoewel dat ik verwacht dat deze gevoeliger ie voor lijnstoringen dan vpn

[ Voor 98% gewijzigd door laurens0619 op 17-03-2024 00:07 ]

[pieterdp]

hi laurens0619,

de proxy is diegene die op mijn QNAP NAS staat. Heb de timeout even verhoogt naar 300s, maar dit helpt niet.

OpenVPN gaat via UDP.

Wanneer de Pi verbonden is via een andere WIFI, lijkt alles wel stabiel te zijn, dus vermoed toch niet dat het aan de proxy server of iets anders op mijn home netwerk ligt.

Op dit moment krijg ik geen reply van de site, en heb onderstaande ping results (die mij toch redelijk OK lijken):


Ter info, connecten via SSH (openvpn ip) lukt, maar valt regelmatig uit (werkt perfect indien site wél bereikbaar). Connecten via WinSCP (SFTP, SCP) lukt niet wanneer site niet bereikbaar, maar wél wanneer wel bereikbaar.




Als ik rechtstreeks de port wil mappen naar de Pi webserver, is dan volgende correct:
port forward op de router naar OpenVPN IP van de PI? Moet er dan nog ergens iets in de Pi toegevoegd worden mbt routing?

Dank,
Pieter

[ Voor 24% gewijzigd door pieterdp op 17-03-2024 09:31 ]

[Ben(V)]

Ik begrijp je keten niet helemaal.
Wie zet de VPN verbinding op?

1. De OpenVpn client op je Qnap die een VPN tunnel opzet naar een OpenVpn server op die pi.
2. Een OpenVpn client op de pi die een VPN tunnel opzet naar een OpenVpn server op de Qnap.

In het eerste geval heb je een connectie probleem want een 4G dongle heeft geen vast ipadres.
In het tweede geval moet je portforwarding in je thuisrouter goed staan en moet je een job op die pi hebben draaien die de VPN tunnel controleert en opnieuw opbouwt als hij wegvalt.

[pieterdp]

Ben(V) schreef op zondag 17 maart 2024 @ 09:44:
Ik begrijp je keten niet helemaal.
Wie zet de VPN verbinding op?

1. De OpenVpn client op je Qnap die een VPN tunnel opzet naar een OpenVpn server op die pi.
2. Een OpenVpn client op de pi die een VPN tunnel opzet naar een OpenVpn server op de Qnap.

In het eerste geval heb je een connectie probleem want een 4G dongle heeft geen vast ipadres.
In het tweede geval moet je portforwarding in je thuisrouter goed staan en moet je een job op die pi hebben draaien die de VPN tunnel controleert en opnieuw opbouwt als hij wegvalt.

2de/ OpenVPN server draait op de NAS. Reverse proxy op de NAS stuurt data/requests voor de Pi webserver richting die Pi.

[laurens0619]

Hmm das wel vreemd, wel ping geen verbinding.
Heb je al eens een lage keepalive ingesteld? En houdt je client wel na reconnect hetzelfde openvpn ip?

[pieterdp]

laurens0619 schreef op zondag 17 maart 2024 @ 20:16:
Hmm das wel vreemd, wel ping geen verbinding.
Heb je al eens een lage keepalive ingesteld? En houdt je client wel na reconnect hetzelfde openvpn ip?

OpenVPN IP client is statisch ingesteld, en de client is verbonden (en blijft bereikbaar).

Lage keepalive is in principe aanwezig, omdat de Pi iedere vijf minuten pingt naar de VPN Server. Tenzij je iets anders zou bedoelen?

Pieter

[laurens0619]

pieterdp schreef op zondag 17 maart 2024 @ 20:54:
[...]


OpenVPN IP client is statisch ingesteld, en de client is verbonden (en blijft bereikbaar).

Lage keepalive is in principe aanwezig, omdat de Pi iedere vijf minuten pingt naar de VPN Server. Tenzij je iets anders zou bedoelen?

Pieter

Ja doelde op openvpnconfig key
https://superuser.com/que...tion-over-unreliable-line

[amiaima]

Even proberen of het band gerelateerd is, 2.4 of 5ghz.

[Ramon]

Vanochtend kreeg ik maar een deel van de HTML binnen, maar momenteel lijkt het wel goed te werken, ik weet niet of je iets veranderd hebt?

Ik heb niet echt verstand van deze zaken, maar wat ik wel nog wilde zeggen is dat het misschien makkelijker is om een proxy in te richten op een VPS, dan haal je het hele router/portforwarding verhaal uit de keten, maakt het misschien wat overzichtelijker.

[pieterdp]

amiaima schreef op zondag 17 maart 2024 @ 21:05:
Even proberen of het band gerelateerd is, 2.4 of 5ghz.

Dank, maar de dongle staat op minder dan één meter van de Pi, dus dat kan volgens mij het probleem niet zijn. Wordt trouwens bevestigd doordat pingen etc naar de Pi wel mogelijk blijft.

[pieterdp]

Ramon schreef op zondag 17 maart 2024 @ 21:34:
Vanochtend kreeg ik maar een deel van de HTML binnen, maar momenteel lijkt het wel goed te werken, ik weet niet of je iets veranderd hebt?

Ik heb niet echt verstand van deze zaken, maar wat ik wel nog wilde zeggen is dat het misschien makkelijker is om een proxy in te richten op een VPS, dan haal je het hele router/portforwarding verhaal uit de keten, maakt het misschien wat overzichtelijker.

Inderdaad, dit is dus het probleem: in 60% van de tijd kan de pagina laden, en dan 40% van de tijd niet.

Wanneer de pagina niet laadt, en ik toch dan SSH'en, dan crasht SSH van zodra ik een bestand probeer te openen. Er is dus connectie, maar hij heeft moeilijkheid met "grote" data. Site is maar een aantal honder KB, maar heeft daar blijkbaar moeite mee dan.

Site is nu live, en de ping response tijd is dezelfde als wanneer site niet volledig laadt.

De reden waarom ik met bestaande setup werk, is vooral budget gerelateerd (puur vrijwillegerswerk), dus probeer mijn bestaande en beschikbare infrastructuur te gebruiken zonder extra licencies of subscriptions te moeten aankopen.

[laurens0619]

Probeer eens NGROK te installeren naast je openvpn setup.
Moet je wel zeker weten dat openvpn niet gebruikt wordt voor al je internet verkeer en ngrok direct naar buiten gaat.

https://thisdavej.com/how...-the-internet-with-ngrok/

Kun je gewoon parallel draaien. JE kunt er ook ssh toegang mee regelelen.

Via Wifi naar zon goedkoop dongeltje lijkt mij ook suboptimaal.
Mooiste lijkt mij een bedrade mifi router met richantenne (teltonika ofzo) maar dat gaat beetje voorbij budget

Is een Huawei E3372(h-510) via de usb poort niet een idee? Zijn voor weinig te koop en "lijkt" mij stabieler dan via wifi.

edit:
je kunt ook openvpn via TCP overwegen. Snelheid zal wel flink achteruit gaan maar als je lijn zo instabiel is dan zou dat wel wat stabiliteit kunnen brengen

[ Voor 41% gewijzigd door laurens0619 op 18-03-2024 11:19 ]

[Hennie-M]

Wellicht kan je veel bandbreedte besparen door de webserver niet op de Pi te draaien maar op de NAS. De Pi stuurt alleen zijn meetwaardes door ipv een gegenereerde website.
En als dit een valide usecase is, is het misschien ook wel interessant om te kijken naar LoRa?

[Ben(V)]

Een webserver samen met een OpenVpn client is denkt gewoon te veel voor een pi.
Welk type pi is het?

[pieterdp]

Ben(V) schreef op maandag 18 maart 2024 @ 11:19:
Een webserver samen met een OpenVpn client is denkt gewoon te veel voor een pi.
Welk type pi is het?

een Pi5, dus niet moet toch wel iets aankunnen.
Trouwens, in een "wired" opstelling, dus Pi5 verbonden in een remote netwerk (dus zonder dongle) werkt alles prima.

[pieterdp]

Hennie-M schreef op maandag 18 maart 2024 @ 11:10:
Wellicht kan je veel bandbreedte besparen door de webserver niet op de Pi te draaien maar op de NAS. De Pi stuurt alleen zijn meetwaardes door ipv een gegenereerde website.
En als dit een valide usecase is, is het misschien ook wel interessant om te kijken naar LoRa?

Al veel over nagedacht, maar dan zouden alles bestanden (vnl audio files) doorgestuurd moeten worden via de 4G verbinding. Is gemakkelijk 5 - 10Gb per dag, dus dat zou mij een fortuin kosten.

[jeroen3]

Kun je Zerotier proberen? Dan neemt de complexiteit van je installatie enorm af.

[Roy Tollenaar]

pieterdp schreef op maandag 18 maart 2024 @ 11:38:
[...]

een Pi5, dus niet moet toch wel iets aankunnen.
Trouwens, in een "wired" opstelling, dus Pi5 verbonden in een remote netwerk (dus zonder dongle) werkt alles prima.

Odido geeft bijvoorbeeld 20GB per dag dus dat zou moeten kunnen denk ik.

[laurens0619]

Ik lees dat die birdnet pi een onderliggende SQLite database gebruikt.
Kun je niet een sync tooltje erop plakken dat die DB change gesynct wordt naar een .sqllite database die ergens op internet draait? En dan de website vanuit de gesyncte database benaderen?

[ Voor 11% gewijzigd door laurens0619 op 18-03-2024 16:17 ]

[pieterdp]

laurens0619 schreef op maandag 18 maart 2024 @ 16:10:
Ik lees dat die birdnet pi een onderliggende SQLite database gebruikt.
Kun je niet een sync tooltje erop plakken dat die DB change gesynct wordt naar een .sqllite database die ergens op internet draait? En dan de website vanuit de gesyncte database benaderen?

zeker een goed idee, maar dit zal me heel wat 4G data kosten (5-10GB/dag aan audiobestanden), dus veel te kostelijk voor mij

[laurens0619]

pieterdp schreef op maandag 18 maart 2024 @ 18:32:
[...]


zeker een goed idee, maar dit zal me heel wat 4G data kosten (5-10GB/dag aan audiobestanden), dus veel te kostelijk voor mij

Staat de audio in de sqlite database? Ik zou verwachten van niet

[pieterdp]

Roy Tollenaar schreef op maandag 18 maart 2024 @ 15:19:
[...]

Odido geeft bijvoorbeeld 20GB per dag dus dat zou moeten kunnen denk ik.

zou zeker kunnen, maar is -helaas- allemaal zelf te bekostigen, en abonnementen van Odido zijn voor een jaar, dus kost mij nog altijd een pak geld...

[pieterdp]

laurens0619 schreef op maandag 18 maart 2024 @ 18:34:
[...]

Staat de audio in de sqlite database? Ik zou verwachten van niet

Je hebt gelijk, ik zou DB en audiobestanden kunnen loskoppelen, maar dat komt dan eigenlijk neer op het herschrijveven dan de webpage, waarbij je in eerste instantie de DB gebruikt en enkel bij doorklikken naar audiofragment naar de originele server gaat.
Mijn kennis hiervan is nu ook niet dat ik dat in een dagje klaarspeel...

[laurens0619]

@pieterdp
herschrijven hoeft niet perse.
Stel je hebt een map: /var/www/audio waar het instaat

Op je kopie webserver vervang je die map door een remote ssh locatie (op filesysteem niveau). Op het moment dat bestand wordt aangesproken, stream hij die via ssh maar binnen. Website/server heeft geen weet ervan, die denkt dat je lokaal bestand aanspreekt

sudo sshfs [-o <options>] <remote user>@<remote host>:/<path to remote directory> /mnt/<folder name>/

Mar anders zou ik een van de andere opties proberen die ik aangedragen heb waar ik zou beginnen met
- NGROK/tailscale/ssh tunnel opzetten voor ssh en http

Dan creer je namelijk secundaire manier om te verbinden.

Daarna:
openvpn op tcp

[ Voor 50% gewijzigd door laurens0619 op 18-03-2024 20:10 ]

[Ben(V)]

@laurens0619
Waarom OpenVpn over tcp?
Dat is enkel extra overhead volgens mij.
Van de OpenVpn website:

The OpenVPN protocol itself functions best over just the UDP protocol.

[ Voor 41% gewijzigd door Ben(V) op 19-03-2024 09:42 ]

[laurens0619]

Ben(V) schreef op dinsdag 19 maart 2024 @ 09:39:
@laurens0619
Waarom OpenVpn over tcp?
Dat is enkel extra overhead volgens mij.
Van de OpenVpn website:

[...]

Omdat het onderliggende 4g netwerk wss zwaar instabiel is.
Ik vermoed dat openvpn via TCP dan een stuk trager maar wel stabieler kan wordenb (of nog erger door de double TCP compensation meltdown )

[ Voor 7% gewijzigd door laurens0619 op 19-03-2024 10:14 ]

[Ben(V)]

Neh de connectie wordt door OpenVpn beheerd en die neemt alle extra functionaliteit die tcp (statefull ipv stateless) boven udp heeft voor zijn rekening.
Het enige wat je er mee bereikt is meer overhead.