Vinnaren i pepparkakshustävlingen!
2018-11-20, 17:26
  #1
Medlem
Jag har en D-Link DIR-810L. Allt har alltid fungerat smärtfritt. För ett par månader sedan började jag bygga en egen webbsida. Hosting sker hos en VPN-leverantör. Sedan start har jag inte kunnat nå www-adressen på vilken sidan ligger. Detta problem har jag endast via ovan nämnda router. Om jag surfar via andra trådlösa nätverk eller via hotspot på telefonen fungerar det utan problem.

Jag har varit inne och kikat i routerns inställningar via adminkontot och hittar inget avvikande. Jag har provat ändra IP-adress utan framgång och har naturligtvis resetat routern. Inget funkar.

Är det någon här som har en susning om var problemet ligger?
Citera
2018-11-20, 18:00
  #2
Medlem
Bongomans avatar
Jag tror problemet ligger i något vi tekniker kallar MTU. Det är en tråkig verklighet att vissa nätleverantörer har länkar som minskar din MTU och det systemet som ska rapportera MTU, eller defragmentera paketen, inte fungerar.

Vilken leverantör har du av router och nät?
Citera
2018-11-20, 18:19
  #3
Medlem
Citat:
Ursprungligen postat av Bongoman
Jag tror problemet ligger i något vi tekniker kallar MTU. Det är en tråkig verklighet att vissa nätleverantörer har länkar som minskar din MTU och det systemet som ska rapportera MTU, eller defragmentera paketen, inte fungerar.

Vilken leverantör har du av router och nät?

Tack för svar! Bahnhof är internetleverantör och routern är den nämnda ovan.
Citera
2018-11-20, 18:43
  #4
Medlem
Bongomans avatar
Citat:
Ursprungligen postat av 1980s
Tack för svar! Bahnhof är internetleverantör och routern är den nämnda ovan.

Bahnhof är svåra. En kompis har dem och har problem med vissa sidor ibland. De kör mystiska länkar kors och tvärs och ibland fallerar MTU-discovery och defragmentering. Det finns verktyg för att hitta sådant men de flesta är för Linux.

Ping är något man kan använda men inte säker på att Windows kan ställa paketstorleken.
Citera
2018-11-20, 20:52
  #5
Medlem
Citat:
Ursprungligen postat av Bongoman
Bahnhof är svåra. En kompis har dem och har problem med vissa sidor ibland. De kör mystiska länkar kors och tvärs och ibland fallerar MTU-discovery och defragmentering. Det finns verktyg för att hitta sådant men de flesta är för Linux.

Ping är något man kan använda men inte säker på att Windows kan ställa paketstorleken.

Jag förstår. Har du några lösningsförlag? Jag är långt ifrån någon hacker...
Citera
2018-11-20, 23:33
  #6
Medlem
Citat:
Ursprungligen postat av 1980s
Jag har en D-Link DIR-810L.
Är det någon här som har en susning om var problemet ligger?

Problemet ligger mest troligt i Dlinkens SPI-brandvägg, prova att sätta datorn i DMZ eller stäng av SPI-brandväggen mot din dator och testa. Jag skulle tro att det löser dina problem.

Citat:
Ursprungligen postat av Bongoman
Jag tror problemet ligger i något vi tekniker kallar MTU. Det är en tråkig verklighet att vissa nätleverantörer har länkar som minskar din MTU och det systemet som ska rapportera MTU, eller defragmentera paketen, inte fungerar.

Vilken leverantör har du av router och nät?

Jag vet inte vilken nätleverantör som har ett någorlunda modernt nätverks som inte kan köra en MTU på 1500 i sina interna länkar, ISPers interna länkar är i regel goda för jumbo frames som ligger på 9000 i MTU.

Av TS leverantörer så är det bara VPN-leverantören som måste sänka sin MTU

För att göra en riktig VPN så måste du sätta en lägre MTU på paketen i tunneln för att kunna köra tunneln över internet.
Vi kan göra ett exempel av en GRE-over-IPv4-tunnel.
Du har 1500 MTU att utnyttja totalt eftersom du ska köra den över internet mellan olika leverantörer.
IPv4-header = 20 Bytes
TCP-header = 20 Bytes
GRE-header = 4 Bytes

