Ik vind het discutabel of het aan KPN ligt. Waarom zou KPN dit IP-adres blokkeren? Het enige wat ik mij kan indenken is dat ze een gerechtelijke basis hebben, omdat er een PirateBay-site op draait of iets dergelijks. Maar daar is geen sprake van, of het is een gerecycled IP ofzo die nog daarvan in een blocklist staat. maar in het algemeen krijg je dan een nette KPN-melding.
@ikheetjeff Vandaag wat traceroutes geprobeerd met de diverse ip adressen en alleen op 76.76.21.22 komt er na 10 hops een reactie. Bij alle andere ip adressen 76.76.21.21 , 76.76.21.124 alleen tot 30 hops sterretjes.
Ook een ping op.22 werkt.
ping 76.76.21.22
PING 76.76.21.22 (76.76.21.22) 56(84) bytes of data.
64 bytes from 76.76.21.22: icmp_seq=1 ttl=250 time=3.70 ms
64 bytes from 76.76.21.22: icmp_seq=2 ttl=250 time=3.98 ms
64 bytes from 76.76.21.22: icmp_seq=3 ttl=250 time=3.70 ms
64 bytes from 76.76.21.22: icmp_seq=4 ttl=250 time=3.49 ms
64 bytes from 76.76.21.22: icmp_seq=5 ttl=250 time=3.84 ms
64 bytes from 76.76.21.22: icmp_seq=6 ttl=250 time=3.82 ms
64 bytes from 76.76.21.22: icmp_seq=7 ttl=250 time=3.68 ms
^C
--- 76.76.21.22 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 3.492/3.744/3.977/0.140 ms
@Alexandra van KPN Afgaande op bovenstaande reacties zou ik toch willen vragen aan de experts om te kijken of ip. 76.76.21.21 ergens door KPN wordt tegengehouden. Het is wel vreemd dat niet alle KPN gebruikers hier last van hebben maar mogelijk zit het verschil in de soort KPN verbinding die gebruikt wordt. Mijn verbinding heeft als hostname: "84-82-*-*.fixed.kpn.net", maar ik begrijp uit sommige commentaren dat bij andere glasvezel verbindingen de hostname na het ip adres anders is dus via een andere server loopt.
Mijn verbinding heeft als hostname: "84-82-*-*.fixed.kpn.net", maar ik begrijp uit sommige commentaren dat bij andere glasvezel verbindingen de hostname na het ip adres anders is dus via een andere server loopt.
De gateway via welke jouw aansluiting communiceert is 195.190.228.102 terwijl mijn aansluiting via gateway 195.190.228.93 loopt.
Mijn verbinding heeft als hostname: "84-82-*-*.fixed.kpn.net", maar ik begrijp uit sommige commentaren dat bij andere glasvezel verbindingen de hostname na het ip adres anders is dus via een andere server loopt.
De gateway via welke jouw aansluiting communiceert is 195.190.228.102 terwijl mijn aansluiting via gateway 195.190.228.93 loopt.
@Alexandra van KPN Waarschijnlijk zit daar het verschil de blokkade is alleen van toepassing op gateway 195.190.228.102
@JohanRobotics Het is veel waarschijnlijker dat een derde bedrijf in de routing tabel de ip adres blokkeert. Verschillende KPN regionale nodes gebebruiken verschillende routes naar buitenland (hier USA)
Dus: 76.76.21.22 is met “traceroute -I” te benaderen. Ik neem aan dat in de routing tabellen 76.76.21.0/24 naar Vercel gerouteerd wordt, dus dat .22 te bereiken is en .21 niet is al vreemd. Wat ik nog veel vreemder vind is da mqtt servers die hetzelfde adres gebruiken wel werken. Ik heb geen kennis van mqtt, werkt dat ook via poort HTTP/HTTPS ? Data reizen over het internet met een bronadres/poort en een bestemmingsadres/poort. Amazon/Vercel moeten beslissingen nemen op basis van de “Host” header in de HTTPS aanvraag, of misschien daarvoor al in de TLS, maar een ieder geval op een heel ander niveau. Ik heb geen idee hoe ze dat doen op zo’n grote schaal.
Toevallig buren/kennissen in de buurt die KPN abonnee zijn en ook routeren naar 76.76.21.21 via 195.190.228.102 ? Als het daar werkt dan lijkt het me geen KPN probleem, maar is of lokaal iets geks aan de hand of gebeuren bij Vercel heel vreemde dingen.
Dus: 76.76.21.22 is met “traceroute -I” te benaderen. Ik neem aan dat in de routing tabellen 76.76.21.0/24 naar Vercel gerouteerd wordt, dus dat .22 te bereiken is en .21 niet is al vreemd. Wat ik nog veel vreemder vind is da mqtt servers die hetzelfde adres gebruiken wel werken. Ik heb geen kennis van mqtt, werkt dat ook via poort HTTP/HTTPS ? Data reizen over het internet met een bronadres/poort en een bestemmingsadres/poort. Amazon/Vercel moeten beslissingen nemen op basis van de “Host” header in de HTTPS aanvraag, of misschien daarvoor al in de TLS, maar een ieder geval op een heel ander niveau. Ik heb geen idee hoe ze dat doen op zo’n grote schaal.
Toevallig buren/kennissen in de buurt die KPN abonnee zijn en ook routeren naar 76.76.21.21 via 195.190.228.102 ? Als het daar werkt dan lijkt het me geen KPN probleem, maar is of lokaal iets geks aan de hand of gebeuren bij Vercel heel vreemde dingen.
MQTT kan ook werken via WebSockets, die standaard poort 443 gebruiken . Hierdoor kan MQTT gebruikmaken van HTTP- en HTTPS-infrastructuur. WebSocket is een protocol dat full-duplex communicatiekanalen biedt via een enkele TCP-verbinding, geschikt voor realtime gegevensoverdracht.
Bedankt voor de toelichting, dus die kunnen via de zelfde infrastructuur naar de juiste server geleid worden. Overigens staat op https://github.com/orgs/vercel/discussions/7314 wel een rechtstreekse kloon van dit probleem. Hier wordt door Vercel eerst een probleem geconstateerd wordt, maar vervolgens de discussie gesloten met verwijzing naar een pagina dat het probleem aan de andere kant neerlegt en adviseert een VPN te gebruiken. Verschillende probleemrapporten, nergens een echte verklaring.
Zouden Amazon/Vercel een beschermingssysteem hebben dat ze zelf niet beheersen?
Dat neemt niet weg dat het mijn pet totaal te boven gaat dat die mqtt servers te bereiken zijn. Hebben die niet stiekum een AAAA record en communiceren via IPv6 rechtstreeks zonder die reverse proxy infrastructuur ertussen?
Bedankt voor de toelichting, dus die kunnen via de zelfde infrastructuur naar de juiste server geleid worden. Overigens staat op https://github.com/orgs/vercel/discussions/7314 wel een rechtstreekse kloon van dit probleem, waarbij eerst een probleem geconstateerd wordt, en vervolgens de discussie gesloten met verwijzing naar een pagina dat het probleem aan de andere kant neerlegt en adviseert een VPN te gebruiken. Verschillende probleemrapporten, nergens een echte verklaring.
Zouden Amazon/Vercel een beschermingssysteem hebben dat ze zelf niet beheersen?
Dat neemt niet weg dat het mijn pet totaal te boven gaat dat die mqtt servers te bereiken zijn. Hebben die niet stiekum een AAAA record en communiceren via IPv6 rechtstreeks zonder die reverse proxy infrastructuur ertussen?
https://github.com/orgs/vercel/discussions/7314
Dit is 100% hetzelfde probleem want het is ook op diezelfde datum 27 juni bij mij begonnen.
@Alexandra van KPN For Personal Networks
Get in touch with your Internet Service Provider’s customer support. Explain the issue and ask that they unblock vercel.com, vercel.app, and 76.76.21.21.
Hier zou je zeggen dat het bij KPN ligt
Twee niet aan elkaar gerelateerde ISP’s krijgen een identiek probleem op hetzelfde moment, een bepaald adres heeft het probleem, de buurman of een groep forumgebruikers niet. Ik zou dan toch gaan denken dat bij Vercel iets mis gegaan is op IP adres niveau en dat bijvoorbeeld de op dat moment actieve gebruikers in een blacklist terecht gekomen zijn.
Maar hoe zodanig door de helpdesk heen te prikken dat er daadwerkelijk goed gekeken wordt of er wellicht wat onjuiste en/of ongedocumenteerde regels in de firewall staan. Maar misschien heeft iemand met kennis van de werkwijze in datacenters een ander idee….
Ik kan zien dat Amazon AWS niet de bedrijf, de 76.76.21.21 blokkeert
9 ???
10 15.230.162.58 0.0% 16.46ms
11 15.230.162.53 0.0% 11.91ms
12 76.76.21.21 AMAZON-02, US 76.76.21.0/24 0.0%
9 ???
10 150.222.103.107 0.0% 1.13ms
11 150.222.103.90 0.0% 1.05ms
12 76.76.21.22 AMAZON-02, US 76.76.21.0/24 0.0% 0.55ms
En wat zien we in jouw bericht @TDN?
@wjb De laatste stuk van traceroute naar 76.76.21.21 en 76.76.21.22, de anderen hoops zijn allemaal sterren, dus onbelangrijk om te laten zien.
@wjb De laatste stuk van traceroute naar 76.76.21.21 en 76.76.21.22, de anderen hoops zijn allemaal sterren, dus onbelangrijk om te laten zien.
Maar wat zien we nu in die twee traceroutes?
Verklaar alsjeblieft tot welke conclusie je bent gekomen en op basis waarvan je tot die conclusie gekomen bent.
@wjb De twee traceroutes zijn allemaal aangekomen, dus geen bedrijven in mijn routes naar endpunten blokkeren deze ip adressen. De laatste hoops en endpunten zijn allemaal Amazon IP adressen. Dwz, als de data bij Amazon aangekomen is, worden ze zonder beperking geroutet. Andere knooppunten laten niet achterhalen, bij welke bedrijven ze behoren, maar ze blokkeren ook niet.
Twee niet aan elkaar gerelateerde ISP’s krijgen een identiek probleem op hetzelfde moment, een bepaald adres heeft het probleem, de buurman of een groep forumgebruikers niet. Ik zou dan toch gaan denken dat bij Vercel iets mis gegaan is op IP adres niveau en dat bijvoorbeeld de op dat moment actieve gebruikers in een blacklist terecht gekomen zijn.
Ik heb me er niet in verdiept, maar volgens mij kan iedereen vanaf dat IP iets hosten. Iedereen een Vercel app. Dus er zijn duizenden sites, en daar zitten ook misbruikers tussen. Daardoor kan zo’n IP op blacklists belanden en kan iedereen last van hebben.
Zie hier bijvoorbeeld de laatste reports van dit IP. https://www.abuseipdb.com/check/76.76.21.21 Er wordt dus best wel wat misbruik van gemaakt, zelfs met brute force inlogpogingen etc. Gisteren was deze score nog 0%.
@wjb De twee traceroutes zijn allemaal aangekomen, dus geen bedrijven in mijn routes naar endpunten blokkeren deze ip adressen. De laatste hoops en endpunten zijn allemaal Amazon IP adressen. Dwz, als de data bij Amazon aangekomen is, worden ze zonder beperking geroutet. Andere knooppunten laten niet achterhalen, bij welke bedrijven ze behoren, maar ze blokkeren ook niet.
Dus dat is wat je bedoelt met "Ik kan zien dat Amazon AWS niet de bedrijf, de 76.76.21.21 blokkeert".
76.76.21.21 behoort tot AS16509, Autonomous System, en dat is Amazon. Vercel pakt daar een stuk van.
Daar snap ik vervolgens weer helemaal niets van, want de RIPE-probes van AS16509 zijn over de hele wereld verspreid. Dus als je denkt, mooi, routing is de beste route zoeken tussen AS’n die hun IP ranges gepubliceerd hebben, dan is het AS16509 over de hele wereld verspreid. Dus zie ik het te simpel en moet het toch weer anders werken.
Maar dat terzijde.
Ik neem aan dat als een ISP op basis van een blacklist een adres blokkeert, alle gebruikers de blokkade ervaren, en niet een enkele. Tenzij de gebruiker zelf via een of andere security software zelf de blokkade veroorzaakt. In ieder geval gaan de pakketten voor 76.76.21.21 naar buiten, want de 1e KPN router meldt zich in traceroute.
Dat dit soort constructies bestaat toont wel aan dat IPv4 adressen echt schaars zijn. Als een adres voor zo’n groot aantal websites gebruikt wordt hoeft er maar een flink rotte appel tussen te zitten. Hoog tijd om die sites via IPv6 toegankelijk te maken en 76.76.21.21 alleen voor fallback…
Nog iets, is hierboven ook al ergens genoemd. Bij Vercel lees ik dat een site een A record moet hebben in DNS of een CNAME record. CNAME moet dan wijzen naar cname.vercel-dns.com, en die zit op:
host cname.vercel-dns.com
cname.vercel-dns.com has address 76.76.21.61
cname.vercel-dns.com has address 76.76.21.22
Als ik robot-maatje.com in /etc/hosts zet op 76.76.21.61, en de site oproep, dan doet hij het en loopt (tcpdump) de communicatie daadwerkelijk via 76.76.21.61. Dat zelfde geldt voor 76.76.21.22 (dus niet 21.21).
Kan het zijn dat Vercel via dat CNAME mechanisme de best werkende servers adverteert en dat het beter is dat te gebruiken in plaats van rechtstreeks 76.76.21.21 ???
(vergeet in ieder geval niet /etc/hosts weer leeg te maken….)
Is dit de oplossing van het raadsel:
- If you're using an Apex domain (e.g. example.com), you will need to configure it with an A record
- If you're using a Subdomain (e.g. docs.example.com), you will need to configure it with a CNAME record
m.a.w. robot-maatje.com moet toch op 76.76.21.21, maar de mqtt servers lopen via 76.76.21.22 of 76.76.21.61.
@AriënC @hmmsjan_2 @wjb @ikheetjeff Sinds vanmorgen kan ik ons platform weer bereiken zonder gebruik te maken van een VPN. Wat de oorzaak is geweest zal ik wel nooit te weten komen.
Maar ik wil in ieder geval iedereen op dit forum die heeft mee gezocht naar een mogelijke oplossing hartelijk bedanken.
Fijn om te horen! Veel succes ermee! 
