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.

@AriënC  “Ik blijf erbij dat het probleem bij de serverbeheerder zit.”

Ik heb een aantal van de websites die op dezelfde host staan geprobeerd en er is er niet een te bereiken via mijn glasvezel verbinding. Het probleem zit dus niet bij de websites zelf maar een stapje daar voor. Het zit ook niet bij auth0 want de andere websites maken daar geen gebruik van. Voor mij blijft er niet anders over dan een probleem bij KPN in combinatie met AWS/Vercel


Dat stapje 'voor' die websites is dus de serverbeheerder, die beheert de server waarop al die websites staan. Andere mensen (waaronder KPN-klanten) hebben hier al aangegeven dat ze wel de server kunnen bereiken.


@AriënC  Ja en dat is dus een probleem die serverbeheerder is het grote AWS van Amazon welke ook aangeven dat mijn IP adres niet is geblokkeerd. Ik denk dat ik alle mogelijke wegen wel hebt gehad om het probleem opgelost te krijgen maar blijkbaar is er niemand die mij verder kan helpen. Er is blijkbaar maar één oplossing en dat is van provider wisselen zodat ik een ander IP adres krijg.


Dat stapje 'voor' die websites is dus de serverbeheerder, die beheert de server waarop al die websites staan. Andere mensen (waaronder KPN-klanten) hebben hier al aangegeven dat ze wel de server kunnen bereiken.

Ik denk niet dat dit issue bij de "serverbeheerder" ligt immers dan zou je verwachten dat niemand die sites zou kunnen benaderen. Mijn vermoeden is dat het een routeringsissue betreft en die zou zelfs al op een node binnen KPN kunnen liggen. Dat is, naast een IP (subnet) blokkade eigenlijk de enige mogelijkheid waardoor een gedeelte van de KPN abonnees die site gewoon goed kan benaderen en een andere gedeelte niet.


Ik lees dat er al een boel geprobeerd en uitgezocht is, maar 't nog niet anders is. Ik zal er ook eens in duiken om te kijken wat ik aan deze kant kan doen @JohanRobotics. Je hebt je profiel al ingevuld zag ik, top. Mocht je nog andere handige toevoegingen of informatie hebben, dan kan je die in je forumprofiel bij ‘persoonlijke opmerkingen’ kwijt.


Ik vind het vreemd dat niemand mij kan zeggen bij welke stap de verbinding stopt.

Het blijft lastig dat traceroute geen info meer geeft. Begrijpelijk als misbruik gemaakt wordt van router antwoorden, maar lastig. Ik weet niet wat de profs als gereedschap hebben, maar die kunnen in ieder geval een collega aan de overkant bellen… Ik heb nog wel op de site van mijn IPv6 tunnel provider gekeken, he.net, zij hebben BGP tools op de website. BGP legt paden tussen “autonomous systems”, bestaande uit een groot aantal IP(v6) blokken. KPN is AS1136. Je kunt er ook traceroute, ping en DNS uitvoeren met behulp van “probes”. Nooit van gehoord, ze zijn van globalping of ripe, kunnen thuis of in een datacentrum aan het net geknoopt worden en je kunt dus via he’s site een traceroute/ping/dns opdracht geven  vanuit zo’n kastje.  Er staat een hele lijst probes onder as1136 vanuit diverse locaties, enkele zijn gemarkeerd als slecht. Dan is natuurlijk weer het probleem: zit er op die locatie bij KPN een kink in de kabel of werkt het kastje niet goed. In ieder geval: veel kunnen 76.76.21.21 bereiken, ik ben alleen 195.190.228.102 als tweede stap niet tegengekomen.

Dus: vanuit veel plaatsen is 76.76.21.21 via KPN bereikbaar, maar een post op dit forum leverde dezelfde informatie.

 


@Alexandra van KPN  Ik heb alle traceroutes en ping resultaten naar de Host Vercel gestuurd en kreeg onderstaand antwoord.

