Sinds enige tijd kan ik vanaf mijn interne netwerk niet meer naar tesla.com. Ik krijg de volgende melding:
Access Denied
You don’t have permission to access “http://www.tesla.com/” on this server.
Dit geldt overigens ook voor alle subdomeinen van Tesla, dus bijvoorbeeld ook auth.tesla.com (nodig om te verbinden met mijn auto). Het maakt niet uit met welk apparaat ik het probeer, bij alle krijg ik deze melding. Gebruik ik 4G of VPN, dan is er geen probleem. In eerste instantie dacht ik dat Tesla mijn IP adres om wat voor reden dan ook geblokt heeft. Maar ook als ik op de router (Draytek Vigor 2927) een route-policy activeer waarbij het uitgaande verkeer over hetzelfde WAN, maar via ander IP adres gestuurd wordt (freedom subnet), dan werkt het ook niet. Ook de DNS servers aanpassen op de router voor LAN1levert niks op.
Mijn vragen aan jullie:
Kan het zijn dat Tesla mij toch blokt, ook al gebruik ik een nog nooit gebruikt uitgaand IP adres uit mijn subnet? Maw kan men via mijn subnet-IP een relatie leggen met mijn eigen IP? Als dat zo is moet ik waarschijnlijk bij Tesla zijn
Kan het zijn dat Freedom het verkeer naar tesla voor mijn aansluiting blokt? En zoja, waarom?
Zijn er andere wegen die ik kan bewandelen om de oorzaak te vinden of beter nog, om dit op te lossen?
traceroute www.tesla.com
traceroute to www.tesla.com (104.126.124.83), 30 hops max, 60 byte packets
1 xxxx.xxxx.xxxx.xxxx (xx.xx.x.x) 1.169 ms 1.449 ms 1.756 ms
2 xxx.xxx.xxxx.connected.by.freedominter.net (185.93.xxx.xxx) 23.671 ms 23.762 ms 23.878 ms
3 ae5.core1.fi001.nl.freedomnet.nl (185.93.175.215) 26.443 ms 26.556 ms 26.680 ms
4 amsix-ams8.netarch.akamai.com (80.249.209.208) 104.107 ms 104.158 ms 104.221 ms
5 192.168.224.29 (192.168.224.29) 26.752 ms 26.878 ms 26.985 ms
6 192.168.231.7 (192.168.231.7) 27.106 ms 192.168.237.3 (192.168.237.3) 25.642 ms 192.168.234.5 (192.168.234.5) 25.698 ms
7 192.168.242.159 (192.168.242.159) 25.811 ms 3.278 ms 11.426 ms
8 a104-126-124-83.deploy.static.akamaitechnologies.com (104.126.124.83) 11.455 ms 11.444 ms 11.445 ms
en check of je dns (thuis) op orde is en je niet per ongeluk naar een ander resolver ip gaat die het anders resolved.
Weet dat sommige uitgegeven IP blokken wel eens geblokt worden omdat ze eerst eigendom waren van een ander land of bedrijf.
Kijk eens waar je IP adres van Freedom op geregistreerd staat.
traceroute to e1792.dscx.akamaiedge.net (23.222.32.231), 64 hops max, 52 byte packets
1 192.168.x.x (192.168.x.x) 15.659 ms 6.429 ms 2.651 ms
2 xxx.xx.xxx.connected.by.freedominter.net (185.93.xxx.xxx) 6.049 ms 8.600 ms 21.247 ms
3 connected.by.freedom.nl (185.93.175.240) 7.781 ms 10.463 ms 18.570 ms
4 et-0-0-1-1000.core1.fi001.nl.freedomnet.nl (185.93.175.218) 11.789 ms 19.185 ms 6.707 ms
5 amsix-ams9.netarch.akamai.com (80.249.208.168) 16.826 ms 13.898 ms 13.400 ms
6 a23-222-32-231.deploy.static.akamaitechnologies.com (23.222.32.231) 19.235 ms 13.284 ms 19.595 ms
DNS:
cat /etc/resolv.conf
#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
# scutil --dns
#
# SEE ALSO
# dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
nameserver 8.8.8.8
nameserver 8.8.4.4
Handige link! Dank, er lijkt echter geen probleem…
The IP Address 45.80.xxx.x did not receive a bad risk score. (mijn freedom ip)
The IP Address 45.80.xxx.x did not receive a bad risk score. (subnet ip)
Dan zal je toch naar Tesla support zelf moeten omdat het er op lijkt dat je op de server (of het voor/portaal) wordt geblokkeerd. Je zult niet de eerste zijn die ergens vanwege achterstallig onderhoud, de deur wordt gewezen.
Check voor de zekerheid ook nog even je ad/blockers/ghosteries van je browser. Mogelijk dat je met een andere browser of op de commandline er wel doorheen komt bv curl https://www.tesla.com ; wanneer je dan een zooi html terugkrijgt, weet je genoeg. Bij blokkeren, check ook of er onderwater misschien wat meer in de geretourneerde inhoud zit.
Ik zou dan graag weten op basis van welke informatie van mijn netwerk ze de blokkade toepassen - dan wel wat ik voor informatie aan ze moet verschaffen. Het IP nummer is niet voldoende, want ook met een ander IP werkt het niet.
Ik heb net een telefoon gebruikt die nog nooit via mijn lan op het internet is geweest, zelfde melding. Ik heb het MAC adres van de router aangepast, maakt ook niets uit.
Ik heb ook al zitten pluizen in het retourverkeer, niets gevonden.
Ik krijg dezelfde melding op zowel een HTTP als HTTPS. aanvraag:
Access Denied
You don’t have permission to access “http://www.tesla.com/ ” on this server.
Heb je de mogelijkheid om het met een andere browser te proberen? Ik kan het probleem niet reproduceren, bij mij kan ik gewoon naar die website. Heb je al geprobeerd je router opnieuw op te starten?
Welk ander IP ? waarbij ik vermoed dat het IP niet terzake doet.
Is dat andere IP in/van jouw omgeving/bedrijf of totaal ergens anders gelocaliseerd, mijn part via hotspot van MacDo.
En nogmaals: gebruik https://… en maak desnoods je cookie/cache compleet leeg of gebruik privacy-browsing omdat het anders wel’s kan terugvallen op oude protocollen. Indien je weet/kunt Wiresharken, kan dat vaak ook wat inzicht geven.
Paar opmerkingen:
MAC adres, hoewel het een wereldwijd uniek adres zou moeten zijn (ideeën uit 1977, toen er ook zeker geen plek was voor meer dan een 10000 computers…) , is het dat beslist niet. Er zijn vele duplicaten alleen merkt vrijwel niemand dat omdat de adapter verschillende kanten opgestuurd worden. MAC adressen worden gebruikt door Bluetooth, Ethernet, TokenRing, en anderen. MAC adressen zijn ook niet onveranderbaar, alle adapters kunnen aangepast worden. ELKE ethernet interface heeft een uniek adres…
Een MAC adres wordt niet buiten het “broadcast” domain (AKA LAN) waarop de ethernet poort is aangesloten gebruikt.
een MAC adres is dus geldig tot de volgende router. MAC adres aanpassen zal geen invloed hebben op www.tesla.com
Als je “curl https://www.tesla.com -L -v” gebruikt dan zou je een 401 / 403 moeten krijgen de evt. redirects worden door -L opgelost, maar zijn mogelijk wel zichtbaar.
Als het eerste contact al mis is dan doet de andere kant mogelijk aan “IP-reputation”… dat was een aardig idee als het ook zou kunnen werken… IP-reputation verklaart in hoeverre een adres behoort tot: een Datacenter, een VPN farm, een SPAM outfit, … Dialup set etc. hoort. Probleem is dat adressen niet meer eenmalig uitgedeeld worden (zoals to een jaar of 10 geleden), maar hergebruikt, geleend, verhuurd, verkocht worden. waardoor een adres dat 5 jaar geleden bij een spam-outfit in verweggistan hoorde, daarna in een DC is gebruikt voor VPN’s, en vervolgens nu verhuurd is aan een ISP oid.
Met een beetje pech houdt de IP-repuatie dienst de eigenaar (verhuur bedrijf) bij en niet de werkelijke gebruiker… Met een beetje meer pech is de DB van de reputatie dienst niet up to date, met nog een beetje meer pech is de database bij de filter provider een beetje out of date…
(vaak is het geinstaleerd en is er daarna (jaren) nooit meer naar gekeken…, een update van de database zou wonderen kunnen opleveren).
Je kunt het probleem vermoedelijk alleen oplossen door contact op te nemen met Tesla, en uit zien te vinden waarom je er niet bij kan, hopelijk kun je de betrokken IP reputatie provider boven water krijgen. Dan kun je of zelf of mogelijk via freedom zaken recht gezet krijgen.
tls v 1.2 is niet het probleem: (tls v1.1 wordt (terecht) niet geaccepteerd).
Het is niet de load balancer/reverse proxy die weigert (het proces dat de SSL verbinding maakt).
Maar een achterliggende server, je hebt meer info nodig van tesla zelf.