Allokering av båndbredde

[simrem]

Når en bruker deler noe, kan mange laste ned fra den brukeren samtidig. Da brukes det 1 port per opplasting. Dermed skjer dette over flere tilfeldige porter.

 

Fant et bilde på google for å vise det jeg mener:

http://feelfree.ee/uploads/programmid/BitLord_0.56.exe.jpg

[simrem]

*klarte å legge til svaret to ganger*

Endret 5. desember 2006 av SIR83

[Langbein]

Uansett må bittorrent-programmet bruke en spesifikk port for å kunne kommunisere eksternt. Men bittorrent bruker bare en port, og det gjør den enkel å kontrollere.

7431284[/snapback]

Alle oppegående bittorrent-klienter lar deg selv velge hvilken port den skal lytte på. Hvis de andre brukerne man laster ned/opp til også bruker alternative porter, vil ikke noe av trafikken foregå på en standard port. Kanskje unntatt trafikk mot trackeren, men det er jo veldig lite da (statistikk, oppdatere liste over peers osv)

[stigfjel]

Uansett må bittorrent-programmet bruke en spesifikk port for å kunne kommunisere eksternt. Men bittorrent bruker bare en port, og det gjør den enkel å kontrollere.

7431284[/snapback]

Alle oppegående bittorrent-klienter lar deg selv velge hvilken port den skal lytte på. Hvis de andre brukerne man laster ned/opp til også bruker alternative porter, vil ikke noe av trafikken foregå på en standard port. Kanskje unntatt trafikk mot trackeren, men det er jo veldig lite da (statistikk, oppdatere liste over peers osv)

7431419[/snapback]

Jeg kjører bittorrent-klienten min på en ikke-standard port. Og det fungerer strålende. Bare setter opp nat og rdr-regler på OpenBSD-boksen min, og alt fungerer som det skal.

 

Edit: akkurat det samme kan jeg gjøre med DirectConnect.

 

Edit edit: bare pass på at du får med deg UDP-porten. Det enkleste er å bruke samme portnummer på UDP-trafikken for samme tjeneste.

Endret 5. desember 2006 av stigfjel

[kyrsjo]

Jada, ikke noe er et problem så lenge man har kontroll på både ruteren og klientene bak den Problemet er at her har man ikke kontroll på klientene, og disse vil kansje prøve å snike seg rundt restriksjoner du legger...

[Langbein]

Jepp, det var derfor jeg skrev at man har kommandoen tc som brukes nettopp til traffic shaping

7430604[/snapback]

Men PF har denne funksjonen innebygget, så man vil ikke trenge å lære seg å bruke en kommando i tillegg til pakkefilteret. Hele brannmur-konfigurasjonen vil være på ett sted.

Poenget mitt var at linux-kjernen også har slikt innebygget. Iptables er strengt tatt bare en kommando for å manipulere netfilter. Skal man drive med mer avansert ruting og firewalling, må man uansett forholde seg til flere kommandoer, også på *BSD.

 

Forøvrig tror jeg nok at man har en del flere muligheter med netfilter enn PF når de gjelder selve filtreringen. F.eks er det mulig å filtrere på MAC-adresser, noe jeg ikke tror går med PF. De obskure patchene er ikke så skumle heller, men er heller ikke nødvendig for de fleste brukere. Noen kan likevel ha glede av dem, fordi de tillater enda mer spesialiserte måter å filtrere eller NAT'te på. Kan være nyttig hvis man må forholde seg til veldig skitne protokoller. Ellers tror jeg mye slik funksjonalitet etterhvert har funnet veien inn i netfilter, slik at patching sjelden vil være nødvendig.

 

Det er selvsagt også mulig å sette opp load balancing.

 

Ellers tviler jeg ikke på at enkelte oppgaver kan være enklere med PF/OpenBSD.

Endret 5. desember 2006 av Langbein

[stigfjel]

Jada, ikke noe er et problem så lenge man har kontroll på både ruteren og klientene bak den Problemet er at her har man ikke kontroll på klientene, og disse vil kansje prøve å snike seg rundt restriksjoner du legger...

7431450[/snapback]

Så lenge man setter en default-to-deny policy er det ikke så mye man kan gjøre. Man kan også sette opp AuthPF. Det fungerer på den måten at brukeren må koble seg til brannmuren via SSH for å kunne komme igjennom brannmuren. Hvis brukeren gjør noe brukeren ikke skal gjøre, er det bare å svarteliste brukeren, så vil brannmuren effektivt stoppe alle pakker fra den svartelistede brukeren. Blokkeringen skjer på routing-nivå.

[simrem]

Jeg har ikke kontroll over klientene på nettverket (ca 50 stk).

Vil helst ikke legge så store restriksjoner på nettverket.

Det er viktig at fildelings-trafikk blir nedprioritert, slik at de som gjør mer formålstjenlige oppgaver på nettverket kan få prioritet for å laste opp.

[stigfjel]

Jeg har ikke kontroll over klientene på nettverket (ca 50 stk).

Vil helst ikke legge så store restriksjoner på nettverket.

Det er viktig at fildelings-trafikk blir nedprioritert, slik at de som gjør mer formålstjenlige oppgaver på nettverket kan få prioritet for å laste opp.

7433612[/snapback]

Det du kan gjøre, er å opprette en port-range bestående av maks 10 porter. Det kan man få til ved bruk av makroer. Og så kan man strupe båndbredden på disse portene. Vanskeligere er det ikke. Og så gjør du brukerne oppmerksomme på at f.eks. bittorrent samt andre fildelingstjenester KUN vil fungere på disse portene og at du kun tillater fildelingstjenester som bare krever en spesifikk port.

[kyrsjo]

Sammarbeid-med-brukerene modellen jeg foreslo.

 

Evt. kan du priorietere web, mail, ntp, ssh, rdp og kansje et par til, og "by default" strupe alt som ikke faller innenfor disse.

 

Store filer på web, skal du ha noe struping på disse? squid kansje?

[stigfjel]

På et slikt nettverk, hvis det er snakk om 50 brukere, så kan squid være hensiktsmessig.