Thank you for the detailed information; this is incredibly helpful. After discussing with our engineering team and reviewing the traceroute results provided, we’ve identified that all traffic is being halted at the ISP IP 195.190.228.102 (KPN) level. This indicates that there are no blockages on our end as it never actually makes it.

We’ve also analyzed the ASN trace and confirmed that KPN is successfully reaching Vercel across our user base. Given that the issue seems to be affecting the user’s internet connection broadly, rather than being isolated to Vercel, we recommend that the user contact their ISP to investigate further. It’s possible that a security concern, such as unauthorized access to their network, might have triggered the ISP to restrict access.

 


Thank you for the detailed information; this is incredibly helpful. After discussing with our engineering team and reviewing the traceroute results provided, we’ve identified that all traffic is being halted at the ISP IP 195.190.228.102 (KPN) level. This indicates that there are no blockages on our end as it never actually makes it.

We’ve also analyzed the ASN trace and confirmed that KPN is successfully reaching Vercel across our user base. Given that the issue seems to be affecting the user’s internet connection broadly, rather than being isolated to Vercel, we recommend that the user contact their ISP to investigate further. It’s possible that a security concern, such as unauthorized access to their network, might have triggered the ISP to restrict access.

Ik vind dit persoonlijke behoorlijk nietszeggend antwoord.

Hebben ze meer details gegeven of is dit het?

En wat voor een gedetailleerde informatie heb jij hen dan verstrekt?


@wjb  Onderstaand heb ik ze gestuurd.

├─────── STARTING

│ Domain to test: robot-maatje.com 
│ Timestamp (UTC): do  8 aug 2024  6:38:45 UTC
| Timestamp (Local): do  8 aug 2024  8:38:45 CEST
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── IP Information 

{
  "ip": "Mijn ip adres stond hier",
  "city": "Alkmaar",
  "region": "North Holland",
  "country": "NL",
  "loc": "52.6317,4.7486",
  "org": "AS1136 KPN B.V.",
  "postal": "1811",
  "timezone": "Europe/Amsterdam",
  "readme": "https://ipinfo.io/missingauth"
}
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.21 

PING 76.76.21.21 (76.76.21.21) 56(84) bytes of data.

--- 76.76.21.21 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3073ms


traceroute to 76.76.21.21 (76.76.21.21), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.372 ms  0.354 ms  0.443 ms
 2  static.kpn.net (195.190.228.102)  4.047 ms  3.845 ms  3.843 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.9 

PING 76.76.21.9 (76.76.21.9) 56(84) bytes of data.

--- 76.76.21.9 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3061ms


traceroute to 76.76.21.9 (76.76.21.9), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.303 ms  0.387 ms  0.384 ms
 2  static.kpn.net (195.190.228.102)  2.061 ms  2.403 ms  2.511 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 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=2.88 ms
64 bytes from 76.76.21.22: icmp_seq=2 ttl=250 time=2.75 ms
64 bytes from 76.76.21.22: icmp_seq=3 ttl=250 time=2.72 ms
64 bytes from 76.76.21.22: icmp_seq=4 ttl=250 time=2.68 ms

--- 76.76.21.22 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.678/2.757/2.884/0.077 ms
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.61 

PING 76.76.21.61 (76.76.21.61) 56(84) bytes of data.

--- 76.76.21.61 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3060ms


traceroute to 76.76.21.61 (76.76.21.61), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.346 ms  0.290 ms  0.385 ms
 2  static.kpn.net (195.190.228.102)  3.626 ms  3.624 ms  3.621 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.93 

PING 76.76.21.93 (76.76.21.93) 56(84) bytes of data.

--- 76.76.21.93 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3062ms


traceroute to 76.76.21.93 (76.76.21.93), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.378 ms  0.335 ms  0.449 ms
 2  static.kpn.net (195.190.228.102)  2.235 ms  2.496 ms  2.707 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.98 

PING 76.76.21.98 (76.76.21.98) 56(84) bytes of data.

--- 76.76.21.98 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3063ms


traceroute to 76.76.21.98 (76.76.21.98), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.304 ms  0.385 ms  0.383 ms
 2  static.kpn.net (195.190.228.102)  2.993 ms  2.991 ms  2.990 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.123 

PING 76.76.21.123 (76.76.21.123) 56(84) bytes of data.

--- 76.76.21.123 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3062ms


traceroute to 76.76.21.123 (76.76.21.123), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.318 ms  0.302 ms  0.405 ms
 2  static.kpn.net (195.190.228.102)  2.940 ms  2.938 ms  2.936 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.142 

PING 76.76.21.142 (76.76.21.142) 56(84) bytes of data.

--- 76.76.21.142 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3062ms


traceroute to 76.76.21.142 (76.76.21.142), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.333 ms  0.369 ms  0.366 ms
 2  static.kpn.net (195.190.228.102)  2.259 ms  2.903 ms  2.902 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.164 

PING 76.76.21.164 (76.76.21.164) 56(84) bytes of data.

--- 76.76.21.164 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3062ms


traceroute to 76.76.21.164 (76.76.21.164), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.309 ms  0.292 ms  0.391 ms
 2  static.kpn.net (195.190.228.102)  2.720 ms  2.718 ms  2.716 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Testing 76.76.21.241 

PING 76.76.21.241 (76.76.21.241) 56(84) bytes of data.

--- 76.76.21.241 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3062ms


traceroute to 76.76.21.241 (76.76.21.241), 30 hops max, 60 byte packets
 1  mijnmodem.kpn.home (192.168.2.254)  0.315 ms  0.298 ms  0.390 ms
 2  static.kpn.net (195.190.228.102)  2.743 ms  2.741 ms  2.740 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  * * *
└───────────────────────────────────────

┌───────────────────────────────────────
├─────── dig robot-maatje.com 


; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> robot-maatje.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40122
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;robot-maatje.com.        IN    A

;; ANSWER SECTION:
robot-maatje.com.    300    IN    A    76.76.21.21

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Aug 08 08:41:39 CEST 2024
;; MSG SIZE  rcvd: 61

└───────────────────────────────────────

┌───────────────────────────────────────
├─────── dig robot-maatje.com via 8.8.8.8


; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> robot-maatje.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30589
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;robot-maatje.com.        IN    A

;; ANSWER SECTION:
robot-maatje.com.    300    IN    A    76.76.21.21

;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Aug 08 08:41:39 CEST 2024
;; MSG SIZE  rcvd: 61

└───────────────────────────────────────

┌───────────────────────────────────────
├─────── dig robot-maatje.com via trace

;; communications error to 127.0.0.53#53: timed out

; <<>> DiG 9.18.28-0ubuntu0.20.04.1-Ubuntu <<>> robot-maatje.com +trace
;; global options: +cmd
.            87203    IN    NS    g.root-servers.net.
.            87203    IN    NS    e.root-servers.net.
.            87203    IN    NS    k.root-servers.net.
.            87203    IN    NS    d.root-servers.net.
.            87203    IN    NS    m.root-servers.net.
.            87203    IN    NS    f.root-servers.net.
.            87203    IN    NS    b.root-servers.net.
.            87203    IN    NS    a.root-servers.net.
.            87203    IN    NS    h.root-servers.net.
.            87203    IN    NS    j.root-servers.net.
.            87203    IN    NS    l.root-servers.net.
.            87203    IN    NS    c.root-servers.net.
.            87203    IN    NS    i.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 8 ms

com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            86400    IN    DS    19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A
com.            86400    IN    RRSIG    DS 8 1 86400 20240821050000 20240808040000 20038 . hOA0XysK6RFsF+h5sos6vLx8JYq3gDlFrt0u3GwdiPIpasAhxRxzINQr c+H3DD2uFkLhhnjYU6wsBWjtXBcm9RExx388X4VoTC9EmVW4PMPECptb uU9Qh4R2cshLAsmqZzfD81bzTa4wJOewe4Vqwq0URW6u9Ym5YDI4V5rt udtPqcY9SJaKXKawxzk/237MQtyvYzpENNvy7SgcPYPEo47CJqIvFZ3H XKdo01Zz67Sho4d7yygUkygndXjyZtnyRTedw6oYBI+k9S5eI00lcCVX 76tJjBbXIqGKetLhg8ruh57i5npbr6mUiAMSgQaqYMG0PSATaGEKBWT2 COiQ9Q==
;; Received 1176 bytes from 202.12.27.33#53(m.root-servers.net) in 12 ms

robot-maatje.com.    172800    IN    NS    darl.ns.cloudflare.com.
robot-maatje.com.    172800    IN    NS    journey.ns.cloudflare.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240812002450 20240804231450 59354 com. EurCNTF+cD8oOQ2Uy4AOieTidK0Psg9o6J2DdmEEoNQzvW0D7/T0lZA3 +sp60fqriK7ug4IhB5W8kJL8/JQcsQ==
CUTLQF99FH9LI40O2FMUVP5SP66L45JC.com. 86400 IN NSEC3 1 1 0 - CUTMEN7HFI9H2IPL5PG2KJ2516555INP NS DS RRSIG
CUTLQF99FH9LI40O2FMUVP5SP66L45JC.com. 86400 IN RRSIG NSEC3 13 2 86400 20240813015006 20240806004006 59354 com. 4KV8ZKosl3lJKaVK0o+wl+R24/rM5hihkT9uO1pfA/ZlXg8A7cVDIIOt cxM558PzUe0qYTMXh95NK8lPRs1gsw==
;; Received 721 bytes from 192.5.6.30#53(a.gtld-servers.net) in 12 ms

robot-maatje.com.    300    IN    A    76.76.21.21
;; Received 61 bytes from 108.162.194.3#53(journey.ns.cloudflare.com) in 4 ms

└───────────────────────────────────────

┌───────────────────────────────────────
├─────── Output of robot-maatje.com

*   Trying 76.76.21.21:443...
* TCP_NODELAY set
* connect to 76.76.21.21 port 443 failed: Verbinding is verlopen
* Failed to connect to robot-maatje.com port 443: Verbinding is verlopen
* Closing connection 0

└───────────────────────────────────────


┌───────────────────────────────────────
│ Time elapsed: 309 seconds

├─────── FINISHED
└───────────────────────────────────────


 


Ik kan op basis van die informatie niet stellig concluderen dat het al fout zou lopen op 195.190.228.102.

Het kan daar inderdaad fout lopen maar het hoeft niet zo te zijn. Zelf denk ik overigens wel dat de netwerkexperts van KPN hier naar moeten kijken, ook ik vermoed dat de oorzaak een foutieve routering is en dan ligt het voor de hand dat de 195.190.228.102 inderdaad de foutieve afslag neemt.


@wjb Het zou zeker mooi zijn als een netwerkexpert van KPN hier naar kan kijken.

Wat mij nog het meest verbaast dat dit zomaar zonder aanleiding plots mis kan gaan.

Ik heb op 26 juni de hele morgen via het platform gewerkt, toen een uur iets anders gedaan en vervolgens had ik ineens geen toegang meer.


Al die traceroutes zeggen dus helemaal niets. De enige conclusie is dat 195.190.228.102 de laatste server is die fatsoenlijk antwoord geeft. Linux traceroute zendt UDP probes, “traceroute -I” zendt ping probes, en 76.76.21.21 geeft daar antwoord op als 10e in de rij, 

“11  76.76.21.21 (76.76.21.21)  12.269 ms  12.358 ms  6.260 ms”.

11 vandaag….

Maar ik zie ook in je logs:

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=2.88 ms
64 bytes from 76.76.21.22: icmp_seq=2 ttl=250 time=2.75 ms
64 bytes from 76.76.21.22: icmp_seq=3 ttl=250 time=2.72 ms
64 bytes from 76.76.21.22: icmp_seq=4 ttl=250 time=2.68 ms

dus die doet het wel….

 

Al die servers binnen dat subnet met  “traceroute -I” vanuit hier, alleen laatste stap getoond. 

