yoel caspersen blog bloghoved

Gør det simpelt med en captive portal

Da jeg i tidernes morgen startede som udvikler i IT-branchen, lærte jeg en vigtig lektie: Hvis folk skal vælge mellem avanceret og simpelt, vælger de fleste simpelt.

Det er værd at huske, når man skal sælge på nettet - hvis det er bare den mindste smule besværligt, bliver ens butik fravalgt, og så er det fuldstændig ligegyldigt, hvor mange fede features man selv mener, at man har. I tilfældet med bolignettet, jeg omtalte i sidste blogindlæg, havde de nye kunder et simpelt valg - de kunne forblive kunder hos Yousee.

Derfor var der ingen tvivl: Det skulle være nemt at blive kunde hos Kviknet, så vi kunne vinde kunderne over ved at levere et bedre produkt til en lavere pris. Signup-processen måtte ikke være en hindring.

Den allernemmeste løsning for kunden ville være, at vi åbnede bolignettet fuldstændigt, så kunden bare skulle sætte computeren i netværkstikket og gå på internettet. Men vi skulle jo helst også gerne have lidt penge i kassen, og det var udelukket at trække betalingen for abonnementet over huslejen, da en af betingelserne for vores overtagelse af driften af bolignettet var, at vi skulle håndtere alle opgaverne selv.

Kunderne skal indfanges

Løsningen blev en såkaldt captive portal. Det er en løsning, der kendes fra hoteller, lufthavne og andre steder, hvor det skal være nemt at komme på internettet mod betaling. Ideen er, at man som bruger automatisk bliver ledt hen til en betalingsside, når man forsøger at gå på nettet. Når man har betalt, kan man bruge forbindelsen som normalt.

Allerførst skal brugeren have en IP-adresse. Som tidligere beskrevet havde hver bruger sit eget VLAN og tilhørende /29 IP scope.

Når man indfører DHCP i et netværk med flere VLANs, anvender man som regel DHCP relays. Et DHCP relay er, når switchen tager imod DHCP-forespørgslen fra brugeren og sender den videre til en DHCP-server et andet sted i netværket.

På en HP Procurve switch konfigureres et DHCP relay med parameteren ip helper-address:

vlan 3606 
   name "Kunde XYZ" 
   ip address 172.16.31.1 255.255.255.248 
   ip helper-address 172.16.1.81
   exit 

Når switchen sender DHCP-forespørgslen videre til DHCP-serveren 172.16.1.81, påtrykker den sin egen IP-adresse som afsender af forespørgslen - i det her tilfælde 172.16.31.1. DHCP-serveren anvender herefter IP-adressen til at afgøre, hvilket scope, der skal deles ud fra.

I vores tilfælde anvendte vi ISC DHCP server, og den konkrete kunde-konfiguration så således ud:

# Kunde XYZ
subnet 172.16.31.0 netmask 255.255.255.248 {
        range 172.16.31.2 172.16.31.6;
        option routers 172.16.31.1;
}

DHCP-serveren vil i dette tilfælde tilbyde 172.16.31.2 til switchen, som sender svaret videre til brugerens PC i VLAN 3606. Brugeren har nu en IP-adresse og en gateway og kan i princippet gå på nettet.

En captive portal kan laves på flere måder, men den består som regel af to elementer: En gateway, der indfanger brugeren, og en portal, som brugeren sendes hen til.

At indfange brugeren er faktisk lidt af en udfordring - når brugeren åbner sin browser og forventer at få vist www.google.dk, men i stedet får vist en side, der beder om hans kreditkortoplysninger, bør alle alarmklokker ringe.

De fleste captive portals anvender DNS hijacking eller ICMP redirects. Ved DNS hijacking manipulerer man DNS-trafikken, der går igennem gateway'en, så en forespørgsel til fx www.google.dk vil pege på en IP-adresse, der tilhører betalingssiden. DNS-pakkerne udstyres med en TTL på 0, så brugerens PC ikke cacher svaret, når betalingen er gået igennem og internetforbindelsen igen skal fungere som normalt.

ICMP redirects er en low-level måde at omdirigere IP-pakker på. Når en router opdager, at en indgående pakke skal sendes ud på det samme interface, som pakken kom ind på, og den i øvrigt skal sendes til en anden router, som kan nås direkte fra afsenderen, sender den en ICMP redirect til afsenderen af pakken, da det ville være mere optimalt hvis afsenderen af pakken sender direkte til den anden router. Det kan udnyttes til at sende brugeren hen til en betalingsside.

