Periode geen toegang tot afgesloten directories

Beste mensen,

Een lastig probleem dat ik reeds met meerdere experts heb besproken. Conclusie is op dit moment dat het ligt aan de Ziggo-verbinding.

Het probleem is als volgt:
Gedurende bepaalde periodes kan geen toegang worden verkregen tot directories die met htaccess / htpasswd zijn afgesloten.
Andere pagina's geven geen probleem.
Ligt niet aan browser-cache of tal van andere reeds aangedragen oplossingen.
Met Firefox krijg je de bekende melding "De verbinding werd geherinitialiseerd". Ook met andere browsers geen toegang.

Op het moment dat het probleem in Amersfoort ontstaat hebben collega's elders wel toegang en andersom.
Als het probleem mij bij zelf ontstaat op mijn Ziggo-netwerk kan ik wel met dezelfde PC / browser deze pagina's benaderen via mijn XS4all-netwerk dat ik ook heb liggen.

Heb het vermoeden dat het gaat om updates van Ziggo-modems die meteen na een dergelijke update geen verbinding kunnen maken met door htaccess afgesloten directory's maar na weer 'in balans komen' weer toegang bieden.
De vraag is nu wat er precies gebeurt met een dergelijke modem-update en wat de relatie zou kunnen zijn met het beschreven probleem.

Nogmaals het gaat alleen om de toegang tot met htaccess / htpasswd afgesloten pagina's.
Zonder verdere acties krijg ik de volgende dag wel weer toegang.

De Ziggo helpdesk geeft tot op heden aan dat er bij Ziggo geen probleem zit...maar ik ben wel benieuwd naar gelijksoortige ervaringen van andere klanten en naar mogelijke oorzaken / oplossingen.

Al vast dank voor jullie suggesties!

installeer wireshark en maak een trace als het fout gaat, en eentje als er geen problemen zijn.
zoek de verschillen.

Dank voor de reactie.
Vraag blijft wel staan of dit bij anderen bekend voorkomt en of het technisch mogelijk is dat via bv een modem-update dit specifieke probleem kan ontstaan en ook weer vanzelf verdwijnt.

Graag een eenvoudige technische uitleg van de mogelijke relatie..

Met dank

Je bent volgens mij de eerste (in jaren) die dit probleem rapporteert.
Mijn conclusie : ga eerst de oorzaak bij jezelf zoeken.
Als het aan iets van Ziggo lag, hadden we dat wel voorbij zien komen (hoewel ik dat nooit uit wil sluiten, maar de kans is klein).

meten is weten. en het is niet zo dat er continu modem updates worden gedaan.
is dit trouwens een vpn verbinding? welke modem/router van ziggo gebruik je? heb je ook nog een eigen router, en zo ja welke? is dit wifi of bedraad?
wat ik niet goed kan plaatsen is dat het niet voortdurend verkeerd gaat. is dat steeds op het zelfde tijdstip? of als de computer xx minuten aanstaat? er nog een andere computer wordt aangezet? of als je eerst op bepaalde andere pagina's bent geweest? staan die pagina's op het zelfde server / volume als die andere?
kortom vragen genoeg. heb zelf een keer zoiets dergelijks gehad, bleek er ergens een geweldige configuratiefout te zitten in een router, en die beheerder was te stom om voor de duvel te dansen. ik heb toen uit pure armoede maar mijn eigen MTU verlaagd om het werkend te krijgen.
als je een trace hebt, kun je zien waarom het waar verkeerd gaat. dat wil dan niet zeggen dat je meteen de oplossing hebt, maar kun je wel gerichter gaan zoeken. dat het met xs4all werkt kan zijn omdat het werkt, niet omdat het hóórt te werken.

@Mesa
We hebben naar veel oorzaken gezocht, echter (vooralsnog) geen enkele oorzaak bij onszelf kunnen vinden (uiteraard wel mee gestart).
Omdat het probleem 'vanzelf' weer wordt opgelost kan ik me voorstellen dat er geen meldingen worden gedaan. Vandaar mijn vraag of het bij anderen bekend is.