traceroute to 76.76.21.21 (76.76.21.21), 30 hops max, 60 byte packets
11  76.76.21.21 (76.76.21.21)  11.710 ms  11.814 ms  8.997 ms
traceroute to 76.76.21.9 (76.76.21.9), 30 hops max, 60 byte packets
11  76.76.21.9 (76.76.21.9)  6.490 ms  6.693 ms  3.599 ms
traceroute to 76.76.21.22 (76.76.21.22), 30 hops max, 60 byte packets
10  76.76.21.22 (76.76.21.22)  5.373 ms  9.092 ms  9.384 ms
traceroute to 76.76.21.61 (76.76.21.61), 30 hops max, 60 byte packets
11  76.76.21.61 (76.76.21.61)  13.264 ms  13.540 ms  11.135 ms
traceroute to 76.76.21.93 (76.76.21.93), 30 hops max, 60 byte packets
10  76.76.21.93 (76.76.21.93)  9.625 ms  6.928 ms  7.349 ms
traceroute to 76.76.21.98 (76.76.21.98), 30 hops max, 60 byte packets
11  76.76.21.98 (76.76.21.98)  13.797 ms  14.081 ms  9.146 ms
traceroute to 76.76.21.123 (76.76.21.123), 30 hops max, 60 byte packets
10  76.76.21.123 (76.76.21.123)  9.734 ms  9.984 ms  10.264 ms

traceroute to 76.76.21.164 (76.76.21.164), 30 hops max, 60 byte packets
10  76.76.21.164 (76.76.21.164)  14.754 ms  14.952 ms  15.137 ms
traceroute to 76.76.21.241 (76.76.21.241), 30 hops max, 60 byte packets
11  76.76.21.241 (76.76.21.241)  6.148 ms  6.356 ms  3.524 ms

 

Of die 76.76.21.22 nu incidenteel gewerkt heeft, geen idee.

 

Met de eerste twee cijfers van je externe IP zou ik nog even gerichter bij “he” kunnen kijken of er een probe via  195.190.228.102  loopt, als die hetzelfde gedrag vertoont wordt dat punt toch verdacht. 

 

 

 

 

 


@wjb Het zou zeker mooi zijn als een netwerkexpert van KPN hier naar kan kijken.

Wat mij nog het meest verbaast dat dit zomaar zonder aanleiding plots mis kan gaan.

Ik heb op 26 juni de hele morgen via het platform gewerkt, toen een uur iets anders gedaan en vervolgens had ik ineens geen toegang meer.

Ik heb navraag uit staan, om te kijken of we aan deze kant iets kunnen vinden. Zo gauw ik nieuws heb, laat ik heb je hier weten.


Even een dubbele check @JohanRobotics. Vergeef me als je het wel ergens gedeeld hebt, dan hoor ik het natuurlijk ook graag:

Heb je op dit moment IPV6 actief? En zo ja, kan je dit tijdelijk uitzetten en daarna opnieuw testen? Een van onze specialisten (en ik) zijn benieuwd naar je bevindingen, ik lees ze hier graag.


@Alexandra van KPN Zoals in een eerdere reactie al aangegeven heb ik IPV6 op het modem uitgezet en getest zonder resultaat, en ook heb ik nog een test gedaan door IPV6 in de browser uit te zetten. En ik heb nog getest om ipv6 in mijn netwerk settings van Linux uit te zetten. Dit alles bracht helaas geen oplossing.


Dank voor de bevestiging @JohanRobotics, ik koppel het terug aan de specialist en kom er bij je op terug als ik meer weet. 


Goedemorgen, onze specialisten hebben er verder naar gekeken en tests gedaan. Uit alle tests (vanuit KPN netwerk) komt dat het IP adres gewoon bereikbaar is. Dit is zowel getest via ping als via publieke tools zoals Ripe atlas. Oftewel, we kunnen in/vanuit het KPN netwerk geen problemen vinden. Het lijkt erop dat je op een firewall loopt binnen het Amazon netwerk. Ik had graag geholpen maar daar kunnen we niks aan doen vanuit onze kant. Ik hoop dat je toch alsnog verder komt via de hosting partij.