Linux to the rescue

I vores tilfælde skulle al trafikken fra bolignettet gå gennem en Linux-server, der agerer NAT-firewall. En Linux-server er et utroligt alsidigt værktøj, når det kommer til håndtering af netværkstrafik - den kan route, filtrere, manipulere og prioritere pakker, og det hele foregår i kernen.

Når man skal indstille kernen på en Linux-server til at håndtere netværkspakker, anvender man en række værktøjer, herunder iptables, der også kommer i en særlig IPv6-version kaldet ip6tables.

Vi satte derfor vores Linux-server op, så der var en firewall-regel for hver bruger på netværket. Brugere, der allerede havde betalt for deres abonnement, fik lov at gå på nettet:

iptables -A FORWARD -s 172.16.31.0/29 -j ACCEPT

Brugere, der endnu ikke havde betalt, blev derimod forwarded til webserveren, der hoster betalingssiden:

iptables -t nat -A PREROUTING -s 172.16.32.0/29 -p tcp --dport 80 -j DNAT --to-destination 172.16.1.81:80

Vi tillod DNS-opslag for alle brugere:

iptables -A FORWARD -s 172.16.0.0/12 -p udp --dport 53 -j ACCEPT

Og ja, det kan i teorien udnyttes, men i praksis holder vi øje med trafikken, og hvis det bliver et problem, finder vi en løsning på det.

På webserveren havde vi sat en catch-all-host op. Hvis en bruger forsøgte at gå ind på fx www.google.dk, ville DNS-opslaget gå fint igennem, hvorefter brugeren ville blive sendt til vores webserver. Webserveren ville tage imod forespørgslen og kvittere med en HTTP redirect til http://www.kviknet.dk - det gjorde vi i vores Apache-server med lidt .htaccess-magi:

RewriteEngine on
RewriteRule ^(.*)$ http://www.kviknet.dk/ [R=303,L]

Desuden havde vi også indført et par regler, så adgang til vores website og vores betalingsgateway var tilladt for alle.

Når kunden havde gennemført betalingen, erstattede vi hans iptables-regel on-the-fly, så han fik fuld adgang til internettet med det samme.

Opmærksomme læsere vil bemærke, at vi fortsatte med at anvende RFC 1918-adresser på bolignettet, hvor vi i stedet burde have anvendt RFC 6598-adresser, som er reserveret til Carrier Grade NAT-formål.

RFC 1918-adresser bør ikke anvendes til Carrier Grade NAT-formål, da det kan give problemer med sammenfald mellem IP-adresserne på den enkelte brugers netværk på indersiden af hans wifi-router og bolignettet på ydersiden.

Når vi bibeholdt adresseplanen, var det for at sikre bagud-kompatibilitet til de brugere, der indtil vores overtagelse af bolignettet havde anvendt statisk konfigurerede IP-adresser.

Vi er dog ved at være nået til et punkt, hvor alle brugere anvender DHCP, så i forbindelse med at vi indfører IPv6, vil vi også anvende RFC 6598-adresser, hvor der er behov for dette.

Findes der en pænere løsning?

Ovenstående approach med en captive portal fungerede fint, men kun på HTTP - på HTTPS giver det en masse grimme advarsler i browseren, hvis den server, man connecter til, ikke har det certifikat, browseren forventer, og det er helt efter bogen.

Vi leder derfor p.t. efter en pænere løsning på dette - hvordan gør man det nemt at betale uden at indføre et man-in-the-middle attack?

Kommentarer (38)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Yoel Caspersen Blogger

Vil du uddybe dit forslag?

En af de cool ting ved vores nuværende approach er, at det ikke kræver, at vi udleverer en router - kunden sætter bare PC'en, eller sin egen router, i netstikket i lejligheden, og så er der (næsten) hul igennem.

  • 1
  • 0
Gert G. Larsen

Nu har jeg ikke boet i en boligforening, eller andre steder med LAN-ipadresser på min forbindelse.
Hvordan klarer kunderne sådan noget med portforwarding, egne webservere, torrentprogrammer og lignende, der gerne skal have en rigtig internet-ip ?
Har I haft overvejet at købe internet-ip'er til alle kunderne? Er det for dyrt eller for besværligt, eller?

  • 0
  • 0