Eftersom vi ville ha GRE-over-IPv4 så måste vi då räkna bort dom bytes vi behöver lägga till.
1500 - 20 - 4 = 1476 Bytes

Sen vill vi ju ha MSS så vi säkerställen att TCP-payloaden inte överstiger en viss storlek och då får vi räkna bort ytterligare några bytes eftersom det tillkommer en extra TCP-header och en till IPv4-header.
1476 - 20 - 20 = 1436

Här har vi alltså en VPN med en MTU på 1436 som ska köras över internet, för att detta ska gå ihop bra lär VPN-leverantören flagga paketen med DF-BIT som gör att paketen inte fragmenteras.
Citera
2018-11-21, 06:28
  #7
Medlem
Bongomans avatar
Citat:
Ursprungligen postat av trolladde
Problemet ligger mest troligt i Dlinkens SPI-brandvägg, prova att sätta datorn i DMZ eller stäng av SPI-brandväggen mot din dator och testa. Jag skulle tro att det löser dina problem.



Jag vet inte vilken nätleverantör som har ett någorlunda modernt nätverks som inte kan köra en MTU på 1500 i sina interna länkar, ISPers interna länkar är i regel goda för jumbo frames som ligger på 9000 i MTU.

Av TS leverantörer så är det bara VPN-leverantören som måste sänka sin MTU

För att göra en riktig VPN så måste du sätta en lägre MTU på paketen i tunneln för att kunna köra tunneln över internet.
Vi kan göra ett exempel av en GRE-over-IPv4-tunnel.
Du har 1500 MTU att utnyttja totalt eftersom du ska köra den över internet mellan olika leverantörer.
IPv4-header = 20 Bytes
TCP-header = 20 Bytes
GRE-header = 4 Bytes

Eftersom vi ville ha GRE-over-IPv4 så måste vi då räkna bort dom bytes vi behöver lägga till.
1500 - 20 - 4 = 1476 Bytes

Sen vill vi ju ha MSS så vi säkerställen att TCP-payloaden inte överstiger en viss storlek och då får vi räkna bort ytterligare några bytes eftersom det tillkommer en extra TCP-header och en till IPv4-header.
1476 - 20 - 20 = 1436

Här har vi alltså en VPN med en MTU på 1436 som ska köras över internet, för att detta ska gå ihop bra lär VPN-leverantören flagga paketen med DF-BIT som gör att paketen inte fragmenteras.

Normalt sker allt detta helt transparent för kunden och mäter man till vilken plats som helst så får man hela fina 1500-byte paket även om vissa delar fragmenteras och plockas ihop igen. Fragmentering är skit men plockas paketen ihop igen på ett snyggt sätt så kan man som kund skita i vad som händer på vägen. Om detta fallerar, ingen MSS sätts, DF försvinner på vägen eller GRE filtreras bort så blir det apskit. Det finns tyvärr idioter bland nätleverantörerna som gör saker de inte ska. Det tror de levererar något men det är inte riktigt en komplett tjänst.
Citera
2018-11-21, 10:14
  #8
Medlem
Citat:
Ursprungligen postat av Bongoman
Normalt sker allt detta helt transparent för kunden och mäter man till vilken plats som helst så får man hela fina 1500-byte paket även om vissa delar fragmenteras och plockas ihop igen. Fragmentering är skit men plockas paketen ihop igen på ett snyggt sätt så kan man som kund skita i vad som händer på vägen. Om detta fallerar, ingen MSS sätts, DF försvinner på vägen eller GRE filtreras bort så blir det apskit. Det finns tyvärr idioter bland nätleverantörerna som gör saker de inte ska. Det tror de levererar något men det är inte riktigt en komplett tjänst.

