Skip to main content

Sinds vorige maand kan ik één bepaalde website niet meer bereiken omdat mijn IP adres is geblokkeerd. Ik heb alle blacklists gecheckt en mijn IP adres komt daar niet op voor. De website wordt beveiligd door Auth0 en Cloudflare maar beiden geven aan dat mijn IP adres niet wordt geblokkeerd.

Op het moment dat ik overschakel op 4G of een VPN gebruikt dan werkt alles 100% het is dus duidelijk een ip blokkade ik heb zowel ipv4 als ipv6 nagekeken in de blacklists maar nergens een blokkade.

Heeft iemand op dit forum nog een suggestie hoe ik er achter kan komen wie wat en waar mijn IP wordt geblokkeerd.

@hmmsjan_2 Het rapport wat ik eerder publiceerde in dit forum was inderdaad van het debug script van Vercel. Dit heb ik naar Vercel opgestuurd en daarmee kwamen zij tot de conclusie dat het probleem bij KPN zou liggen omdat de aanroep van de URL nooit bij hun aankwam.


Excuses, als ik teruggekeken had, dan had ik moeten zien dat u de uitvoer van precies dat script hier al geplaatst heeft. Hier loopt alles vlekkeloos, inclusief curl uitvoer van de webserver.  Als ik het allemaal goed begrepen heb wordt de internet routering automatisch geregeld, en wordt daarbij 76.76.21.0/24 aangekondigd, dus als 76.76.21.21 niet te bereiken is, zijn de subdomeinen ook niet te bereiken als die naar hetzelfde adres refereren. Het gaat mijn beperkte kennis te boven, dat OAuth2 de mogelijkheid biedt om adressen te blokkeren hen ik gezien, maar dat dan Vercels voordeur dichtgegooid wordt gaat wel heel erg ver… 

 

 


Op de subdomeinen draait een mqtt server en ook deze zit op  76.76.21.21 deze mqtt server kan ik gewoon bereiken en aansturen.

Ik heb de gok gewaagd dat jij voor die mqtt server het subdomein mqtt.robot-maatje.com gebruikt.

Wijst robot-maatje.com naar 76.76.21.21, mqtt.robot-maatje.com wijst naar 20.54.136.70.


@wjb De mqtt servers draaien niet op robot-maatje.com maar op enkele domeinnamen die op dezelfde server staan en dus gebruik maken van hetzelfde IP adres.


@Alexandra van KPN Blijkbaar is er niemand die hier een oplossing voor kan vinden ook Amazon/Vercel/Auth0 geven niet thuis of geven KPN de schuld. Er is echter niemand die dit hard kan maken of eventueel kan aangeven waar het dan fout gaat. Dit duurt nu al meerdere maanden en een oplossing lijkt er niet te komen. Gezien er geen mogelijkheid bij KPN bestaat om mij een nieuw IP adres toe te wijzen ben ik bang dat ik noodgedwongen zal moet overstappen naar een andere provider om weer volledig operationeel te kunnen werken.


Jammer dat je er niet met Amazon/Vercel/Auth0 uitkomt. Je kan proberen dit te laten escaleren naar een hogere afdeling daar. 

Misschien komt het gek over, maar je kan het ook hard spelen. Amazon/Vercel/Auth0 zorgen voor een oplossing, of je stelt ze verantwoordelijk voor de kosten voor je nieuwe abonnement, omdat KPN duidelijk heeft bewezen dat het niet aan hun ligt. 


@AriënC  Dat is nu juist het probleem KPN vermoed dat het bij Amazon fout gaat, maar zeggen niet dat het daar fout gaat.


...omdat KPN duidelijk heeft bewezen dat het niet aan hun ligt. 

Heeft KPN duidelijk bewezen dat het niet aan hun kant ligt?

Wat mij betreft niet.


@JohanRobotics, Kan je hier eens een traceroute naar 76.76.21.22 plaatsen?


@wjb Op pagina 3 van dit topic staat een uitgebreid overzicht van de traceroutes


@wjb Op pagina 3 van dit topic staat een uitgebreid overzicht van de traceroutes

Maar net niet een traceroute naar 76.76.21.22 en dat is nu net degene die ik zou willen zien.


Lastige en vooral vervelende kwestie. Hard spelen richting Amazon/Vercel/Auth0 zal niet zoveel zin hebben, want die zijn vrij om hun firewall in te richten naar hun wensen.

Zover ik begrijp heeft Vercel aangegeven dat hun jouw IP niet hebben geblokkeerd. Maar dat jouw request niet eens bij Vercel aankomt, toch?

Ook https://reactjs.org werkt niet, toch? Werken deze sites bij jou?

Deze zijn allemaal ook verbonden aan 76.76.21.21. Als al die sites ook niet werken, moet je bij Amazon zelf zijn. Want Vercel heeft niks te verwerken, en Auth0 ook niet, want die komt na Vercel pas aan bod.

Ik denk dat KPN ook niet fout zit, maar wellicht kan je dit als Plan B escaleren binnen KPN voor een écht onderzoek vanaf jouw netwerk? Want volgens mij is er nu alleen getest vanaf een willekeurig KPN netwerk.


@wjb traceroute 76.76.21.22 
traceroute to 76.76.21.22 (76.76.21.22), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.423 ms  0.449 ms  0.501 ms
 2  static.kpn.net (195.190.228.102)  2.332 ms  2.580 ms  2.828 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *


@JohanRobotics, Dus een traceroute naar 76.76.21.22 komt niet tot een goed einde terwijl het wel lukt om die host te pingen?