Yoel Caspersen Blogger

Hvordan klarer kunderne sådan noget med portforwarding, egne webservere, torrentprogrammer og lignende, der gerne skal have en rigtig internet-ip ?

Det gør de ikke.

Har I haft overvejet at købe internet-ip'er til alle kunderne? Er det for dyrt eller for besværligt, eller?

Det er en af de ting, vi arbejder på. Sagen er, at som billedet ser ud nu, er offentlige IPv4-adresser en løbende udgift, og langt de fleste kunder klarer sig fint uden. Indtil for kort tid siden kunne man betale sig fra at få nogle flere IP-adresser hos RIPE ved at købe et medlemskab ekstra (man får 1024 adresser pr. medlemskab p.t.), men de har netop lukket den mulighed, da russiske virksomheder har købt medlemskaber i stor stil for at hamstre IPv4-adresser og sælge dem dyrt senere.

Det betyder, at vi er nødt til at købe IPv4-adresser på diverse børser, hvor den slags bliver handlet, og handelsprisen er ca. 10$ pr. IPv4-adresse, hvis man køber dem i store blokke. IP-adresserne vil ofte have en historik, og det betyder, at kunderne fx vil opleve, at visse websites tror, de kommer fra Ukraine, Rusland eller et helt andet sted. Hvis man er uheldig, er IP-adresserne også registreret i diverse blacklists, og vi skal derfor bruge tid på at få dem fjernet derfra.

Kviknet har som medlem af RIPE fået tildelt 1024 IPv4-adresser, og vi arbejder i skrivende stund på at kunne tilbyde brugere på vores bolignet, at de kan få en offentlig IPv4-adresse mod en beskeden betaling, så de kunder, der reelt har brug for offentlige IPv4-adresser kan få dem, mens de, der er ligeglade, kan undvære.

Løsningen på problematikken hedder IPv6, og her vil vi i fremtiden tilbyde offentlige scopes til alle bolignetkunder uden merpris.

  • 2
  • 0
Yoel Caspersen Blogger

Hvornår går i over til IPv6?

Så hurtigt det kan lade sig gøre ;-)

Lige nu er vi ved at implementere et projekt, der vil gøre det muligt for os at tilbyde til vores bolignetkunder - jeg forventer at vi har de første kunder i luften på IPv6 om ca. en måneds tid. TDC hænger stadig i bremsen i forhold til IPv6 på Bredbånd Basic (dvs. DSL-forbindelser), så der kommer nok til at gå noget tid her, men vi presser løbende på for at få det gjort muligt.

Vi arbejder på sagen i forhold til at komme ind på TDC's coax-net og fibernet, og her bliver det et godt spørgsmål, hvornår IPv6 understøttes. På fibernettet forventer jeg, at det bliver tilgængeligt fra dag 1, mens coax-nettet er mere usikkert. Hardwaren og netværket burde understøtte det, men TDC er endnu ikke klar til at slippe det løs.

  • 1
  • 0
Jesper Nielsen

Jeg var for flere år siden ansat hos en internetudbyder, som puttede ikke-betalere i et andet VLAN, som kun tillod forbindelse til udbyderens egne tjenester.

De lavede stadig noget captive portal med DNS eller på anden vis for at få kunderne ind til selvbetjeningen. Men ved at skifte VLAN på ikke-betalerne sørgede man for, at det kun var dem, der skulle igennem en fælles gateway — og ikke også alle de betalende.

Når kunden havde betalt, sendte provisioneringssystemet en besked ud til switchen om, at VLAN skulle ændres tilbage.

  • 4
  • 0
Jesper Nielsen

Men ved at skifte VLAN på ikke-betalerne sørgede man for, at det kun var dem, der skulle igennem en fælles gateway — og ikke også alle de betalende.

Og en tilføjelse.

Det kan ikke anbefales at putte erhvervskunder i en "du har ikke betalt din regning"-captive portal. De bliver så sure, hvis de har kundebesøg, og den besked kommer frem på storskærmen under mødet.

Så hellere bare lukke forbindelsen for den type kunder.

  • 2
  • 0
Jesper Nielsen

Men ved du, om de gjorde noget specielt for at undgå advarsler i browseren, når brugerne blev omdirigeret til betalingssiden?

Nej, det er jeg desværre ikke bekendt med. Jeg arbejdede ikke i netværksafdelingen, så jeg hørte det kun beskrevet overordnet.

Men nu var HTTPS ikke så udbredt dengang (i midten af 0'erne), så mit bud vil være, at det ikke var tænkt ind i løsningen.

  • 1
  • 0
Henning Wangerin

Spændende ide med et separat VLAN til dem, der ikke har betalt endnu. Men ved du, om de gjorde noget specielt for at undgå advarsler i browseren, når brugerne blev omdirigeret til betalingssiden?

Nogle browsere melder fejl når der viderestilles fra en global ip til en rfc1819-adresse, men det omgår I jo ved at sende al trafik til en catch-all server.

certifikat-advarslen ved viderestilling af en https-forbindelse an du jo ikke gøre noget ved.

Jeg ved ikke lige hvordan man ville kunne omgå de to advarsler. Er der andre senarier hvor der vil komme advarsler?

  • 1
  • 0
Yoel Caspersen Blogger

Jeg ved ikke lige hvordan man ville kunne omgå de to advarsler. Er der andre senarier hvor der vil komme advarsler?

Ikke lige hvad jeg selv kan komme på - det er primært et problem ved HTTPS, dvs. Google, Facebook og Youtube, som nok er der hvor 90 % af brugerne vil ind ;-)

På Android er der en mekanisme, der detekterer captive portals og giver en pæn advarsel til brugeren om, at der skal logges ind, før man kan anvende internettet. Det havde været fedt, hvis der var en standard for captive portal detection på tværs af styresystemer.

  • 3
  • 0
Morten Siebuhr

På Android er der en mekanisme, der detekterer captive portals og giver en pæn advarsel til brugeren om, at der skal logges ind, før man kan anvende internettet. Det havde været fedt, hvis der var en standard for captive portal detection på tværs af styresystemer.

SVJV har de fleste moderne OS'er en URL de prøver at hente for at se om de rammer en captive portal. En hurtig søgning afslører lidt uenighed om de eksakte URLer og mulig support for noget måske-relevant kaldet WISPr.

Så er der også forslaget om HTTP 511: Network Authentication Required fra RFC6585, netop designet til Captive Portals. Jeg har ingen anelse om hvor udbredt understøttelsen er...

  • 1
  • 0
Christian Nobel

SVJV har de fleste moderne OS'er en URL de prøver at hente for at se om de rammer en captive portal.

Apple dimser mener de skal snakke hjem hvis de skal på et åbent WiFi - det giver den udfordring at hvis man har eksempelvis et åbent gæstenetværk, hvor validering foregår gennem en captive portal, så er det nødvendigt at indsætte et par Apple adresser (som ikke er konsistente over tid) i iptables, ellers kommer æbledimsen ikke engang på det trådløse netværk.

  • 0
  • 0
Yoel Caspersen Blogger

Så er der også forslaget om HTTP 511: Network Authentication Required fra RFC6585, netop designet til Captive Portals. Jeg har ingen anelse om hvor udbredt understøttelsen er...

Jeg har altid drømt om en legitim use-case for HTTP Response Code 402: Payment Required, men det ser desværre ikke ud til at den er implementeret i gængse browsere ;-)

511 lyder umiddelbart mere interessant - men ja, det er selvfølgelig et godt spørgsmål, hvor udbredt understøttelse den har. Det skal jo helst virke på tværs af alle platforme.

  • 1
  • 0
Yoel Caspersen Blogger

Hvad er jeres typiske pingtider på en DSL forbindelse, hvor der er omkring 500m til centralen?

Det er et godt spørgsmål. Jeg har netop prøvet på min egen private DSL-forbindelse, hvor der er ca. 650 meter til DSLAM'en:

yoel@server:~$ ping 188.176.165.157  
PING 188.176.165.157 (188.176.165.157) 56(84) bytes of data.  
64 bytes from 188.176.165.157: icmp_seq=1 ttl=63 time=5.97 ms  
64 bytes from 188.176.165.157: icmp_seq=2 ttl=63 time=5.41 ms  
64 bytes from 188.176.165.157: icmp_seq=3 ttl=63 time=5.93 ms  
64 bytes from 188.176.165.157: icmp_seq=4 ttl=63 time=5.95 ms  
64 bytes from 188.176.165.157: icmp_seq=5 ttl=63 time=5.24 ms  
64 bytes from 188.176.165.157: icmp_seq=6 ttl=63 time=5.65 ms  
64 bytes from 188.176.165.157: icmp_seq=7 ttl=63 time=5.94 ms

I dette tilfælde pinger jeg min offentlige gateway-adresse i TDC's net, så pingtiden repræsenterer forsinkelsen i selve DSL'en. Forbindelsen er i øvrigt en VDSL med ca. 40 Mbit/s download og 5 Mbit/s upload, og der sidder en Mikrotik-router foran serveren, jeg pinger fra.

  • 2
  • 0
Baldur Norddahl

Sjovt, jeg er ikke lige hjemme men pinger min router udefra:

baldur@ballerup1:~$ ping6 -c5 2a00:7660:5c6::
PING 2a00:7660:5c6::(2a00:7660:5c6::) 56 data bytes
64 bytes from 2a00:7660:0:16::c6: icmp_seq=1 ttl=63 time=5.36 ms
64 bytes from 2a00:7660:0:16::c6: icmp_seq=2 ttl=63 time=5.34 ms
64 bytes from 2a00:7660:0:16::c6: icmp_seq=3 ttl=63 time=5.44 ms
64 bytes from 2a00:7660:0:16::c6: icmp_seq=4 ttl=63 time=5.41 ms
64 bytes from 2a00:7660:0:16::c6: icmp_seq=5 ttl=63 time=5.44 ms

--- 2a00:7660:5c6:: ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 5.341/5.402/5.448/0.079 ms

Det er en 70/20 VDSL2 med cirka 300-400 meter til DSLAM.

Ping af fiber:

baldur@ballerup1:~$ ping6 -c5 2a00:7660:8ca::
PING 2a00:7660:8ca::(2a00:7660:8ca::) 56 data bytes
64 bytes from 2a00:7660:0:12::ca: icmp_seq=1 ttl=62 time=1.46 ms
64 bytes from 2a00:7660:0:12::ca: icmp_seq=2 ttl=62 time=1.72 ms
64 bytes from 2a00:7660:0:12::ca: icmp_seq=3 ttl=62 time=1.66 ms
64 bytes from 2a00:7660:0:12::ca: icmp_seq=4 ttl=62 time=1.51 ms
64 bytes from 2a00:7660:0:12::ca: icmp_seq=5 ttl=62 time=1.72 ms

--- 2a00:7660:8ca:: ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.460/1.617/1.723/0.112 ms

Begge tilfælde inkluderer også en tur på cirka 10 km i vores backbone.

Ping af en anden server over 10G backbone:

baldur@ballerup1:~$ ping6 -c5 herlev1
PING herlev1(herlev1.gigabit.dk) 56 data bytes
64 bytes from herlev1.gigabit.dk: icmp_seq=1 ttl=63 time=0.295 ms
64 bytes from herlev1.gigabit.dk: icmp_seq=2 ttl=63 time=0.269 ms
64 bytes from herlev1.gigabit.dk: icmp_seq=3 ttl=63 time=0.268 ms
64 bytes from herlev1.gigabit.dk: icmp_seq=4 ttl=63 time=0.268 ms
64 bytes from herlev1.gigabit.dk: icmp_seq=5 ttl=63 time=0.255 ms

--- herlev1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.255/0.271/0.295/0.013 ms

  • 1
  • 0
Baldur Norddahl

En kollega foreslog at jeg prøver at pinge routeren fra vores lokalnet. Resultatet er:

baldur@yakshi:~$ ping6 -c5 2a00:7660:8ca::
PING 2a00:7660:8ca::(2a00:7660:8ca::) 56 data bytes
64 bytes from 2a00:7660:8ca::1: icmp_seq=1 ttl=64 time=0.826 ms
64 bytes from 2a00:7660:8ca::1: icmp_seq=2 ttl=64 time=0.707 ms
64 bytes from 2a00:7660:8ca::1: icmp_seq=3 ttl=64 time=0.982 ms
64 bytes from 2a00:7660:8ca::1: icmp_seq=4 ttl=64 time=0.740 ms
64 bytes from 2a00:7660:8ca::1: icmp_seq=5 ttl=64 time=0.694 ms

--- 2a00:7660:8ca:: ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.694/0.789/0.982/0.112 ms

Det er ping fra en maskine der sidder til routeren med et 10m cat6 kabel...

Så en stor del af latency er vores router som er sløv til at svare på pings.

  • 2
  • 0
Yoel Caspersen Blogger

Så ikke just imponerende med de 18-19 ms som DanskNet (med den påtvungne Zyxel *#¤! router) kan mobilisere.

Har du 18-19 ms mellem din router og din gateway hos DanskNet? Jeg vil tro, de anvender TDC's DSLAM'er ligesom os, så selve DSL-forbindelsen er nok af ca. samme kvalitet. Men det kan selvfølgelig være, de har skruet deres efterfølgende netværk anderledes sammen.

  • 0
  • 0
Christian Nobel

Har du 18-19 ms mellem din router og din gateway hos DanskNet?

Ja, fra min router til min offentlige gateway adresse, så det burde repræsentere DSL delen - men de mumler om at der er sat noget delay op med vilje, så jeg skal lige have udfrittet dem om det.

Men det endnu nu nok at at dig bliver dig (Yoel) alligevel på et tidspunkt, da I jo kan love en bedre upload speed - det skal bare lige passe ind i de samlede planer ;-D

  • 3
  • 0
Christian Nobel

Prøv at pinge noget andet end din gateway adresse. Nogle switche er ganske forfærdelige til at svare på pings. Det går til kontrolplanet, det er rate limited og går ind i en QoS kø med lav prioritet.

Det gør det kun værre.
Men hvis jeg pinger min egen routers ip (på ydersiden), så taler vi om ca. 0,6 - 0,7 ms, så det må vel være repræsentativt for sådan en Zyxel knallert.

Og nej, jeg kan jo selvfølgelig ikke foretage en IPv6 ping, men måske engang i år 2035 er TDC nået dertil ;-(

  • 1
  • 0
Jn Madsen

Et par gode tommelfingerregler:

Man skal huske at hastigheden i fiber er rundt regnet 200 km per msek. Den er rar at have i baghovedet, når der skal regnes på delay, tcp segmenter, reel overførselshastighed og lignende. For eksempel hvis en kunde har et kontor i København og et andet i Sidney, så er der nogle gode formler der.

Delay på kobber? Nok ikke værd at nævne,- strækningen er alligevel så kort at det er uden betydning.

Så er der delay på udstyret. Den er mere interessant. Udstyr findes i alverdens afarter, men hvis tingene er af moderne standart og konfigureret ordenligt, så burde der ikke være et nævneværdigt delay. Der er forhåbenligt ingen der konfigurerer en switch til store-and-forward. Man bør bruge cut-through.

Det skal dog lige indskydes, at nogle typer DSLAM er meget langsomme. De skal åbenbart lige holde på pakken og tælle til 10, inden de forwarder dem. Jeg tror dog de er ved at være helt udfaset. Det er nogle år siden jeg sad med den forbandelse.

Så er der den med ping. Den er værre. Ping kan bruges til at konstatere om udstyret er i live. Jeg tør ikke lægge mere i det. Tider fra ping og traceroute på ISP udstyr skal altid tages med et kilo salt.
Noget udstyr er konfigureret til at svare langsomt -udstyret ligger simpelthen et kunstig delay ind,- ofte skal udstyr besvare et ping fra control-plane som er langsommere end hvis det var dataplane,- uanset hvad, så kan trafikken gennem udstyret sagtens være ekspederes hurtigt, mens ping tiderne er lange.

Den store ukendte faktor er QoS og båndbredde. Hvis en pakke skal forbi en strækning hvor der mangler "hul igennem",- så er fanden løs. Alt kan ske, og ikke noget af det er positivt.

Så den eneste slags ping man bør tolke på er mellem udstyr på kundelokationer. Det giver et reelt billede af, hvor hurtigt/langsomt "transport-båndet" mellem 2 lokationer er. - Med mindre udstyret der pinges også er knotten den dag :-)

  • 2
  • 0
Jn Madsen

Jeg så lige der var tvivl om, hvorfor man skulle ligge kunstigt delay ind på ping-svar på ISP udstyr.

Det er simpelthen "business-as-usual" på moderne routere og andet grej.
Tidligt i "O'erne" blev det højeste mode blandt hackere at bombardere routere med ping og pakker med ttl=0 (f.eks. traceroute). De gamle routere, pligtopfyldende og smådumme som de var, de gennemløb dette forløb:

  1. Av,- der er godt nok gang i forretningen i dag.
  2. Der er sgu flere julehilsner til mig end jeg kan nå at svare på. Gemmer dem lige i RAM.
  3. Nu er mine RAM fyldt op med julekort, CPU'en koger ... jeg ligger mig ned og dør.

Og så røg routeren og måske 20.000 kunder på røven.

De fleste store router-producenter har lavet forsvarsværker mod dette nu. Særlige små køer og policy til at svare på ping. Skal reagere trægt og begynde og droppe ICMP-reply helt, hvis der er for meget af den slags trafik.
Ovenstående er naturligvis kun et eksempel ud af mange typer angreb.

  • 4
  • 0
Morten Christensen

"Når kunden havde gennemført betalingen, erstattede vi hans iptables-regel on-the-fly, så han fik fuld adgang til internettet med det samme."

Har/havde I en automatik imellem betalingssystemet og firewall-maskinen, eller skulle der håndkraft til, for at initiere ændringen i iptables ?

  • 0
  • 0
Yoel Caspersen Blogger

Har/havde I en automatik imellem betalingssystemet og firewall-maskinen, eller skulle der håndkraft til, for at initiere ændringen i iptables ?

Det skete helt automatisk. Når betalingen var gennemført, kaldte systemet et shell script, som kørte den rigtige iptables-kommando. Det betød, at der var hul igennem til internettet inden for få hundrede millisekunder efter at betalingen var gået igennem.

Når betalingen gik igennem, blev kunderne trukket for 30 dages abonnement. Hver dag kørtes et shell script via cron, som fornyede udløbne abonnementer - hvis et abonnement ikke kunne fornyes pga. manglende penge på kortet blev abonnementet automatisk lukket og kunne kun genåbnes med et gyldigt betalingskort med penge på. Ingen bindingsperiode, men heller ingen kredit. Keine Hexerei - nur Behändigkeit.

I starten havde nogle få af kunderne svært ved at forstå det, men efterhånden som tiden gik fik det faktisk en opdragende effekt, og det er en ideel måde at undgå dårlige betalere på.

  • 3
  • 0
Yoel Caspersen Blogger

Jeg så lige der var tvivl om, hvorfor man skulle ligge kunstigt delay ind på ping-svar på ISP udstyr.

Super indlæg. Og nogle af effekterne ser man den dag i dag, hvor visse sysadmins blokerer ICMP og ICMPv6 totalt, hvorved bl.a. path MTU discovery holder op med at virke ordentligt.

Vi stod engang over for en opgave, hvor en IPTV-klient skulle finde den bedste distributionsplatform ud af et antal mulige IP-adresser. ICMP ping kunne fortælle os en smule om, hvor tæt den pågældende IP-adresse var på klienten, men da man ikke kan gå ud fra, at ICMP virker pålideligt, måtte vi finde en anden løsning.

Løsningen blev en kombineret speedtest og test af ping-tid - klienten koblede op til en service via HTTP, og målte tidspunktet fra sessionen blev startet til den første byte fra svaret ankom. Inden for en halv træskolængde var det faktisk en ping-tid, der var til at regne med, og ud fra den tid, der gik fra første byte ankom, til den sidste var modtaget, kunne vores klient også regne sin aktuelle båndbredde ud.

På internettet er det i grove træk BGP, der vha. antallet af AS-hops finder ud af, hvilken vej der er den bedste fra A til B. BGP lider dog af den store mangel, at den ikke tager højde for aktuelt tilgængelig båndbredde, så hvis man fx skal distribuere video, kan man ikke nøjes med BGP til at foretage dette valg - her er man nødt til at lave en konkret speedtest.

  • 3
  • 0
Jn Madsen

På internettet er det i grove træk BGP, der vha. antallet af AS-hops finder ud af, hvilken vej der er den bedste fra A til B

BGP er en videnskab for sig, den kan vi tage en anden gang.
De tunge ISP'er har økonomer der skriver ønskesedler om trafikafvikling ud efter de peering aftaler man har forhandlet sig til. Det er så op til designerne/udviklerne at konfigurere BGP'en så trafikken afvikles med størst mulig økonomisk udbytte/mindst mulig udgift.
Det er en multi-multi-million forretning at designe BGP trafikmønstre.

De fleste seriøse ISP'er har også på centrale steder i netværket nogle test-bokse,- hvor man netop kan lave reelle test med kunderne,- ved mistanke om problemer og andet. Netop for at undgå alt det der ping snak,- og lige så ofte "reel båndbredde" problematikker.

  • 1
  • 0
Baldur Norddahl

Man kan melde sig ind i NLNOG RING https://ring.nlnog.net/ og der er også mulighed for at bruge RIPE Atlas. Det er gratis.

Det er kun i begrænset omfang muligt at påvirke inbound trafik. Det følger af at du har fuld kontrol over dit outbound trafik. Vi har IP transit hos TDC, så derfor er det naturligt at vi aflevere trafik til TDC direkte hos TDC. Men hvis jeg har lyst til at aflevere det hos Cogent (vores anden IP transit) i stedet, så er der intet store og mægtige TDC kan gøre ved det.

Man kan lave nogle tricks med BGP communities og ved kunstigt at gøre BGP path længere ved at dublere dit eget AS nummer et par gange. Det har ringe virkning. De fleste (os selv inklusive) bruger kun AS-path længde som fall back efter andre mere specifikke regler.

Jeg har eksempelvis en regel der siger at hvis du er direkte kunde hos Cogent, så sender jeg trafikken via Cogent. Som anden prioritet har jeg en regel om at hvis du er direkte kunde hos TDC, så sender jeg trafikken via TDC. Hvis du ligesom os har peering med både TDC og Cogent, så modtager du vores trafik via Cogent lige meget hvad du forsøger. Den regel har baggrund i at Cogents eget net som regel er ok men de er meget billigere end TDC.

Uheldigvis er det vores inbound (download) som er mest interessant. Altså den retning vi ikke kontrollerer.

Det er nemmere hvis man er content provider, dvs. et datacenter. Her er det outbound (upload) der er mest interessant og det kan de selv styre direkte. Det er også derfor mest content providere der har gavn af at købe software der kan optimere routingen. Vi andre er nødt til at gøre det på et højere plan ved at overveje hvem vi peerer med. Når først peeringen er der, så er der ikke længere nogen kontrol fra vores side. I praksis er det dog ret nemt, da det stort set altid er en fordel at få så meget trafik som muligt på peering.

  • 3
  • 0
Jn Madsen

Det er kun i begrænset omfang muligt at påvirke inbound trafik

Du har helt ret, Baldur.
BGP er ekstremt kompliceret,- og meget afhænger af hvem man er, og hvilke parametre man aftaler i forskellige peering aftaler.
Outbound trafik er naturligvis altid under ens egen kontrol,- det er inbound trafik kontrol der kan give hovedpine.
MED, AS path prepending og communities er værktøjer,- men der er ingen garantier. Det skal aftales med peering partner om de respekterer det,- ellers kan man prepende lige så tosset man vil,- det kan overrules/ignoreres :-)

Hos de større ISP'er er det en del af aftalerne, når de årlige kontrakter underskrives på båndbredde-børsen. Ingen ønsker at betale mere end højst nødvendigt, så de dyreste links benyttes helst som fail-over. Hvis partneren ikke kan/vil lege med på de aftaler,- så bliver der bare ikke skrevet under.

PS,- du kan altid lukke en peering med "shut down",- og når lokummet brænder et andet sted ... "no shut" :-)

  • 1
  • 0
Yoel Caspersen Blogger

RFC 7710 ser ud til at være designet lige præcis til denne problemstilling.

Tak for hintet. Nogle gange er det forunderligt, som tilfældigheder kan afgøre ens timing. Læser Vint Cerf version2? ;-)

Det er i øvrigt en super elegant løsning, der er foreslået i RFC 7710: En ekstra DHCP/RA option, som fortæller hvor man finder sin captive portal.

Kombineret med vores nuværende setup som fallback kunne det være en pæn løsning.

  • 2
  • 0
Log ind eller Opret konto for at kommentere