@PetervdM
Helemaal eens met 'meten is weten'. De reden dat ik dit probleem plaats in dit forum is om te onderzoeken of er meer mensen dit probleem herkennen.

Zoals aangegeven gaat het niet alleen om mijn eigen netwerk thuis maar ook om het netwerk van collega's in Amersfoort.
In Amersfoort is het probleem begonnen toen we onlangs zijn overgestapt van KPN naar Ziggo (wat ons weer een stap dichter bij de conclusie bracht dat het een Ziggo-probleem moet zijn). Ik herkende toen het probleem dat ik thuis al langer had.

In mijn thuissituatie gaat het om een eigen bedraad netwerk met de Ubee evb3200 (dus geen VPN verbinding met Amersfoort).

Qua ontstaan is er geen peil op te trekken.
Soms gaat het een paar maanden goed. Soms zit er 1 week tussen.
Meestal direct 's ochtends (na een nachtelijke update?), soms pas in de loop van de dag.
Ook geen relatie met bezoek andere pagina's.

Ik heb geen ervaring met het maken van een trace, maar zal het gaan proberen en me weer hier melden.
Dank voor het meedenken.

PS
Je laatste opmerking
"dat het met xs4all werkt kan zijn omdat het werkt, niet omdat het hóórt te werken" kan ik niet helemaal plaatsen...

soms zijn dingen niet juist geconfigureerd, maar werkt het toch omdat andere processen toleranter zijn dan de norm voorschrijft.

bv volgens de norm werkt wifi alleen op de snelle N norm als je als beveiliging óf niks óf wpa2 gebruikt EN wmm is ingeschakeld.

in de praktijk werkt het vaak ook met wpa en zonder wmm.

als jij je wifi-router dus niet volgens de norm instelt en het dan een keer níet werkt met een bepaald apparaat kan je wel gaan afgeven op dat ene apparaat, maar dat is niet terecht. als jíj je aan de norm had gehouden bij het inrichten van je wifi router had je het probleem niet gehad. het werkte tgv de tolerantie van het gros van de systemen: het werkt omdat het werkt, niet omdat het hóórt te werken.

zoals de disclaimer bij reclame voor financiëele producten het zo fraai zegt: "resultaten behaald in het verleden bieden geen garantie voor de toekomst".

als nou lokatie X niet juist is geconfigureerd ( wat dan ook ), en de internet toegang van kpn is toleranter dan die van ziggo, kun je de fout bij ziggo blijven zoeken tot je een ons weegt. vandaar: meten is weten, en niks uitsluiten.

Peter : welke wireshark filters zou hij moeten gebruiken om niet te verzuipen in een oneindige wireshark log ?

goeie. ik zou eens beginnen op de eigen pc met het volgende filter:

ip.addr==x.x.x.x and ip.addr==y.y.y.y , waarbij x.x.x.x het lan ip adres van de pc is ( dus niet het wan adres van de router ) en y.y.y.y het ip adres van de server zoals dat wordt teruggeven bij een ping -a of nslookup.

dit filter laat alle verkeer zien tussen je pc en de server, in beide richtingen. omdat http(s) verkeer gebruikmaakt van sessies kun je dan per keer zien hoe de verbinding wordt opgebouwd in de three-way handshake vwb zaken als mtu ed, en waar de verbinding op een gegeven moment stokt.

hierbij ga ik er wel vanuit dat de authenticatie gebeurt op de zelfde server als de "data" server. als dat niet zo is dan wordt het basis filter:
ip.addr==1.1.1.1 and ( ip.addr==2.2.2.2 or ip.addr==z.z.z.z ) , z.z.z.z is dan de authenticatie server.

enige kennis van de gebruikte netwerkarchitectuur is dus wel handig.