Hallo,
Ik hoop dat er iemand is die ons zou kunnnen helpen, wat tot nu toe nog door niemand is gelukt.
Wij hebben internet via T-mobile glasvezel en een website bij mijndomein.nl.
Sinds een paar weken kunnen wij ineens niet meer op de site om te kijken of bewerken.
Volgens T-mobile is de verbinding in orde, kunnen zij gewoon naar de website.
Natuurlijk hebben zij wel gekeken vanaf een ander internet IP-adres, andere tussenstations, routers en glasvezel en niet via onze verbinding.
Mijndomein.nl hebben ook gekeken naar hun zijde en zei kunnen ook op de site en doen zij niet aan blokkades.
Mijn netwerk hier in huis bedraagt meerdere computers, PS3's, een NAS, wifi printer, 7 telefoons via wifi, de T-mobile gateway/router, een switch en nog 3 routers die dienst doen als doen als switches en access points en als laatste nog een eigen DNS server.
Het volgende heb ik zelf geprobeerd.
De glasmodem/router terug naar fabrieksinstellingen. 2x
Computers direct op de gateway.
Met en zonder DNS-server.
Standaard dns adressen, alternatieve.
Statische en dynamische IP-adressen.
Diverse componenten afgekoppeld van het netwerk.
Alle mogelijke combinaties die mogelijk zijn met bovenstaaande geprobeerd en het haalt niets uit.
Het adres is in iedere DNS server combinatie, altijd netjes omgezet naar een IP-adres en werkt dus gewoon zonder problemen.
Mijn netwerk loskoppelen van de gateway en 1 computer via wifi, koppelen met de hotspot van mijn telefoon, resulteert in toegang tot de website.
Wanneer ik die hotspotverbinding via die ene computer deel met de rest van het netwerk, hebben alle computers en telefoons wel toegang tot de website.
Iedere verbinding buiten dit huis (bij familie, notebook van de zaak met eigen dongel, zakelijke vpn verbinding, mobiel internet op de telefoon) werkt gewoon.
Zodra ik de notebook van de zaak verbind met mijn netwerk via wifi en de VPN verbinding heb opgebouwd, is er geen verbinding met de website mogelijk.
De website is een wordpress website, met een paar plugins en verders niets bijzonders.
De plugins zijn uitgeschakeld geweest en heeft geen effect gehad.
Er zijn geen blokkades terug te vinden in de website.
Om de gehele website uit te sluiten, is de index.php hernoemd naar index. Dus zonder extensie.
Dit zorgde ervoor dat de wordpress site niet meer bereikbaar was. Logisch toch?
In plaats daarvan heb ik een index.html geplaatst, wat alleen maar een stukje tekst gaf in een browser.
Ook dit ene bestandje was niet bereikbaar.
Het is dus onmogelijk om via onze internet verbinding thuis, verbinding te maken met onze website.
Sterker nog, alle websites op de webserver van mijndomein met ip-adres 34.240.160.162, zijn voor ons niet bereikbaar.
Het ip-adres reageert ook niet op ping verzoeken.
En ik heb momenteel geen idee, wat ik nog kan doen om erachter te komen waar het probleem zit.
Bladzijde 1 / 1
Hallo @FamSlui ,
Om je beter te kunnen helpen wil ik je verzoeken om een Trace route uit te voeren vanaf je thuis locatie.
Dit doe je door CMD te openen en het volgende commando in te voeren.
raceroute 34.240.160.162
Hiermee kunnen we even kijken waar het precies mis gaat en zo de juiste mensen aan te sturen.
Om je beter te kunnen helpen wil ik je verzoeken om een Trace route uit te voeren vanaf je thuis locatie.
Dit doe je door CMD te openen en het volgende commando in te voeren.
raceroute 34.240.160.162
Hiermee kunnen we even kijken waar het precies mis gaat en zo de juiste mensen aan te sturen.
Hallo Hidden.nld
Hier is het resultaat.
Zie volgende post. Het ging fout met plakken en opslaan.
Hier is het resultaat.
Zie volgende post. Het ging fout met plakken en opslaan.
Traceren van de route naar klusmontagebedrijftikkie.nl [34.240.160.162]
via maximaal 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 2 ms 1 ms 1 ms 1-0-201-31.ftth.glasoperator.nl [31.201.0.1]
3 4 ms 4 ms 4 ms 10.10.80.149
4 5 ms 8 ms 6 ms amsix01-ams1.amazon.com [80.249.210.100]
5 13 ms 10 ms 13 ms 52.93.0.118
6 4 ms 4 ms 5 ms 52.93.0.123
7 21 ms 20 ms 34 ms 54.239.42.202
8 19 ms 19 ms 19 ms 52.93.128.95
9 19 ms 19 ms 19 ms 54.239.44.146
10 * * * Time-out bij opdracht.
11 38 ms 21 ms 22 ms 52.93.6.140
12 20 ms 20 ms 20 ms 52.93.101.55
13 21 ms 20 ms 20 ms 52.93.101.38
14 19 ms 19 ms 19 ms 52.93.7.57
15 * * * Time-out bij opdracht.
via maximaal 30 hops:
1 1 ms 1 ms 1 ms 192.168.1.1
2 2 ms 1 ms 1 ms 1-0-201-31.ftth.glasoperator.nl [31.201.0.1]
3 4 ms 4 ms 4 ms 10.10.80.149
4 5 ms 8 ms 6 ms amsix01-ams1.amazon.com [80.249.210.100]
5 13 ms 10 ms 13 ms 52.93.0.118
6 4 ms 4 ms 5 ms 52.93.0.123
7 21 ms 20 ms 34 ms 54.239.42.202
8 19 ms 19 ms 19 ms 52.93.128.95
9 19 ms 19 ms 19 ms 54.239.44.146
10 * * * Time-out bij opdracht.
11 38 ms 21 ms 22 ms 52.93.6.140
12 20 ms 20 ms 20 ms 52.93.101.55
13 21 ms 20 ms 20 ms 52.93.101.38
14 19 ms 19 ms 19 ms 52.93.7.57
15 * * * Time-out bij opdracht.
Het is de laatste tijd wel een stortvloed aan problemen over bereikbaarheid van websites binnen het T-Mobile netwerk vanaf bepaalde random IP's.
Lijkt op een trend die ze snel moeten doorbreken en zeker serieus moeten nemen.
Het tref steeds meer klanten ... en veelal na onderhoud en IP changes.
Note: Veel servers schakelen ICMP responces uit voor security, daardoor is het ook steeds moeilijker om een goede ICMP of traceroute te doen.
Wel merkwaardig dat je ook met een VPN actief op je notebook nog niet bij de betreffende site kan. Normaliter is dit de workaround, want met een VPN actief wordt dan de website door jouw benaderd vanuit het IP adres van de VPN provider en die zorgen er wel voor dat ze hun routing/peering op orde hebben.
Het kan zijn dat de VPN software en/of jouw notebook met een dubbele gateway werkt, dus alleen maar het IP verkeer m.b.t. je werk / de zaak door de VPN leidt en de rest nog gewoon direct via de TMT infrastuctuur. Of een dual-stack issue (IPv4 en IPv6 zijn ook onafhankelijke kanalen). Dus al het verkeer via werk leiden of een andere VPN implementatie of configuratie gebruiken of andere internet provider nemen.
Ondertussen kan marketing van T-Mobile erover nadenken om 2 varianten internetters te definieren: 'budgetters' en 'hosters'. De eerste groep (ook wel de massa) mag dan goedkoper, krijgt direct een 10.0.0.0/8 adres zoals ook voor mobieltjes en kan dus niet portforwarden (handmatig of via UPnP).
Hoe de vpn van de zaak is ingesteld, is mij niet helemaal duidelijk. Ik heb dit keer niet de tijd genomen om dit uit te pluizen. Is iets wat ik nog wel wil doen, want ik wil die vpn ook op mijn mobiel.
Naar mijn weten werkt de vpn van de zaak met IPv4. En intern in mijn netwerk wordt IPv6 niet gebruikt en bij t-mobile heb ik ook alleen een IPv4 adres en geen IPv6 adres.
Ik heb ook nog dat mijn snelheid op mijn adres niet gehaald wordt. Max 500MBit ipv 750.
Volgens T-mobile kan dat aan apparatuur in het veld liggen, welke dan zou moeten worden vervangen.
Dan vraag ik mij ook af, kan het niet zijn dat apparatuur in het veld dit kunnen veroorzaken?
De opmerking van 500 vs. 750 zet ook aan het denken. 750Mbps zou op TMO eigen glasvezel moeten zijn (ODF) want via KPN WBA levert ook TMO max 500Mbps. Dus kan ook nog zijn dat je contractueel ODF '750' hebt maar in werkelijkheid WBA '500'. En dat deze discrepantie er mede toe bijdraagt tot de ervaren problemen.
In Windows zou je met commando
ipconfig /all
kunnen zien of je verkeer via 2 kanalen gaat of zou kunnen gaan als de VPN actief is. Hoe er dat precies uitziet weet ik zo niet, maar je zou 2 default gateways kunnen zien met verschillende metric.
In Windows zou je met commando
ipconfig /all
kunnen zien of je verkeer via 2 kanalen gaat of zou kunnen gaan als de VPN actief is. Hoe er dat precies uitziet weet ik zo niet, maar je zou 2 default gateways kunnen zien met verschillende metric.
Dat is een goede en aan t-mobile om dat te controleren. Ik weet niet beter dan dat wij op de t-mobile netwerk zitten en niet kpn. Dat was namelijk ook de reden dat wij t-mobile hebben genomen, omdat wij zover mogelijk niets met kpn te maken willen hebben.
Voor wat betreft VPN wil ik er niet verder op ingaan.
Het is geen desinteresse of iets dergelijks, maar het moet gewoon werken zonder omwegen, zoals het altijd heeft gedaan. De VPN was enkel een middel om te testen/proberen. Ook al zitten hier ook voorwaarden aan, maar uit ervaringen in het verleden kreeg ik het vermoeden dat al het internet via de vpn ging, maar helaas is vpn iets wat nog wel eens wilt wijzigen bij de ict afdeling.
Voor wat betreft VPN wil ik er niet verder op ingaan.
Het is geen desinteresse of iets dergelijks, maar het moet gewoon werken zonder omwegen, zoals het altijd heeft gedaan. De VPN was enkel een middel om te testen/proberen. Ook al zitten hier ook voorwaarden aan, maar uit ervaringen in het verleden kreeg ik het vermoeden dat al het internet via de vpn ging, maar helaas is vpn iets wat nog wel eens wilt wijzigen bij de ict afdeling.
Hallo @FamSlui ,
De trace laat zien dat het verkeer gewoon overgaat naar AWS EC2.
Het gaat in Amsterdam het Netwerk in van AWS en moet in Dublin uit komen waar de server staat, echter lijkt het daar niet aan te komen. stuur deze trace naar je Hoster en vraag of hij een trace naar jou ip kan uitvoeren. wellicht komen we dan weer een stapje dichterbij de oplossing.
@Pieter_B
Elke dag komen er routing fouten voor waardoor sommige delen onbeschikbaar worden.
Er was laatst nog een provider in geloof Nigeria die het voor elkaar kreeg om google plat te leggen door een fout in de BGP sessie.
@tmoesel het 10.10 adres word gebruikt op de AMS-IX en is inderdaad een niet routeerbaar adres. echter mag dit geen problemen geven. dit gebeurt veel vaker op de AMS-IX
De trace laat zien dat het verkeer gewoon overgaat naar AWS EC2.
Het gaat in Amsterdam het Netwerk in van AWS en moet in Dublin uit komen waar de server staat, echter lijkt het daar niet aan te komen. stuur deze trace naar je Hoster en vraag of hij een trace naar jou ip kan uitvoeren. wellicht komen we dan weer een stapje dichterbij de oplossing.
Elke dag komen er routing fouten voor waardoor sommige delen onbeschikbaar worden.
Er was laatst nog een provider in geloof Nigeria die het voor elkaar kreeg om google plat te leggen door een fout in de BGP sessie.
Dit suggereert of het toeval is, willekeurig en geen strategie of beleid of iets gedocumenteerd waarvan je op aan kan. Hop 2 in de trace is TMT, daarna hop 3 is 10.x.x.x. Dat is dus de eerste directe link van de klant's WAN IP met AMS-IX. 'gebeurt wel vaker' is m.i. gewoon de 'far-end kant' van de TMT/klant verbinding en is derhalve onderdeel van configuratie van TMT.
Voor de klant werken outbound connecties gewoon (in deze forumpost echter dus niet), dat is al jaren gebruikelijk op IPv4 in mobiele domein met CGNAT. Maar andersom, dus inbound connecties, wat in deze post niet aan de orde is maar voor andere meldingen op dit forum wel, is mij onduidelijk hoe dit grootschalig en flexibel zou moeten werken. Als je kan aangeven op wat voor IETF standaard o.i.d. dit gebaseerd is zou helpen. De klant zit simpelweg achter dubbel NAT zonder te weten (als ie geen trace had uitgevoerd).
Hi FamSlui, top dat je zelf al zo veel geprobeerd hebt! Ik heb dit issue voorgelegd aan onze netwerkspecialisten maar de trace lijkt zonder problemen ons netwerk uit te komen en stopt in het netwerk van Amazon. Dit ligt letterlijk buiten ons domein en kunnen wij daarom niet verhelpen. Dat je problemen ook ondervind met het gebruik van een VPN lijkt dit te ondersteunen, als er als iets mis zou gaan in ons domein dan zou een VPN dit kunnen verhelpen.
@Pieter_B Recent hebben we inderdaad veel meldingen binnen gekregen, dit bleek een issue aan onze kant en hebben we gelukkig snel kunnen verhelpen. Dat ging om dit topic. Vorige week hebben we weer drie meldingen binnen gekregen (waaronder deze). Op het oog lijken dit vergelijkbare problemen maar de ze zijn in dit geval uiteenlopend en hebben (tenminste voor zover we nu kunnen zien) niet dezelfde oorzaak.
@Pieter_B Recent hebben we inderdaad veel meldingen binnen gekregen, dit bleek een issue aan onze kant en hebben we gelukkig snel kunnen verhelpen. Dat ging om dit topic. Vorige week hebben we weer drie meldingen binnen gekregen (waaronder deze). Op het oog lijken dit vergelijkbare problemen maar de ze zijn in dit geval uiteenlopend en hebben (tenminste voor zover we nu kunnen zien) niet dezelfde oorzaak.
Hallo @Brian ,
Bedankt voor de reactie en dat je het ook bij jullie netwerkspecialisten hebt neergelegd.
Het lijkt er steeds meer op dat het probleem bij Amazon zou liggen.
Maar wij hebben helaas nog geen bericht terug gehad van de hoster, met een traceroute of andere informatie.
Dus er is ook nog geen uitsluitsel voor ons.
Maar wij zijn nu al even bezig met dit probleem en na alles zelf geprobeerd te hebben voor een oplossing of om uit te sluiten, wist ik het niet meer.
Alle hulp is welkom en omdat via TMT de website niet bereikbaar is maar wel via het mobiele netwerk van T-mobile, leek het logisch om op dit forum de vraag te stellen.
Op dit forum zijn er namelijk mensen, die beter zijn in netwerken dan ik.
Bedankt voor de reactie en dat je het ook bij jullie netwerkspecialisten hebt neergelegd.
Het lijkt er steeds meer op dat het probleem bij Amazon zou liggen.
Maar wij hebben helaas nog geen bericht terug gehad van de hoster, met een traceroute of andere informatie.
Dus er is ook nog geen uitsluitsel voor ons.
Maar wij zijn nu al even bezig met dit probleem en na alles zelf geprobeerd te hebben voor een oplossing of om uit te sluiten, wist ik het niet meer.
Alle hulp is welkom en omdat via TMT de website niet bereikbaar is maar wel via het mobiele netwerk van T-mobile, leek het logisch om op dit forum de vraag te stellen.
Op dit forum zijn er namelijk mensen, die beter zijn in netwerken dan ik.
Hi FamSlui, dat laatste geldt ook zeker voor mij 😉 We proberen altijd zo goed mogelijk mee te denken maar op een bepaald punt houd onze kennis en kunde (en invloed) op. Ik denk dat het nu even wachten is op een bericht van de hoster of zij iets hebben kunnen achterhalen. Laat zeker nog even weten wat er uit is gekomen en mochten we toch nog iets kunnen doen aan deze kant dan hoor ik het graag!
Iedereen bedankt voor het meedenken.
Het is opgelost.
Uiteindelijk blijkt dat de hoster die niet aan blokkeren van ip-adressen doet, ons ip-adres had geblokkeerd.
Het is opgelost.
Uiteindelijk blijkt dat de hoster die niet aan blokkeren van ip-adressen doet, ons ip-adres had geblokkeerd.
Heeft de hoster excuses aangeboden?
Als men dit:
https://community.t-mobile.nl/storingen-netwerk-347/website-op-poort-8069-onbereikbaar-304112?postid=1456847
vergelijkt met dit:
https://community.t-mobile.nl/t-mobile-thuis-internet-492/websites-niet-bereikbaar-307169?postid=1474401
is het maar de vraag van wie excuses op zijn plaats zijn. Als een server service of infrastuctuur van de hoster zonder menselijk ingrijpen besluit dat de route vanaf de klant niet in de haak is, is het eerder aan degene die de route verzorgt.
Ik zeg niet dat er een automatisch systeem is wat een soort van backtraceroute doet b.v. als veiligheidscheck, maar als het wel het geval is, dan valt de praktijk van privaat adres in het midden van een route over publiek adresbereik denk ik als eerste door de mand.
https://community.t-mobile.nl/storingen-netwerk-347/website-op-poort-8069-onbereikbaar-304112?postid=1456847
vergelijkt met dit:
https://community.t-mobile.nl/t-mobile-thuis-internet-492/websites-niet-bereikbaar-307169?postid=1474401
is het maar de vraag van wie excuses op zijn plaats zijn. Als een server service of infrastuctuur van de hoster zonder menselijk ingrijpen besluit dat de route vanaf de klant niet in de haak is, is het eerder aan degene die de route verzorgt.
Ik zeg niet dat er een automatisch systeem is wat een soort van backtraceroute doet b.v. als veiligheidscheck, maar als het wel het geval is, dan valt de praktijk van privaat adres in het midden van een route over publiek adresbereik denk ik als eerste door de mand.
Hi FamSlui, goed om te horen dat ze er achter zijn en het op hebben kunnen lossen!
Reageer
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.