24748
netweters
|
152280
antwoorden
|
20688
vragen
|
Eerst wil ik even vermelden dat dit een week of 2 geleden perfect werkte.
Ik gebruik cloudflare (cf) proxies al jaren om mijn ip's niet onnodig publiek te maken, voor caching en voor bescherming.
Poort 80 en 433 staan open in ons telenet dashboard, requests direct naar ons ip of requests naar een domein met een A record naar ons ip werken perfect.
Wanneer er een cf proxy aanstaat op 1 van de domeinen dan komt dat request niet aan bij mijn server en toont cloudflare hun eigen 522 pagina.
Ik gebruik een kleine server geschreven in rust die een http server draait op poort 80 gebonden aan 0.0.0.0. Wanneer ik een request doe doorheen een cloudflare proxy logt deze server niets naar de terminal, alle andere requests doen dat wel zoals verwacht.
Ik denk dat cloudflare misschien wordt geblokkeerd, al zou ik dit zeer vreemd vinden.
Normaal draai ik en traefik proxy op 433 die verder de binnenkomende requests verdeeld naar de services op ons thuisnetwerk zoals homeassistant, netdata, traefik-dashboard, ect..
Ik zoek hier een oplossing voor aangezien caching en ons ip verbergen wel nuttig zijn, alle hulp is geapprecieerd.
Meer info:
- testing programma dat ik heb gebruikt: https://github.com/ToxicMushroom/http-test
- server draait Ubuntu 21.04 (GNU/Linux 5.11.0-25-generic x86_64)
Opgelost! Ga naar oplossing.
Ik ken er nougatballen van maar ben 'ns wezen zoeken:
https://community.cloudflare.com/t/error-522-when-proxy-is-turned-on/166877
https://www.ionos.com/digitalguide/hosting/technical-matters/error-522-explanation-and-solutions/
Edit
https://www.reddit.com/r/HomeServer/comments/hapg0i/getting_522_error_while_trying_to_reverse_proxy/
De tweede vermelde link heb al eens bekeken, deze wees aan op geen ack sturen, maar ik krijg geen request om een ack op te sturen. Ook wezen ze daar op mogelijke problemen met de ISP dus vandaar dat ik het hier eens kwam vragen.
De derde link geeft wel wat nuttige info:
- ik heb de UFW (firewall service op ubuntu) eens uitgezet maar dat helpte niet, tevens is er ook een firewall optie in de modem die ik nog niet heb proberen uitzetten maar daar heb ik zelf geen toegang toe op dit ogenblik.
- Ik weet niet of mijn webserver keepalive headers respecteerd maar dat zou vgm nogsteeds een request voor de eerste aanvraag moeten loggen, desnoods vervang ik mijn testing programma met een tcp listener.
- De andere opgelijste oorzaken zijn vrijwel onmogelijk om door mij veroorzaakt te zijn.
De vierde link biedt ook geen antwoord op het probleem al is het wel hetzelfde probleem.
Ik zal nog wat verder proberen zien of ik wel een tcp request binnen kan krijgen, desnoods stop ik er een tweede proxy tussen (niet ideaal maarja).
Ik heb het nu zonder UFW (ubuntu firewall) en met tcp listener geprobeerd (zie dezelfde repository in de laatste commit)
Ik krijg nooit een request binnen van cloudflare zoals ik al verwachtte, cloudflare staat op not secure voor het testen zodat alles naar poort 80 zou gaan.
Ik zal nu nog een laatste poging doen door mijn firewall op de modem even uit te zetten maar dat is geen goede oplossing denk ik.
Een dubbele reverse proxy dan of eens bellen naar telenet support I guess. 🙂
(Het kan natuurlijk de schuld van cloudflare zijn maar dat werkt nog wel goed naar mijn andere servers dus dat zou een beetje vreemd zijn)
Contacteer Cloudflare anders 'ns?
Een aantal Kraks hier zullen je zeker kunnen helpen. Beetje geduld. Van sommigen zie ik weinig activiteit momenteel; vakantie?
Komt wel goed.
@PixelHamster heb je ook een server op HTTPS (TCP443) draaien via Cloudflare, en werkt die wel?
Hoe gebeurt de forwarding bij Cloudflare naar je eigen server, is dat via een hardcoded IP adres of via een DNS hostname?
Je hebt dus wellicht een business abonnement met een statisch IP adres? Of meerdere IP's?
cloudflare is mijn dns server ect dus dat is
A melijn.me -> ons public ip
maar wanneer de proxy aanstaant is het eigenlijk (ookal geef je dat zo niet in in hun dashboard)
A melijn.me -> random cf server
en de cf server doet dan de request naar het public ip
het domein dat ik niet proxy gebruikt een cname ding atm
CNAME netdata.melijn.me -> melijn.me
Ik heb hetzelfde probleem met SSL over 433 ja.
Al heb ik dat niet met mijn eigen tcp server getest. Ik kreeg echter geen debug logs in traefik voor https/http requests wanneer gebruik makend van cf proxies.
( Ik weet dat je het publiek ip atm kan vinden maar ik heb dat liever niet vereeuwigd in deze post )
@Steven-E Oh ik ben vergeten te vermelden dat ik geen "statisch" ip heb en ook geen business abonnement.
Ons ip address is de afgelopen 10 jaar 1 keer veranderd toen we een nieuwe modem kregen, het is nog steeds hetzelfde tot op vandaag (al kan het in theorie altijd veranderen).
@PixelHamster schreef:@Steven-E Oh ik ben vergeten te vermelden dat ik geen "statisch" ip heb en ook geen business abonnement.
Ons ip address is de afgelopen 10 jaar 1 keer veranderd toen we een nieuwe modem kregen, het is nog steeds hetzelfde tot op vandaag (al kan het in theorie altijd veranderen).
Hi @PixelHamster ,
Het enige dat ik hier kan bedenken is dat je publiek IP gewijzigd is, Cloudflare wordt niet geblokkeerd anders zou je geen 522 of 502 pagina krijgen. Telenet customer's support gaat je hier niet kunnen helpen, dit is "out of the scope".
Ik zou een testje met een andere DDNS dienst, zoals No-IP of ChangeIP, uitvoeren, in een paar minuutjes tijd is het klaar en je hoeft niets aan je CF configuratie veranderen, hiermee ga je kunnen testen of je lokale configuratie juist staat, zo ja, wilt het zeggen dat iets bij Cloudflare is veranderd.
Grtz,
Ik vermoed dat PixelHamster wel al gechecked heeft of het IP klopt, zoniet dringend checken 😉
@PixelHamster gebruik je DynDNS of heb je in Cloudflare je IP manueel ingegeven (aangezien je aangaf dat je IP nagenoeg nooit verandert, zou dit kunnen).
Ik vermoed manueel adhv de DNS entry in Cloudflare, het IP adres dat je onzichtbaar hebt gemaakt.
Als dit IP adres correct is, dan denk ik dat het op Cloudflare wel ok zit.
Doen zij ook nog firewalling ergens?
Tip: je zou toch met Dyndns kunnen werken en dan in Cloudflare CNAME records gebruiken ipv A-records. Dan ben je safe, ook al verandert je IP.
Ik zou eens een niveau lager gaan testen en kijken of er uberhaupt wel http requests toe komen op je server. Niet adhv je webserver logs, maar dmv tcpdump. Tcpdump is standaard aanwezig op de meeste linux systemen.
Hier een aantal voorbeelden: https://hackertarget.com/tcpdump-examples/
@Steven-E Ons IP is idd nog steeds hetzelfde, anders zouden de non-proxy requests ook niet aankomen 😛
Het is wel manueel ingevoerd dus het had gekund maar dat is wel het eerste wat ik heb nagekeken.
Ik heb tcpdump geprobeerd net en daar zie ik volgens mij de packets die ik wil ontvangen.
162.159.133.234 ect zijn cloudflare ips, dus hun proxy bereikt mijn server wel ? (niet zeker ik heb deze tool nog niet eerder gebruik)
maar waarom mijn software niet ?
mijn firewall staat al uit, ik heb vgm nooit zelf iets geblokkeerd
@PixelHamster schreef:162.159.133.234 ect zijn cloudflare ips, dus hun proxy bereikt mijn server wel ? (niet zeker ik heb deze tool nog niet eerder gebruik)
maar waarom mijn software niet ?
Geen idee, maar de tcpdump toont imho wel aan dat het probleem niet bij Telenet ligt (en vermoedelijk ook niet bij Cloudflare).
Kijk eens na of er op je server niets actief is wat dynamisch IP's blokkeert? Ratelimiting functies ofzo op je webserver.
Ja klopt, het ligt dan bij mij.
Wat ik wel vreemd vind is dat ook mijn eigen tcp server de packets niet kreeg, dus ik neem aan dat iets die ergens blokkeert op mijn server, ik zal er wat verder naar zoeken,
Jullie zijn allemaal erg bedankt 🙂
Een update nu ik het probleem heb "opgelost"
Oplossing: telenet modem/router powercyclen. (😳 did you try turning it off and on?)
Oorzaak: ongekend
Situatie:
Onze telenet router was er van overtuigd dat mijn server het ip 192.168.0.103 had (toonde zo in de web-interface) en er wordt enkel geportforward naar 192.168.0.33 (statisch ip van de server), hoe dat deze vreemde toestand er is gekomen weet ik niet.
Met nmap of andere tools vond je helemaal niets op .103 wel .33 zoals het hoort.
Achja dit ligt ook aan mij, ik wist niet dat naar ons publiek ip surfen van binnen ons netwerk niet hetzelfde was als van buiten ons netwerk naar het publiek ip surfen dus dacht ik dat het aan Cloudflare of Telenet lag.
Ik ben erg blij dat het nu weer allemaal werkt 🙂