Inmiddels moge het wel duidelijk zijn dat je op traceroute niet echt meer kunt vertrouwen als een host ICMP's (ping's) blokkeert.


Inmiddels moge het wel duidelijk zijn dat je op traceroute niet echt meer kunt vertrouwen als een host ICMP's (ping's) blokkeert.

Dat ben ik niet met je eens. Als de laatste hop maar reageert (bereikt wordt) dan is er niets mis zelfs als alle tussenliggende hops enkel sterretjes geven.

Wat wel vreemd is, is dat, in het geval van host 76.76.21.22 de ping naar die laatste host wel werkt terwijl de traceroute die host niet lijkt te bereiken. Dat is een beetje tegenstrijdig.


Wat wel vreemd is, is dat, in het geval van host 76.76.21.22 de ping naar die laatste host wel werkt terwijl de traceroute die host niet lijkt te bereiken. Dat is een beetje tegenstrijdig.

Is niks tegenstrijdigs aan. Dan wordt alleen TCP/UDP geblokkeerd en ICMP niet.


Wat wel vreemd is, is dat, in het geval van host 76.76.21.22 de ping naar die laatste host wel werkt terwijl de traceroute die host niet lijkt te bereiken. Dat is een beetje tegenstrijdig.

Is niks tegenstrijdigs aan. Dan wordt alleen TCP/UDP geblokkeerd en ICMP niet.

Een traceroute is, net als een ping, volledig ICMP.


Wat wel vreemd is, is dat, in het geval van host 76.76.21.22 de ping naar die laatste host wel werkt terwijl de traceroute die host niet lijkt te bereiken. Dat is een beetje tegenstrijdig.

Is niks tegenstrijdigs aan. Dan wordt alleen TCP/UDP geblokkeerd en ICMP niet.

Een traceroute is, net als een ping, volledig ICMP.

Nee hoor, Linux gaat via UDP. De traceroute op Windows gaat via ICMP. TS deed op MacOS, wat valt onder Linux. 


Met Linux altijd “traceroute -I” gebruiken. Als het doel antwoordt op ping, dan stopt traceroute daar.

traceroute -I 76.76.21.22

traceroute to 76.76.21.22 (76.76.21.22), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  5.827 ms  7.600 ms  7.680 ms
 2  195-190-228-48.fixed.kpn.net (195.190.228.48)  14.519 ms  13.880 ms  13.115 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  76.76.21.22 (76.76.21.22)  218.278 ms  222.504 ms  222.512 ms

 

Alternatief:

mtr -r -c 2 76.76.21.22
Start: 2024-09-05T20:10:36+0200
HOST: mamd                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- mijnmodem.kpn.home         0.0%     2    1.9   1.7   1.4   1.9   0.4
  2.|-- 195-190-228-48.fixed.kpn.  0.0%     2    9.9   8.2   6.4   9.9   2.5
  3.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  5.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  6.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  7.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  8.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  9.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 10.|-- 76.76.21.22                0.0%     2  112.3 162.5 112.3 212.8  71.0

“-r” is “report mode, “-c 2” twee iteraties.

 

 

 

 


@hmmsjan_2

traceroute to 76.76.21.22 (76.76.21.22), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.366 ms  0.379 ms  0.365 ms
 2  static.kpn.net (195.190.228.102)  3.611 ms  3.514 ms  3.503 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  76.76.21.22 (76.76.21.22)  3.545 ms  3.534 ms  3.524 ms

@ikheetjeff ik kan geen van de aangegeven websites bereiken


@JohanRobotics, Krijg je dan ook een ander resultaat bij  "traceroute -I 76.76.21.21"?


@ikheetjeff ik kan geen van de aangegeven website bereiken

@JohanRobotics Samengevat: UDP komt niet aan, ICMP wel. Je hebt dus een TCP/UDP block op server 76.76.21.22. robot-maatje.com heeft hier zelf niks mee te maken (behalve eigen server nemen), het ligt tussen Vercel/Amazon in + en/of KPN.

Ik heb dit gevonden

Lijkt er toch op dat je weer bij KPN mag aankloppen. Misschien kan Abuse hier iets mee? Ik weet niet of dit tot hun takenpakket hoort/ze specifieke IPs (tijdelijk) blokkeren. En anders ergens een ticket laten escaleren? (moderator?) Je hebt genoeg argumenten om bij KPN aan te kloppen vind ik.

Het desbetreffende Vercel IP staat ook op deze blocklist. En vrij recent:

 

Werkt IP 76.76.21.142 wel? Vercel heeft nu een tweede IP sinds 17 juni. Je zou eventueel robot-maatje.com kunnen vragen het naar dat IP te wijzigen?

Je zou eventueel ook hier laten weten zodat ze het kunnen heropenen => https://github.com/reactjs/react.dev/issues/6732

Een ding is zeker, dit IP is vaker de klos.


@ikheetjeff, Als het IP adres 76.76.21.21 op een blocklist zou staan die door KPN gebruikt wordt, dan zou je verwachten dat geen enkele KPN abonnee de sites op dat IP adres zou kunnen benaderen maar dat is dus niet het geval.


@ikheetjeff, Als het IP adres 76.76.21.21 op een blocklist zou staan die door KPN gebruikt wordt, dan zou je verwachten dat geen enkele KPN abonnee de sites op dat IP adres zou kunnen benaderen maar dat is dus niet het geval.

Dat zou je denken ja, maar dingen zijn soms minder logisch dan je zou denken ;-)

Vercel wijst met veel vertrouwen naar de ISP, en dat blijkt vaak de issue te zijn, dus geen gekke mogelijke oorzaak om te overwegen.


Reageer