@Alexandra van KPN 

Het probleem heeft zeker wel met mijn KPN verbinding / ip adres  te maken. Ongetwijfeld ligt de oorzaak van de blokkade bij Amazon of andere partij maar het feit blijft dat het met mijn verbinding niet meer werkt. Het zou mooi zijn als er een mogelijkheid was om mijn vaste IP adres te wijzigen maar dat lijkt bij KPN niet mogelijk te zijn.

Waar in Nederland ik ook gebruik maak van het internet overal kan ik probleemloos ons platform bezoeken of het nu KPN, ZIGGO of een andere aanbieder is het maakt geen verschil alleen via mijn eigen KPN verbinding werkt het niet dus blijft er in mijn opinie alleen een IP blokkade over.


En omdat IP-adressen in het IPv4-segment schaars zijn, wisselt KPN geen IP-adressen. Je kan kijken of het met IPv6 beter gaat. 

 

Mijn advies: Druk blijven uitoefenen op je hosting dat ze hun Amazon settings nachecken. 


@AriënC volgens mij heeft wisselen van ipv6 weinig zin, zover als ik mij herinner word er bij ipv6 standaard steeds van adres gewisseld voor de verbinding.


Als je ipv4 op een blacklist staat, en jij dwingt ipv6 als gebruik (in de browser kan dat) en de tegenpartij ondersteunt ook ipv6, dan omzeil je de blocklist. Tenzij je ipv6 range ook geblokkeerd is. 😉


@AriënC  Vandaag even ipv4 totaal uitgeschakeld en een test gedaan maar dat geeft hetzelfde beeld.

Wat mij vandaag wel opviel was dat als ik een subdomein van de websites probeer te bereiken dan is er geen enkel probleem. Het verschil is dat de subdomeinen niet worden afgeschermd via Auth0. Dus ga ik nog maar een keer richting die partij mailen want ik krijg toch de indruk dat daar het probleem zit.


IPv4 uitschakelen zal niet helpen aangezien de server geen AAAA adres adverteert. Je zou dan eigenlijk verwachten dat zonder IPv4 de hele site niet meer gevonden wordt, maar als een site een IPv4 maar geen IPv6 record heeft mag DNS geen “NXDOMAIN” teruggeven en bestaat dus.

Maar wat zijn die “subdomeinen”?  Zitten die ook op dat 76.76.21.21 adres of komen die heel ergens anders terecht en is 76.76.21.21. alleen een portaal dat naar auth0 leidt? Zie de ontwikkelaars werkbalk. En die paginas komen toch niet uit de cache???

Overigens is toch overtuigend aangetoond met ping en met HTTPS via de ontwikkelaars werkbalk dat 76.76.21.21 niet bereikbaar is.


@hmmsjan_2  

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. Het enige verschil is dat deze MQTT server zijn eigen wachtwoorden systeem heeft en niet via Auth0 wordt afgehandeld. Het lijkt er dus sterk op dat het probleem bij Auth0 zit maar die partij lijkt moeilijk benaderbaar te zijn bij dit soort problemen.

 


Het is gewoon tegenstrijdig. Als de mqtt servers via 76.76.21.21 bereikbaar zijn, zou je zeggen dat de routing in orde is, en dat de vraag is welke trucs Amazon/Vercel/Auth0 uithalen om het adres tot op ping niveau te blokkeren, inclusief medegebruikers van dit adres, bijv. ricoh.ca.

Vercel heeft een test script op https://github.com/vercel-support/vercel-connect-debug, maar dat heeft u waarschijnlijk al gevonden. Een aantal pings naar verschillende relevante servers, en test of de server toegankelijk is, dus ik verwacht geen nieuwe informatie. Het laatste stukje is weg gecommentarieerd, maar roept voor de diverse IP’s “mtr” aan, een uitgebreide traceroute. Daar is te zien dat heel af en toe een andere afslag genomen wordt.

 

 

 


Reageer