Återigen, kan du nämna någon ISP som gör detta?
Det du pratar om görs i brandväggar och ISPer kör absolut inga brandväggar på konsumenttrafik.
Undantaget som skulle kunna ställa till det för vissa tunnlar är om en ISP kör CG-NAT, detta är dock väldigt ovanligt att tunneltrafik inte lyckas hitta sig igenom adressöversättningen när det kommer till CG-NAT, det ska vara någon exceptionellt märkligt tunnel
Citera
2018-11-21, 10:22
  #9
Medlem
Citat:
Ursprungligen postat av trolladde
Problemet ligger mest troligt i Dlinkens SPI-brandvägg, prova att sätta datorn i DMZ eller stäng av SPI-brandväggen mot din dator och testa. Jag skulle tro att det löser dina problem.



Jag vet inte vilken nätleverantör som har ett någorlunda modernt nätverks som inte kan köra en MTU på 1500 i sina interna länkar, ISPers interna länkar är i regel goda för jumbo frames som ligger på 9000 i MTU.

Av TS leverantörer så är det bara VPN-leverantören som måste sänka sin MTU

För att göra en riktig VPN så måste du sätta en lägre MTU på paketen i tunneln för att kunna köra tunneln över internet.
Vi kan göra ett exempel av en GRE-over-IPv4-tunnel.
Du har 1500 MTU att utnyttja totalt eftersom du ska köra den över internet mellan olika leverantörer.
IPv4-header = 20 Bytes
TCP-header = 20 Bytes
GRE-header = 4 Bytes

Eftersom vi ville ha GRE-over-IPv4 så måste vi då räkna bort dom bytes vi behöver lägga till.
1500 - 20 - 4 = 1476 Bytes

Sen vill vi ju ha MSS så vi säkerställen att TCP-payloaden inte överstiger en viss storlek och då får vi räkna bort ytterligare några bytes eftersom det tillkommer en extra TCP-header och en till IPv4-header.
1476 - 20 - 20 = 1436

Här har vi alltså en VPN med en MTU på 1436 som ska köras över internet, för att detta ska gå ihop bra lär VPN-leverantören flagga paketen med DF-BIT som gör att paketen inte fragmenteras.

Tack för svar!

SPI var redan avstängd. Jag har också provat DMZ nu, men det hjälper heller inte. Några andra förslag?
Citera
2018-11-21, 10:55
  #10
Medlem
Jag ska tillägga att jag kan nå den aktuella sidan om jag kör med kabel direkt mellan vägguttag och dator. Felet ligger alltså i routern.
Citera
2018-11-21, 17:42
  #11
Medlem
Bongomans avatar
Citat:
Ursprungligen postat av trolladde
Återigen, kan du nämna någon ISP som gör detta?
Det du pratar om görs i brandväggar och ISPer kör absolut inga brandväggar på konsumenttrafik.
Undantaget som skulle kunna ställa till det för vissa tunnlar är om en ISP kör CG-NAT, detta är dock väldigt ovanligt att tunneltrafik inte lyckas hitta sig igenom adressöversättningen när det kommer till CG-NAT, det ska vara någon exceptionellt märkligt tunnel

Telia har i allra högsta grad brandväggar. De har både blockering av inkommande DNS och utgående port 25, ett barnporrfilter, som för övrigt inte längre är baserat på DNS, och lite annat blandat skit. Mindre ISP hyr kapacitet i andra leverantörers backbone om de har verksamhet på flera orter. Vissa blockerar VPN men det är främst mobilt.

Det optimala är rak pipa till närmsta GIX men det är få som levererar det.
Citera
2018-11-23, 23:05
  #12
Medlem
Citat:
Ursprungligen postat av 1980s
Tack för svar!

SPI var redan avstängd. Jag har också provat DMZ nu, men det hjälper heller inte. Några andra förslag?

Ah, sedär.. har du kollat så att PPTP och IPSEC är aktiverat i brandväggen? Hittade någon tråd på Dlinkforum som tipsade om att det ska vara aktiverat i brandväggen för att den ska släppa igenom trafiken. Verkar som att det finns en SPI-brandvägg och en vanlig brandvägg utan inspection
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback