mboost-dp1
Proxy med logning til 250 brugere
Hvad vil det koste at købe en maskine, der skal fungere som proxy, og som kan logge 250 brugeres internetfærd, så det er i overensstemmelse med logningsbekendtgørelsens §5.
Dvs. der skal logges for, hvilket internt ip, der henvender sig til hvilket eksternt ip, tidspunkt og varighed. Portnummer og protokol skal ligeledes logges.
Der er tale om en 200/200 Mbit linje, som deles mellem 250 ungdomsboliger.
Jeg havde forestillet mig en simpel quad-core-maskine med ~8 GB RAM og et par SSD'er samt to almindelige gigabit-netkort - men er det nok til at håndtere den slags trafik?
Og kan man blot købe en eller anden form for netværksboks, som kan det samme, og som man bare smider ind i sit netværk, evt. i rackskabet sammen med det andet?
Dvs. der skal logges for, hvilket internt ip, der henvender sig til hvilket eksternt ip, tidspunkt og varighed. Portnummer og protokol skal ligeledes logges.
Der er tale om en 200/200 Mbit linje, som deles mellem 250 ungdomsboliger.
Jeg havde forestillet mig en simpel quad-core-maskine med ~8 GB RAM og et par SSD'er samt to almindelige gigabit-netkort - men er det nok til at håndtere den slags trafik?
Og kan man blot købe en eller anden form for netværksboks, som kan det samme, og som man bare smider ind i sit netværk, evt. i rackskabet sammen med det andet?
Maskinen behøver ikke at være så stor selvom det vil hjælpe lidt.. Jeg kan tage en kig på det når jeg får lidt mere tid. Har du et budget?
En proxy er teknisk set en dårlig løsning på den opgave.
En løsning til at logge data skal ikke ændre på flowet af data. Med andre ord, hvis ikke du ville have sat en proxy op alligevel, så skal du heller ikke sætte en proxy op for at løse denne opgave.
I stedet ville jeg anvende tcpdump eller lignende værktøj. For TCP er det nok at dumpe pakker med SYN, FIN eller RST bit sat.
For UDP og UDPlite er der ikke noget sessionsbegreb, således er der ingen pakker som opfylder kravene i §5 stk 1. Der kan selvfølgelig implementeres protokoller ovenpå UDP eller UDPlite, som har et sessionsbegreb. Men der står ikke eksplicit hvilket protokolniveau der skal logges på. Men da der omtales portnumre er der implicit sagt at det er UDP/TCP niveau.
Resultatet er at det er et fortolkningsspørgsmål hvorvidt UDP overhovedet skal logges.
Det er ikke teknisk muligt at implementere et system der kender alle protokoller der kan køres over UDP. Og det er heller ikke teknisk muligt at implementere et system der kender alle de protokoller man kan køre over IP. Desuden er der mange af dem som ikke gør brug af portnumre, og man kan ikke logge et portnummer for en protokol der ikke har et.
Hvis du har et system hvor det ikke er teknisk muligt at logge oplysninger som beskrevet i stk 1 er det så vidt jeg kan læse ikke noget problem. Der står ikke noget om at man skal ændre sit net for at gøre det muligt, i stedet skal man som beskrevet i stk 4 logge hver 500. pakke, hvis det ikke er teknisk muligt at logge som beskrevet i stk 1.
Men man skal stadig logge de samme oplysninger fra pakken. Og man kan stadig ikke logge oplysninger, der ikke findes. Så man er nødt til at tolke kravet sådan at man skal logge portnummer hvis et sådan findes i protokollen, ellers ville bekendtgørelsen jo have været noget vrøvl.
Det vil sige at man nok i sidste ende er nødt til at logge TCP pakker med SYN, FIN eller RST sat og derudover logge hver 500. pakke for alle andre protokoller. Lige det med hver 500. pakke ved jeg ikke om tcpdump kan, men iptables kan.
Derudover kunne man argumenter for at DHCP pakker også initierer og afslutter sessioner på et andet niveau. Man kunne derfor argumentere for at alle DHCP pakker burde logges. Til gengæld indeholder DHCP serveren sandsynligvis en log med tilstrækkelige oplysninger om DHCP til at man ikke behøver logge DHCP pakkerne.
Når man kommer lidt længere ned i bekendtgørelsen viser der sig til gengæld et kæmpe hul. Hvis du har en løsning med NAT skal du ifølge §5 stk 5 logge på ydersiden af din NAT. Brugerinfo logget ifølge §5 stk 2 er åbenlyst registrering af adresser på indersiden af din NAT.
Det betyder altså, at hvis du har NAT i dit netværk og hvis du logger præcist som beskrevet i bekendtgørelsen, kan logfilerne ikke identificere hvilke brugere der har foretaget hvilken kommunikation.
En løsning til at logge data skal ikke ændre på flowet af data. Med andre ord, hvis ikke du ville have sat en proxy op alligevel, så skal du heller ikke sætte en proxy op for at løse denne opgave.
I stedet ville jeg anvende tcpdump eller lignende værktøj. For TCP er det nok at dumpe pakker med SYN, FIN eller RST bit sat.
For UDP og UDPlite er der ikke noget sessionsbegreb, således er der ingen pakker som opfylder kravene i §5 stk 1. Der kan selvfølgelig implementeres protokoller ovenpå UDP eller UDPlite, som har et sessionsbegreb. Men der står ikke eksplicit hvilket protokolniveau der skal logges på. Men da der omtales portnumre er der implicit sagt at det er UDP/TCP niveau.
Resultatet er at det er et fortolkningsspørgsmål hvorvidt UDP overhovedet skal logges.
Det er ikke teknisk muligt at implementere et system der kender alle protokoller der kan køres over UDP. Og det er heller ikke teknisk muligt at implementere et system der kender alle de protokoller man kan køre over IP. Desuden er der mange af dem som ikke gør brug af portnumre, og man kan ikke logge et portnummer for en protokol der ikke har et.
Hvis du har et system hvor det ikke er teknisk muligt at logge oplysninger som beskrevet i stk 1 er det så vidt jeg kan læse ikke noget problem. Der står ikke noget om at man skal ændre sit net for at gøre det muligt, i stedet skal man som beskrevet i stk 4 logge hver 500. pakke, hvis det ikke er teknisk muligt at logge som beskrevet i stk 1.
Men man skal stadig logge de samme oplysninger fra pakken. Og man kan stadig ikke logge oplysninger, der ikke findes. Så man er nødt til at tolke kravet sådan at man skal logge portnummer hvis et sådan findes i protokollen, ellers ville bekendtgørelsen jo have været noget vrøvl.
Det vil sige at man nok i sidste ende er nødt til at logge TCP pakker med SYN, FIN eller RST sat og derudover logge hver 500. pakke for alle andre protokoller. Lige det med hver 500. pakke ved jeg ikke om tcpdump kan, men iptables kan.
Derudover kunne man argumenter for at DHCP pakker også initierer og afslutter sessioner på et andet niveau. Man kunne derfor argumentere for at alle DHCP pakker burde logges. Til gengæld indeholder DHCP serveren sandsynligvis en log med tilstrækkelige oplysninger om DHCP til at man ikke behøver logge DHCP pakkerne.
Når man kommer lidt længere ned i bekendtgørelsen viser der sig til gengæld et kæmpe hul. Hvis du har en løsning med NAT skal du ifølge §5 stk 5 logge på ydersiden af din NAT. Brugerinfo logget ifølge §5 stk 2 er åbenlyst registrering af adresser på indersiden af din NAT.
Det betyder altså, at hvis du har NAT i dit netværk og hvis du logger præcist som beskrevet i bekendtgørelsen, kan logfilerne ikke identificere hvilke brugere der har foretaget hvilken kommunikation.
#4 > Mange tak for det udførlige svar.
Lad os så sige, at jeg ikke vil have en proxy, men blot en løsning, der for så vidt lever op til dele af logningsbekendtgørelsen, der rent faktisk giver mening (selvom jeg ikke mener, bekendtgørelsen er skabt af raske mennesker i første omgang).
Hvad skal der så købes, og hvordan skal det rent teknisk implementeres?
Lad os så sige, at jeg ikke vil have en proxy, men blot en løsning, der for så vidt lever op til dele af logningsbekendtgørelsen, der rent faktisk giver mening (selvom jeg ikke mener, bekendtgørelsen er skabt af raske mennesker i første omgang).
Hvad skal der så købes, og hvordan skal det rent teknisk implementeres?
Logningen er efter min mening ret trivielt at lave. Problemet er nærmere, hvordan man vil sikre hvilken bruger der står bag en given udveksling af data på et given tidspunkt.
Dette har jeg ikke kunne finde en god løsning på, men måske skal man slet ikke indsamle oplysninger omkring dette?
Dette har jeg ikke kunne finde en god løsning på, men måske skal man slet ikke indsamle oplysninger omkring dette?
#7 Jeps, men spørgsmålet er jo hvordan du sikre at brugeren ikke sniffer andre maskiners MAC og IP nummer, spoofer det og dermed bruger en andens bruger identitet til at lave ugerninger på internettet :)
#0 skal være opmærksom på at der skal laves en form for captive portal for at sikre at man har brugerinfo jf. logningsbekendtgørelsen.
Nogen der rent faktisk har lavet sådan et setup?
#0 skal være opmærksom på at der skal laves en form for captive portal for at sikre at man har brugerinfo jf. logningsbekendtgørelsen.
Nogen der rent faktisk har lavet sådan et setup?
Ved nærmere eftertanke har jeg husket lidt forkert. Det man nemt kan med iptables er at logge et bestemt antal pakker per sekund, men hver 500. pakke er ikke helt det samme.kasperd (4) skrev:Lige det med hver 500. pakke ved jeg ikke om tcpdump kan, men iptables kan.
Under alle omstændigheder er det en nem feature at tilføje til enten tcpdump eller iptables. Det nemmeste ville være at modificere tcpdump så man kan give et flag der fortæller at den skal logge hver 500. pakke. Det 499 andre kunne tcpdump så bare tage imod fra kernen og ignorere.
Og nu jeg så faktisk har kigget på dokumentationen kan jeg se at denne feature faktisk allerede er blevet tilføjet til iptables. Man skal bare bruge --every 500.
Første gang en MAC adresse ses kan man hijacke forbindelsen og kræve at brugeren logger på således at identiteten kan registreres.Atom (6) skrev:Logningen er efter min mening ret trivielt at lave. Problemet er nærmere, hvordan man vil sikre hvilken bruger der står bag en given udveksling af data på et given tidspunkt.
Det er en grim løsning og nemt at omgå med MAC spoofing. Men tilsyneladende er det den måde de fleste registrerer brugere på.
Hvis slutbrugerne er forbundet til en unmanaged switch kan man faktisk ikke gøre ret meget andet, med mindre man tvinger brugerne til at anvende en anden protokol. IPSEC eller lignende kunne anvendes, men så er det straks en noget mere besværlig opgave både for administratoren og for brugerne.
Det bedste ville være en switch der kan logge tilstrækkelige oplysninger så man ved hvilken fysisk port der har sendt pakker med en given MAC og/eller IP.
Jo, det fremgår klart af §5 stk 2.Atom (6) skrev:Dette har jeg ikke kunne finde en god løsning på, men måske skal man slet ikke indsamle oplysninger omkring dette?
Tilsyneladende har dem der skrev bekendtgørelsen ikke haft fantasi til at forestille sig carrier-grade-NAT. Hvis der bruges CGN skal man logge hvilken intern IP der er tildelt hver bruger, men for trafikken skal man kun logge eksterne IP adresser.Daniel-Dane (7) skrev:Det er netop idéen med logningsbekendtgørelsen.
Det er for mig fuldstændig ligegyldigt, om det kan misbruges/omgås eller ej. Der skal bare sættes udstyr op, som efterlever lovgivningen.
Jeg kan dertil siges, at hele netværket bruger switche som kan låse en IP-adresse til en bestemt port, således at hver lejlighed ikke kan nappe andre IP'er (medmindre man også kan spoofe dette). Men det er for så vidt ligegyldigt i forhold til lovgivningen.
Jeg kan dertil siges, at hele netværket bruger switche som kan låse en IP-adresse til en bestemt port, således at hver lejlighed ikke kan nappe andre IP'er (medmindre man også kan spoofe dette). Men det er for så vidt ligegyldigt i forhold til lovgivningen.
#9 Jeg er slet ikke med på hvad du mener med "NATens DHCP" ?
Din DHCP server vil da aldrig finde ud af at du overtog en MAC og IP nummer fra en godkendt klient såfremt du kunne sikre at denne ikke længere var forbundet.
At holde øje med hvilken port trafikken kommer fra i switchen vil heller ikke hjælpe hvis man fx. kører trådløs og roamer fra et AP til et andet?
Anyway, til #0
Jeg har ikke fået lavet en løsning til dette som fungerer optimalt men jeg har forsøgt lidt med pfsense som har indbygget captive portal, så det ville være et godt sted at starte hvis du vil lave noget selv. Ellers findes der hostede løsninger som man kan betale sig fra at benytte.
Din DHCP server vil da aldrig finde ud af at du overtog en MAC og IP nummer fra en godkendt klient såfremt du kunne sikre at denne ikke længere var forbundet.
At holde øje med hvilken port trafikken kommer fra i switchen vil heller ikke hjælpe hvis man fx. kører trådløs og roamer fra et AP til et andet?
Anyway, til #0
Jeg har ikke fået lavet en løsning til dette som fungerer optimalt men jeg har forsøgt lidt med pfsense som har indbygget captive portal, så det ville være et godt sted at starte hvis du vil lave noget selv. Ellers findes der hostede løsninger som man kan betale sig fra at benytte.
Atom (12) skrev:Jeg har ikke fået lavet en løsning til dette som fungerer optimalt men jeg har forsøgt lidt med pfsense som har indbygget captive portal, så det ville være et godt sted at starte hvis du vil lave noget selv. Ellers findes der hostede løsninger som man kan betale sig fra at benytte.
Selve teknikken bag bliver formentlig ikke det store problem. Jeg ville sådan set bare vide, hvad hardwarespecifikationerne til en sådan maskine skulle være. Men man kan få routeren til at dumpe hele lortet til en maskine, som så tager sig af det?
Atom (12) skrev:#9 Jeg er slet ikke med på hvad du mener med "NATens DHCP" ?
NAT = router. Sorry.
Atom (12) skrev:Din DHCP server vil da aldrig finde ud af at du overtog en MAC og IP nummer fra en godkendt klient såfremt du kunne sikre at denne ikke længere var forbundet.
Præcis. Det kræver netop, at den anden computer ikke er på nettet samtidig. Men sletter DHCP-serveren ikke klienten (og dertilhørende IP-adresse) fra listen, når sessionen ophører?
arne_v (15) skrev:#11
Så er dit problem vel mere et præcedens problem end et teknisk problem.
Du har brug for at høre hvad de gør andre steder. Så kan du implementere det og du kan til enhver tid hævde at du gør som alle andre.
Hvordan det virker er ligegyldigt.
Korrekt. Jeg skal bare brug en løsning der billigst muligt opfylder lovens betingelser uden at blive en flaskehals.
Er der indenfor "udbyderens eget net" en enhed der foretager NAT? Eller leverer du en global IP adresser til hver enkelt bruger?Emil (11) skrev:Det er for mig fuldstændig ligegyldigt, om det kan misbruges/omgås eller ej. Der skal bare sættes udstyr op, som efterlever lovgivningen.
Hvis der indgår NAT er du nødt til at vælge om du vil foretage logning som beskrevet i bekendtgørelsen eller logning som de havde tænkt sig at det skulle gøres. Eller om du vil ofre resourcerne på at logge både det ene og det andet.
Uanset hvordan du gør vil der den dag logfilerne skal bruges nok også stå en advokat parat til at misfortolke bekendtgørelsen på en måde der kan vise at du har gjort det forkert, så hvis det sker får du nok selv brug for en advokat der kan dokumentere at du har gjort det rigtigt.
Det gør tingene lidt nemmere. Er der så også en DHCP server som kan sikre at brugerne får tildelt en IP adresse som er tilladt på den port de er forbundet til? Eller skal brugerne konfigurere deres computers IP manuelt?Emil (11) skrev:Jeg kan dertil siges, at hele netværket bruger switche som kan låse en IP-adresse til en bestemt port
Hvis du har IP adresser nok, og hvis switchene kan konfigureres til det, ville jeg give hver port et interval af adresser, så brugerne kan tilslutte en switch og flere computere uden at skulle introducere endnu et niveau af NAT.
Hvis du laver NAT for brugerne har du adresser nok til at du kunne give 65536 adresser til hver bruger. Hvis du ikke laver NAT har du sandsynligvis kun adresser nok til at give en til hver bruger.
Skal løsningen i sætter op nu være klar til IPv6? Eller regner i med at få penge til en ny logningsløsning når I får brug for at opgradere til IPv6?
Hvis man følger bekendtgørelsen burde man være på den sikre side uanset hvad andre gør. I de fleste tilfælde vil der sikkert ikke være nogen CGN løsning, hvilket vil sige at det punkt jeg rejste omkring interne/eksterne adresser ikke har noget at sige. Vi har ikke fået svar på om det konkrete system anvender en CGN løsning.arne_v (15) skrev:Du har brug for at høre hvad de gør andre steder. Så kan du implementere det og du kan til enhver tid hævde at du gør som alle andre.
Jeg ved ikke om der overhovedet findes præcedens for hvordan det gøres på et netværk med CGN.
Jeg tror en fit PC2i er tæt på at være hurtig nok. Jeg vil lige prøve at smide en test op til at måle hvor hurtigt man kan få data gennem sådan en fætter.Emil (16) skrev:Jeg skal bare brug en løsning der billigst muligt opfylder lovens betingelser uden at blive en flaskehals.
#17 > P.t. er der offentlige IP v4-adresser til samtlige lejligheder, men der ønskes i stedet en løsning med én fælles IP-adresse og internt NAT, hvor hver lejlighed tilbydes en range på ~10 lokale IP-adresser. Det gør det lettere at sikre, at folk ikke sætter FTP-servere op og what not.
De 10 IP'er bliver naturligvis låst til én bestemt port i én bestemt switch.
De 10 IP'er bliver naturligvis låst til én bestemt port i én bestemt switch.
kasperd (18) skrev:Jeg tror en fit PC2i er tæt på at være hurtig nok. Jeg vil lige prøve at smide en test op til at måle hvor hurtigt man kan få data gennem sådan en fætter.
Den nuværende router er en Intel Xeon CPU 3040, 1.86GHz med 1 GB ram, så den har lidt år på bagen, men den burde da være hurtigere end sådan en PC2i?
Resultaterne jeg fik ud af det er desværre mærkelige. Jeg testede først at de to computere jeg ville have til at kommunikere kunne klare mellem 600 og 990 Mbit/s i begge retninger på samme tid. Det var gennem tre switches.kasperd (18) skrev:Jeg tror en fit PC2i er tæt på at være hurtig nok. Jeg vil lige prøve at smide en test op til at måle hvor hurtigt man kan få data gennem sådan en fætter.
Dernæst satte jeg min fit PC2i ind imellem og satte den op så den opførte sig som en switch. Hvis jeg kun sendte trafik den ene vej gennem kunne jeg få 400Mbit/s i den ene retning og 500Mbit/s i den anden retning. Men hvis jeg sendte begge retninger på samme tid faldt hastigheden til 30-70Mbit/s.
Hvad der var endnu mere underligt var at en top kommando jeg kørte på denne fit PC2i indikerede en belastning på under 10%. Og der var ingen indikation af belastning noget som helst sted. ping viste en helt fin roundtrip og ingen af maskinerne er belastet.
Desværre har jeg ikke lige nogen anden computer ved hånden med to 1Gbit/s interfaces, så jeg kan ikke lave nogen sammenligning.
Der kommer til at gå et par uger før jeg har mulighed for at gentage testen på en anden computer med to 1Gbit/s interfaces.
Det er en forkert måde at gøre det på. For det første giver NAT tonsvis af problemer, og hvis du endeligt vil filtrere trafikken er det bedre at gøre det uden NAT. For det andet vil du også komme til at spærre for mange legitime anvendelser. For et tredje finder de såmænd nok en måde at sætte en FTP server op alligevel.Emil (19) skrev:P.t. er der offentlige IP v4-adresser til samtlige lejligheder, men der ønskes i stedet en løsning med én fælles IP-adresse og internt NAT, hvor hver lejlighed tilbydes en range på ~10 lokale IP-adresser. Det gør det lettere at sikre, at folk ikke sætter FTP-servere op og what not.
Det skal den være. Hvis ikke kravene står deri, så er de jo ikke gældende.arne_v (20) skrev:Men er den præcis nok til at man kan afgøre om en løsning opfylder kravene baseret på ren teknik?
kasperd (22) skrev:Det er en forkert måde at gøre det på. For det første giver NAT tonsvis af problemer, og hvis du endeligt vil filtrere trafikken er det bedre at gøre det uden NAT. For det andet vil du også komme til at spærre for mange legitime anvendelser. For et tredje finder de såmænd nok en måde at sætte en FTP server op alligevel.
Hvordan vil de sætte en FTP-server op, hvis der ikke er en åben port til deres lejlighed?
Hvilke legitime anvendelser vil blive spærret?
Hvordan kan jeg filtrere trafikken? De kan jo bare kryptere den, så er den umulig at filtrere.
Emil (23) skrev:Hvordan vil de sætte en FTP-server op, hvis der ikke er en åben port til deres lejlighed?
Jeg tror, de vil blive pænt irriteret, hvis I spærrer port 80 ind og ud.
Daniel-Dane (24) skrev:Jeg tror, de vil blive pænt irriteret, hvis I spærrer port 80 ind og ud.
Fordi der er åbent på port 80, er der ikke nødvendigvis redirected port 80 til en NAT IP? At tillade trafik på en port, er ikke det samme som de kan sætte en server op selv.
#26
Det forstår jeg ikke. Siger du, at man kan blokere for FTP-trafik igennem en HTTP-tunnel? Edit: Wait. I think I see now.
Det forstår jeg ikke. Siger du, at man kan blokere for FTP-trafik igennem en HTTP-tunnel? Edit: Wait. I think I see now.
Kontrolforbindelsen bruger så lidt kapacitet, at den kan man nemt få hostet et andet sted og køre gennem en krypteret tunnel. Data kan man køre gennem en udgående forbindelse.Emil (23) skrev:Hvordan vil de sætte en FTP-server op, hvis der ikke er en åben port til deres lejlighed?
En FTP server har mange legitime anvendelser. Det kunne f.eks. være backup af feriebilleder.Emil (23) skrev:Hvilke legitime anvendelser vil blive spærret?
Det var dig der startede med at sige du ville filtrere FTP ved at bruge NAT.Emil (23) skrev:Hvordan kan jeg filtrere trafikken? De kan jo bare kryptere den, så er den umulig at filtrere.
NAT er en (dårlig) workaround for for få adresser. Hvis ikke du har et problem med for få adresser, så skal du ikke bruge NAT.
Hvis du har et andet problem, så findes der en bedre løsning. Men jeg ved ikke hvad det er for et problem du prøver på at løse.
kasperd (28) skrev:Kontrolforbindelsen bruger så lidt kapacitet, at den kan man nemt få hostet et andet sted og køre gennem en krypteret tunnel. Data kan man køre gennem en udgående forbindelse.
Hvis folk har adgang til en VPN, så er der ikke det store, man kan gøre, men eftersom det er de færreste, der har den mulighed, og ligeledes har adgang til en VPN, der kan banke afsted med 200/200 Mbit, så bliver det nok ikke noget problem.
Problemet bliver folk, der synes de skal starte deres egen serverfarm hjemme fra lejligheden. Da jeg dårligt kan se, om de sætter en FTP op med 10 TB film i et stort piratnetværk, eller om de bruger den til backup af mor og fars familiebilleder, så er det letteste ikke at tage chancen.
kasperd (28) skrev:Hvis du har et andet problem, så findes der en bedre løsning. Men jeg ved ikke hvad det er for et problem du prøver på at løse.
Jeg har et netværk, hvor jeg skal logge hver enkelt IP's forbindelser til internettet på den billigste måde uden at selve logningen skaber en flaskehals for trafikken. Simple as that.
BlackFalcon (31) skrev:#1
Jeg har god erfaring med at outsource opgaven. Fx. kontakt dem her: link
Mange tak for det. Jeg har haft kontakt til dem nu, men de specialiserer sig mest i campingpladser og ligende, så en løsning med 250 faste, daglige brugere ville løbe op i 2-3000 kr. om måneden pga. den enorme mængde plads, logningen fylder, samt backup og vagttelefon i forbindelse med opkald fra Politiet.
Kontrolforbindelsen skal jo ikke bruge 200Mbit/s.Emil (30) skrev:og ligeledes har adgang til en VPN, der kan banke afsted med 200/200 Mbit
Hvis først du har besluttet at du hellere vil blokere legitim trafik end at lade noget uønsket slippe igennem, så kan du jo lige så godt slukke for dit netværk.Emil (30) skrev:så er det letteste ikke at tage chancen.
Hvad er det for et problem du prøver på at løse?
Den opgave er nemmere at løse uden NAT.Emil (30) skrev:Jeg har et netværk, hvor jeg skal logge hver enkelt IP's forbindelser til internettet på den billigste måde uden at selve logningen skaber en flaskehals for trafikken.
Jeg må indrømme, at jeg har glemt navnet på det firma jeg egentlig havde i tankerne, så jeg googlede ovenstående. Jeg benyttede mig af et firma for ca. ~3 år siden. De var bosat i København og de havde specialiseret sig i løsninger til hoteller m.v. De kørte helt til Sønderborg for at montere deres boks - god service og prisen var svjh. cirka 500/md.
#Emil
Du har ikke skrevet har det er for nogen 250 bruger du har. Så jeg går ud fra at det er kollegiet-lejligheder.
Forslag:
Sæt hver lejlighed på hver sit VLAN. Hver lejlighed bliver tildel en /24 i RFC1918, som bliver nattet til en fast global IP for hver lejlighed. Det hele bliver routet/nattet i en linuxbox, hvor connection-tracking bliver logget.
Så har du:
* Fuld logging af alle forbindelser
* 1:1 mapping i mellem lejlighed og global IP
* Ingen triks imellem lejlighederne.
Bonus:
Sæt IPv6 op, og tildel en /64 til hver lejlighed.
Du har ikke skrevet har det er for nogen 250 bruger du har. Så jeg går ud fra at det er kollegiet-lejligheder.
Forslag:
Sæt hver lejlighed på hver sit VLAN. Hver lejlighed bliver tildel en /24 i RFC1918, som bliver nattet til en fast global IP for hver lejlighed. Det hele bliver routet/nattet i en linuxbox, hvor connection-tracking bliver logget.
Så har du:
* Fuld logging af alle forbindelser
* 1:1 mapping i mellem lejlighed og global IP
* Ingen triks imellem lejlighederne.
Bonus:
Sæt IPv6 op, og tildel en /64 til hver lejlighed.
Altså, hvis beboerne har brug for at udveksle filer med hinanden tvinger man trafikken ud over det 200Mbit/s link, som er flaskehalsen for alt trafik ud af huset. Jeg ved ikke hvor meget trafik der er mellem beboerne, men det lyder upraktisk at tvinge trafik ud på en omvej over et link som sandsynligvis er mere belastet.CableCat (35) skrev:* Ingen triks imellem lejlighederne.
Man burde få et /48 netværk fra sin udbyder og derfra kunne tildele /56 til hver lejlighed. De fleste kan sikkert nøjes med /60 eller /64, men hvis man alligevel har et /48 er der ikke meget grund til kun at give /64 til hver lejlighed.CableCat (35) skrev:Sæt IPv6 op, og tildel en /64 til hver lejlighed.
CableCat (35) skrev:Sæt hver lejlighed på hver sit VLAN. Hver lejlighed bliver tildel en /24 i RFC1918, som bliver nattet til en fast global IP for hver lejlighed. Det hele bliver routet/nattet i en linuxbox, hvor connection-tracking bliver logget.
Bedste forslag so far.
Det kommer an på detaljerne i opsætningen, det var fra forslaget ikke helt klart hvordan NAT ville blive sat op.Atom (38) skrev:Man tvinger vel kun trafikken igennem routeren
Hvis NAT håndterer hver port separat og der ikke kan kommunikeres mellem portene uden NAT bliver man nødt til at gå gennem en ekstern service.
Hvis NAT sker på ydersiden og der blot vælges forskellig adresse afhængig af hvilken port trafikken kom fra kan der stadig kommunikeres mellem portene uden at gå gennem NAT, og så er der intet performance problem ved kommunikation mellem beboerne.
Det ændrer dog ikke på at man hverken har gjort sig klart hvad det er for et problem man prøver at løse eller hvad den løsning man har valgt kan bruges til.
En dag jeg har god tid og et passende netværk at eksperimentere med må jeg lave mig den nødvendige software til at køre en FTP server bagved NAT. Det er der sikkert mange, som kan bruge.
Med "Ingen triks imellem lejlighederne" mener jeg at det ikke er muligt at lave arp eller DHCP fusk, da brugerne ikke er på samme layer 2 netværk. Trafikken imellem lejlighederne skal selvfølgelig ikke igennem NAT, men bare routes.
Med IPv6, om man skal tildele mere end /64: Det vil komme til at fungere på den måde at man kan få ekstra netværk via DHCP. Se RFC 3633. Så det man skal gøre er at man give en "kunde" et /64 netværk, og så kan kunden få flere via DHCP. Det oprindelige /64 vil således blive bruget som et slags routenet.
Med IPv6, om man skal tildele mere end /64: Det vil komme til at fungere på den måde at man kan få ekstra netværk via DHCP. Se RFC 3633. Så det man skal gøre er at man give en "kunde" et /64 netværk, og så kan kunden få flere via DHCP. Det oprindelige /64 vil således blive bruget som et slags routenet.
Det vil selvfølgelig være en fornuftig løsning. Det kræver så at man logger hvilke prefix der er tildelt hvilke lejligheder, samt at man sikrer at de ikke kan bruge andre prefixes.CableCat (40) skrev:Det vil komme til at fungere på den måde at man kan få ekstra netværk via DHCP.
Det angiver hvor mange bits af adressen netværksdelen udgør. De resterende bits vil være host delen.Emil (41) skrev:Lige for at være helt sikker, betyder /24 og /64 så?
/0 betyder kort sagt hele Internettet, og derfra kan der underinddeles i mindre netværk. /24 betyder altså en 16777216. del af Internettet.
Med IPv6 er en typisk inddeling at en udbyder tildeles et /32 netværk som de underinddeler i /48 og /56 netværk som de tildeler til deres kunder. Når der er tale om flere lejligheder skal man selvfølgelig have et /48 netværk.
Når du får /48 fra din udbyder kan du give /56 til hver lejlighed (56-48=8, så et /48 kan inddeles i 256 /56 netværk). Beboerens egen router kan så inddele det /56 i /64 efter behov.
Med IPv6 underopdeler man normalt sine netværk indtil man når ned på /64, det betyder at de resterende 128-64 bits er host adressen. Nogle af protokollerne for tildeling af adresser kræver at man bruger denne 64+64 opdeling.
Men som #40 er inde på tildeler man i første omgang /64 og så tildeler man kun mere hvis beboeren selv har en IPv6 router som kan håndtere inddelingen.
Lad os f.eks. antage at din udbyder giver dig 2001:db8:1e6d::/48. Og lad os antage at lejlighederne er nummereret fra 1 til 250. Så kan du tildele 2001:db8:1e6d:0100::/56 til lejlighed 1, 2001:db8:1e6d:0200::/56 til lejlighed 2, osv. op til 2001:db8:1e6d:fa00::/56 som tildeles lejlighed 250. Disse adresser tildeles beboernes routere med DHCPv6.
2001:db8:1e6d:0000::/56 har du ikke brugt endnu, det kan du dele op i et /64 til hver lejlighed, som du så bruger til segmentet udenfor beboerens egen router(e). Det vil sige 2001:db8:1e6d:0001::/64 til lejlighed 1, 2001:db8:1e6d:0002::/64 til lejlighed 12 2001:db8:1e6d:00fa::/64 til lejlighed 250.
2001:db8:1e6d:fb00::/56 og 2001:db8:1e6d:fc00::/54 er endnu ikke tildelt noget, så der er rigeligt at tage af til infrastrukturen.
Med IPv4 har du ikke adresser nok til en så pæn opdeling.
Det kan være du har 192.0.2.0/24 tildelt fra din udbyder. Der kan du så bruge 192.0.2.1 til lejlighed 1, 192.0.2.2 til lejlighed 2, 192.0.2.250 til lejlighed 250.
Hver beboer kan så have en router der foretager NAT for deres eget netværk, hvis de har brug for mere end en enkelt computer.
Hvis mange beboere har brug for mere end en enkelt computer hver, og nem kommunikation internt mellem beboerne er vigtigere end nem kommunikation med omverdenen, så kan du rykke NAT funktionen ud til en central router mellem dit netværk og omverdenen.
Så kan du bruge 10.0.0.0/8 til det interne netværk. Tildel 10.1.0.0/16 til lejlighed 1, 10.2.0.0/16 til lejlighed 2, 10.250.0.0/16 til lejlighed 250. Du vil stadig kunne bruge samme tildeling af IPv4 adresser som skitseret ovenfor, så hver lejlighed stadig ses med en enkelt IPv4 adresse, når de kommunikerer med omverdenen.
Hvis der er beboere som har brug for adgang uden NAT kan du så fortælle dem, at de må bruge IPv6.
Men du kunne også lave en hybrid løsning, hvor de har IPv4 adgang både med og uden NAT. Den første computer fra hver lejlighed får 192.0.2.x, resten får en adresse fra 10.0.0.0/8. Kommunikation mellem de eksterne og de interne adresser skal selvfølgelig ikke gennem NAT. Og når en ekstern adresse kommunikerer med omverdenen skal den heller ikke gennem NAT. Når en intern adresse kommunikerer med omverdenen skal den gennem NAT.
192.0.2.251-192.0.2.254 har vi ikke defineret endnu, de kunne være en router adresse og 3 adresser til en NAT pool.
Nogen vil så mene at du skal logge mappings som denne NAT foretager, men det har de glemt at skrive i bekendtgørelsen, så det er du egentlig ikke nødt til.
Emil skrev:Lige for at være helt sikker, betyder /24 og /64 så?
Lige den simple forklaring:
/24 i IPv4 = 10.12.34.0/255.255.255.0 = 10.12.34.*
Her beskriver de første 24bits netværket og de sidste 8bit er hosten. Antal IP'er i netværket = 2^8 = 256.
/64 i IPv6 = 1111:2222:3333:4444:****:****:****:****
Dette er standart størrelsen på ét netværk. Det er kun i få tilfælle man vil bruge andet end /64.
Her er et link til en video der foklare netmask og hvad en /24 er:
www.youtube.com/watch?v=FxfNGou9u30#t=56m50s
www.youtube.com/watch?v=FxfNGou9u30#t=56m50s
Lidt mere præcist sagt, så er det standardstørrelsen på et netværkssegment.CableCat (45) skrev:Dette er standart størrelsen på ét netværk.
Et netværk bestående af mere end et segment vil have et prefix der er kortere end 64 bits. Resten af bittene op til 64 vil så være en selector, der angiver hvilket segment adressen tilhører.
Hvis der anvendes Ethernet kaldes et segment også for et broadcast-domæne. Hvis der mellem to computere blot er en række switches, så er de på samme segment. Hvis trafikken mellem to computere skal gennem en router, så er de på forskellige segmenter.
Det er kun i få tilfælle man vil bruge andet end /64.I stort set alle tilfælde er /64 den rigtige størrelse til et segment. Der er hørt om personer, der gerne vil spare på IPv6 adresserne og derfor kun tildeler /124, /126 eller /127 når de laver et point-to-point link.
Den type besparelser er ret meningsløse på nuværende tidspunkt. At skulle køre IPv4 og IPv6 parallelt er kompliceret nok, der er ingen grund til at gøre det mere besværligt ved at spare på IPv6 adresserne.
På nuværende tidspunkt er det langt vigtigere at få skiftet til IPv6 end at spare på IPv6 adresserne. I øjeblikket har IANA kun lov til at dele ud af 2000::/3. Selv hvis hver person får et /48 netværk til deres bolig, så er 2000::/3 stort nok til at når engang 2000::/3 er brugt op vil IPv6 netværket være så mange gange større IPv4 netværket, at man er nødt til at være på IPv6 netværket. Og til den tid kan man droppe IPv4 netværket helt.
Hvis det nogensinde bliver nødvendigt at give IANA lov til at dele ud af 4000::/3, så bliver der nok strammet op på brugen af IPv6 adresser. Og da vil man nok skulle vænne sig til at man kommer til at have netværk med prefixes på 72 eller 76 bits og en ny måde at tildele de sidste 56 eller 52 bits på.
Men hvis det sker, så vil det stadigvæk være simplere at have med at gøre, end det vi har i dag, fordi man er fri for IPv4 og NAT.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Hardware
Gå til bund