Aktualizacja paczek: 26.05.2012 (dzień Matki :D) - zobacz listę zmian (kliknij)

Jeśli szukasz odpowiedzi na jakieś pytanie to zajrzyj do FAQ (kliknij) lub na forum dyskusyjne (kliknij) zanim mi je zadasz

Jeśli chcesz przejść dalej musisz najpierw wbić sobie do głowy, że potrafisz:

• zainstalować Debiana 6 (squeeze) w wersji netinstall
• sprawdzić czy adres IP, który masz umożliwi Ci dostęp do Internetu
• czytać i postępować tak jak  jest tu napisane :]

KROK 1 - Ala ma komputer

Wymagania co do komputera są proste. Po pierwsze musi mieć twardy dysk, CD-ROM, koło 256MB RAM oraz działać po włączeniu zasilania oraz musi umieć zbootować się z płytki CD. Upewnij się, że posiadasz zamontowane dwie karty sieciowe. Jeśli masz sieć powyżej 50 użytkowników - zainteresuj się komputerem z 2 corami oraz przynajmniej 1 GB ramu.

KROK 2 - Komputer ma linuxa

Na początku przygotuj sobie adresację IP (adres, maska, brama, dns), na której będziesz miał dostęp do Internetu. Zainstaluj Debiana 6 (Squeeze) w wersji amd64 (pobierz) lub i386 (pobierz) po wcześniejszym wypaleniu obrazów na CD. Jeśli tylko Twój sprzęt obsługuje wersję 64-bitową - gorąco ją polecam. Podczas instalacji wybierz interfejs eth0 jako główny oraz wpisz POPRAWNIE adresację tak, aby instalator miał dostęp do Internetu. Ten krok prawdopodobnie powtórzysz kilka razy jeśli nie robiłeś tego wcześniej Przy wyborze oprogramowania zaznacz jedynie "System podstawowy" i "Serwer SSH". Środowisko graficzne, które domyślnie jest zaznaczone nie będzie Ci do niczego potrzebne. Jeśli nie wiesz, co odpowiedzieć na pytania instalatora - wybierz potwierdzenie lub wpisz cokolwiek. Bezpośrednio po instalacji zaloguj się na konto użytkownika root z hasłem, które podałeś podczas instalacji oraz wykonaj następujące polecenia:

apt-get update && apt-get upgrade

Jeśli nie masz programu puTTy to ściągnij go stąd (kliknij). Odpal i połącz się poprzez SSH z adresem IP, który podałeś podczas instalacji systemu. W zależności od języka i zestawu znaków (tzw. locales) wybierz odpowiednie kodowanie znaków (ISO-8859-2 lub UTF-8). Jeśli nie wiesz o co chodzi to po zalogowaniu się wpisz po prostu:

LANG=

Nie polecam przechodzić do dalszego kroku, dopóki wszystko nie zostało zrobione jak powyżej.

Krok 3 - Linux ma paczki

STOP! Instalatory nadpiszą poprzednią wersję bazy LMSa (klienci itd).

Kliknij tutaj aby przejść na forum i pobrać adresy skryptów instalacyjnych.

Po drodze zostaniesz zapytany o kilka spraw, przez instalatora:

• zapytanie o pakiet phpmyadmin - wybierz apache2 - UWAGA - wciśnij spację aby zapaliła się gwiazdka przy zaznaczeniu - to najczęściej powtarzany przez Was błąd i mówicie, że nie działa phpmyadmin Jeśli jesteś już po instalacji to wpisz dpkg-reconfigure phpmyadmin i powtórz krok.
• zapytanie: "Configure database for phpmyadmin with dbconfig-common" - wybierz NIE
• zapytanie o serwer mysql - zapisz na kartce hasło - będzie Ci potrzebne za chwilę ponownie!
• zapytanie o serwer postfix - wybierz Internet Site
• cała reszta pytań - odpowiadasz TAK lub DALEJ

Po zapakowaniu wszystkiego potrzebnego do Twojego komputera system zrobi reboot. Po restarcie maszyny powinieneś mieć gotowy działający router z LMS i zaawansowanym podziałem pasma. W zasadzie jedyne co musisz zmienić to ustawienia parametrów Twojego łącza WAN (DOWNLOAD i UPLOAD - teraz też dodatkowe nocne dla WAN) w pliku:

/serwer/serwer.conf

Hasło do LMS ustawisz sobie podczas pierwszego logowania się w przeglądarce po adresem:

http://adres_ip_routera

Instalator wygeneruje losowe hasło do bazy danych zatem nie ma potrzeby jego zmiany.

Krok 4 - Uwagi do bajki

Router posiada następującą funkcjonalność:

• dynamiczny podział pasma na WAN za pomocą IMQ na HTB/esfq z priorytetyzacją usług (plik /serwer/skrypty/htbwan.sh)
• statyczny podział pasma dla klientów sieci LAN za pomocą IMQ na HTB/sfq (plik /serwer/skrypty/htblan.sh)
• firewall odpowiadający za autoryzację klientów po MAC+IP (plik /serwer/skrypty/firewall.sh)
• serwer DHCP dla klientów
• serwer DNS dla kientów
• serwer PPPoE dla LAN oraz PPtP dla LAN i WAN (dostęp zdalny) - nazwa komputera z LMS to login, hasło to PIN klienta jeśli nie zostało zdefiniowane hasło przy danym komputerze
• komunikaty: dla nieautoryzowanych klientów, przypomnienie o płatnościach, blokada dostępu do siec
• panel LMS z autorskim demonem do przeładowywania serwera (katalog /var/www)
• funkcje LMS: klienci, komputery, sieci, urządzenia sieciowe, mapa sieci, taryfy, faktury, helpdesk, terminarz i inne
• userpanel: informacje, faktury i płatności, kontakt poprzez helpdesk z panelem LMS
• taryfy nocne dla LAN i WAN
• przekierowania portów poza LMS
• obsługa dwóch lub więcej łączy WAN (kliknij)
• serwer przeładowuje konfigurację praktycznie natychmiast po wprowadzeniu zmian w LMS (płynność 2-3 sek)
• przykładowe dane konfiguracyjne z opisem
• po więcej informacji zapraszam do FAQ (kliknij)

Jądro (2.6.34), iptables 1.4.8 oraz iproute zostały załatane patchami kolegi DJ Gregora z linuxbox.pl.

Wszelkie powyższe materiały i opisy na stronie oraz wypowiedzi autora na forum stanowią jego własność intelektualną. W szczególności skrypty z katalogu /serwer oraz /var/v-smart oraz wszystkie paczki deb. Autor zezwala na używanie powyższych materiałów w sposób komercyjny i niekomercyjny jednak zabrania modyfikowania ich i umieszczania poza stroną v-smart.pl

Lista zmian dotyczy projektu routera z LMS na Debianie (kliknij), do którego FAQ znajdują się tutaj (kliknij).

26.05.2012

• wersja 2.1 projektu, zajrzyj na forum

01.09.2011

• wersja 2.0 projektu, zajrzyj na forum

07.02.2011

• przystosowanie systemu do Debiana 6 (Squeeze)
• skrypt robiący upgrade Lenny do Squeeze (kliknij)
• inne drobne poprawki funkcjonalności LMSa

15.01.2011

• pożądany artykuł dotyczący dwóch lub więcej łącz WAN (kliknij)

12.01.2011

• skrypt do updatu do najnowszej wersji, zachowujący bazę LMSa
• skrypcik do przekierowania portów do LAN (poza LMS)

11.01.2011 (fajna data w ogóle)

• taryfy nocne dla LAN
• taryfy nocne dla WAN - tego jeszcze nie grali ale to ma głębsze dno

09.01.2011

• uproszczono skrypty w katalogu /serwer
• uruchomiono userpanel
• uruchomiono możliwość wysyłania SPAMu do klientów LMSa
• uruchomiono wymianę informacji helpdesk <-> userpanel

07.01.2011

• obsługa protokołu ppp (PPPoE i PPtP)
• jajko 2.6.34, iptables 1.4.8, iproute 2.6.34
• dodano trzy rodzaje komunikatów z informacjami dla klientów
• dodano automatyczne blokowanie klientów po przekroczeniu określonego ujemnego salda

gdzieś po drodze

• kompilacje i testy nowego jajka 2.6.34
• testy mechanizmów ppp (PPPoE, PPtP)

26.08.2010

• pierwsza wersja projektu
• jajko 2.6.29.4, iptables 1.4.8, iproute 2.6.30
• LMS 1.11 wersja hardcorowa testowa

Opis znajdujący się poniżej operuje na jednej dodatkowej tabeli routingu. Lepsze podejście znajdziecie na forum (klik).

Dla uproszczenia sprawy obczajmy najpierw system do zarządzania routerem w wersji podstawowej, którego w miarę pełny i aktualizowany na bieżąco opis znajdziecie tutaj (kliknij). Po instalacji powinniśmy mieć dwie karty sieciowe w kompie czyli 1xWAN i 1xLAN. Następnie dokładamy kolejny interfejs (karta sieciowa, śledzik czy jak to tam zwą) do maszynki, który w systemie przyjmie po restarcie nazwę eth2. Podczas dalszego pisania bajki o multi-wan będziemy wykonywać następujące kroki niezależnie od oczekiwanego efektu końcowego:

• przypisanie adresacji IP do nowego łącza WAN oraz utworzenie kolejnego interfejsu IMQ dla HTB
• utworzenie tablicy routingu dla nowego łącza (sprawa konieczna absolutnie) oraz reguł routingu opartych o markowanie pakietów/połączeń
• ustawienie parametrów NATa dla nowego łącza
• ustawienia parametrów HTB czyli dynamicznego podziału ruchu na tym drugim łączu WAN
• wreszcie i nareszcie metody sterowania przepływem pakietów poprzez multi-wan.

Załóżmy bez większego zastanowienia, że drugie łącze ma następującą adresację IP:

ADRES IPv4: 89.10.11.12
MASKA PODSIECI: 255.255.255.240 (/28)
ADRES IP SIECI: 89.10.11.0/28
ADRES BRAMY DOMYŚLNEJ: 89.10.11.1
ADRES BROADCAST (ROZGŁOSZENIOWY): 89.10.11.15

Załóżmy też, że podłączyłeś kabel sieciowy do eth2 No to jedziemy z tym.

1. Przypisanie adresacji IP do nowego łącza WAN

W pliku /etc/modules zamieniamy wpis "imq numdevs=3" na

imq numdevs=4

W pliku /etc/rc.local dopisujemy pod "/usr/sbin/ip link set eth1" up następujące dwie linijki:

/usr/sbin/ip a a 89.10.11.12/28 brd 89.10.11.15 dev eth2
/usr/sbin/ip link set eth2 up

2. Utworzenie tablicy routingu dla nowego łącza

W pliku /etc/iproute2/rt_tables na końcu dopisujemy numer oraz nazwę nowej tabeli routingu:

200 wan2

Następnie znów w pliku /etc/rc.local po wpisie z pkt. 1 dopisujemy trasy dla tej tabeli oraz reguły dla niej. Musimy wbić do głowy linuksowi, że jeśli będzie korzystał z nowej tabeli routingu wan2 to musi wiedzieć, w jaki sposób obsłużyć ruch do każdej podsieci LAN z dostępem do Internetu, skonfigurowanej na routerze. Domyślnie na routerze skonfigurowana jest podsieć 192.168.100.0/24 z bramą 192.168.100.254 na interfejsie eth1. Jeśli dodałeś/łaś więcej podsieci LAN - musisz je tutaj również dopisać. Dodatkowo występuję znacznik pakietu 0x1, który będzie dalej wykorzystywany w firewallu do oznaczania ruchu.

# trasy dla tabeli wan2
/usr/sbin/ip ro a table wan2 89.10.11.0/28 dev eth2 src 89.10.11.12
/usr/sbin/ip ro a table wan2 192.168.100.0/24 dev eth1 src 192.168.100.254
# trasa domyslna dla tabeli wan2
/usr/sbin/ip ro a table wan2 default via 89.10.11.1
# regula zwrotna dla podsieci na wan2
/usr/sbin/ip ru a from 89.10.11.0/28 table wan2
# przypisanie znacznika (marka) pakietow dla tej tabeli
/usr/sbin/ip ru a fwmark 0x1 table wan2

Ponieważ każde połączenie PPP (zarówno PPPoE jaki i PPtP) dodaje swoja własną trasę do domyślnej tablicy routingu, musimy je zmusić do dodania jej także do tablicy dla drugiego łącza. W tym celu do pliku /etc/ppp/ip-up dopisujemy następująca linijkę:

/usr/sbin/ip r a table wan2 ${5} dev ${1}

oraz do pliku /etc/ppp/ip-down podobną (ale nie taką samą!):

/usr/sbin/ip r d table wan2 ${5} dev ${1}

3. Ustawienie parametrów NATa dla nowego łącza

Najpierw dla porządku dodajmy co nieco do pliku /serwer/serwer.conf w miejscu według uznania:

EXTDEV2=eth2
DOWNLOAD2=2000
UPLOAD2=500

Następnie do pliku /serwer/skrypty/nat.sh w sekcji "# MASKARADA dla wszystkiego" dopisujemy:

$IPTABLES -t nat -A POSTROUTING -s $INTNET1 -o $EXTDEV2 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -s $NOWI -o $EXTDEV2 -j MASQUERADE

4. Ustawienia parametrów HTB dla drugiego łącza WAN

W pliku /serwer/skrypty/mangle.sh dopisujemy w sekcji "# podniesienie IMQ" następującą linijkę:

$IP link set imq3 up

oraz w sekcji "# ruch przez IMQ" linijkę:

$IPTABLES -t mangle -A PREROUTING -i $EXTDEV2 -j IMQ --todev 3

Następnie w pliku /serwer/skrypty/htbwan.sh w sekcji "# czyszczenie kolejek" dodajemy:

$TC qdisc del root dev imq3 2> /dev/null > /dev/null
$TC qdisc del root dev $EXTDEV2 2> /dev/null > /dev/null

oraz poniżej w sekcji "# ograniczenia WAN" doklejamy:

htbwan imq3 sport ctnatchg $DOWNLOAD2
htbwan $EXTDEV2 dport ctnatchg $UPLOAD2

Teraz czas na reboot. Po ponownym odpaleniu zabawki powinniśmy mieć już przygotowaną obsługę dwóch łączy WAN. No i teraz zaczynamy ciekawe sprawy

5. Load balancing pomiędzy dwa łącza

Load balancing na poziomie routingu polega na keszowaniu tras. Więc jeśli po restarcie routera jakaś trasa (np do strony v-smart.pl) zostanie raz skeszowania to będzie istnieć do upływu pewnego czasu (nie wiem ile to) lub do restartu maszyny. Otwórz plik:

/etc/network/interfaces

Znajdź tam wpis dotyczący "gateway adres_twojej_bramy". Zakomentuj go znakiem #. Przy okazji jak już tu jesteś to zwróć uwagę co jest napisane w "dns-nameservers". Powinien tu być adres serwera DNS który będzie ogólnodostępny i nie blokowany przez operatorów. W szczególności przez operatorów, od których masz 2 wany Polecam googlowy 8.8.8.8 tutaj wpisać. W przeciwnym wypadku może wystąpić problem z rozwiązywaniem nazw domenowych podczas sterowania ruchem.

Następnie do /etc/rc.local wrzuć gdzieś na samym dole (po podniesieniu interfejsów eth1 i eth2):

/usr/sbin/ip r a default scope global nexthop via adres_twojej_bramy dev eth0 weight 1 nexthop via 89.10.11.1 dev eth2 weight 1

Reebot i gotowe Masz super load-balancing. Parametr weight możesz dostosować do stopnia rozłożenia ruchu np 1:2.

6. Sterowanie usługami oraz ruchem z IP lanowego

Polega na wyrzuceniu ruchu do jakiegoś adresu IP, ruchu od jakiegoś adresu z LAN lub ruchu do jakiegoś portu docelowego (np 80 - www) na drugie łącze. W tym celu do /serwer/skrypty/mangle.sh dopisujemy:

# ruch z wybranego IP lanowego po drugim laczu
#$IPTABLES -A PREROUTING -t mangle -s 192.168.100.1 -j MARK --set-mark 0x1

# ruch do wybranego adresu docelowego po drugim laczu
#$IPTABLES -A PREROUTING -t mangle -d 195.205.4.134 -j MARK --set-mark 0x1

# ruch po wybranym porcie (80) docelowym po drugim laczu
#$IPTABLES -A PREROUTING -t mangle -p tcp --dport 80 -j MARK --set-mark 0x1

Nastepnie odpalamy skrypcik: /serwer/start_all i powinno działać

Q: Dlaczego klient zawsze ma 512/128 prędkość? Przecież przypisuje mu prawidłowe zobowiązanie!

A: Jednak niekoniecznie. Zobacz jak to powinno wyglądać klikając tutaj. Musisz wybrać taryfę z prędkością i zaznaczyć komputer klienta oraz fakturę przy zobowiązaniu.

Q: A co z trybem Access Point Client? Jak podłączyć trzech klientów pod jednym adresem MAC?

A: Trochę teorii najpierw. Tryb APC (Intfrastructure Client, Client itd...) polega na tym, że w warstwie trzeciej na poziomie adresów IP apek maskuje rzeczywisty adres MAC klienta, który znajduje się za apekiem. W efekcie do autoryzacji MAC + IP, z jakiej korzysta mój LMS potrzeba MAC apeka a nie klienta. Żeby było trudniej to w warstwie drugiej na poziomie ramek apek nic nie maskuje zatem DHCP zobaczy rzeczywisty MAC komputera klienta (niezamaskowany) znajdującego się za APC. Teraz jak to zrobić w moim LMSie, żeby zadziałało:

• Osprzęt sieciowy -> Nowe urządzanie: wybierz mu TYP: APC oraz dodaj jakas nazwę, następnie dodaj mu IP oraz jego MAC
• Dodaj komputer klienta z jego rzeczywistym adresem MAC oraz wybierz mu punkt podłączenia z listy rozwijanej jako powyżej dodane urzadzenie
• I tak możesz dowolną ilość komputerów podłączać do tego samego AP w trybie Client
• Wyglądać to ma tak (kliknij).

Z trybem APC wiąże się swoista dziura w zabezpieczeniach sieci. Otóż jeśli w LMSie mamy autoryzację na jakiś komputer klienta, który podłączony jest do APc to niezależnie od adresu MAC komputera klienta będzie działać mu net jeśli tylko wpisze poprawny IP ręcznie. Dlatego dla grup klientów stosuje się tryb WDS, który MACów nie maskuje!

Q: Nie działa mi sprawdzanie czy komputer klienta jest włączony.

A: Wykonaj:

apt-get install fping

i zacznie. Chyba, że klient ma firewalla,  który blokuje pingi to nie zacznie.

Q: Dlaczego nie działa mi Webmin po instalacji tego twojego systemu?

A: Wieśmin nie działa ponieważ używa portu 10000 tcp, który jest domyślnie zamknięty przez firewall. Do pliku /serwer/skrypty/firewall.sh należy po sekcji:

# autoryzowany dostep tylko z pliku dostep.conf
grep "^[^#]" ${DOSTEP} | while read IP OPIS; do

dopisać następująca linijkę:

$IPTABLES -A INPUT -s $IP -m state --state NEW -p tcp --dport 10000 -j ACCEPT

i odpalić ten skrypt. UWAGA! Nie używajcie firewalla z Wieśmina, ponieważ pogryzie się na 100% z moim. Nie zmieniajcie również adresów IP na interfejsach poprzez niego. Korzystajcie z moich opisów do tego.

Q: Jak wyłączyć ograniczenia prędkości w LANie?

A: Rozjaśnijmy trochę sytuację. Cięcie prędkości w LAN występuje jeśli ruch przechodzi przez router. Co za tym idzie, jeśli nie używamy PPPoE to komputery w jednej podsieci w LAN mogą bez ograniczeń prędkości przesyłać dane między sobą. Wynika to z samej zasady działania protokołu IP, który nie potrzebuje bramy domyślnej do komunikacji z hostami w tej samej podsieci. Inaczej wygląda sytuacja, kiedy korzystamy z PPPoE (ruch zawsze idzie przez koncentrator) oraz próbujemy ściągnąć coś lokalnie z routera. W przypadku mojego systemu domyślnie zadziałają tu ograniczenia prędkości z taryf dla klientów. Zanim zaczniemy je wyłączać, sprawdźmy czy faktycznie tak jest. Ściągnijmy i zamontujmy darmowy tester:

wget http://www.speedtest.pl/app/speedmini.zip
unzip speedmini.zip -d /var/www/

Możemy go otworzyć przez przeglądarkę spod adresu:

http://adres_ip_routera/speedmini

i sprawdzić aktualną prędkość. Powinno być jak pisałem wyżej Następnie weźmy sobie na tapetę plik /serwer/skrypty/firewall.sh i znajdźmy w nim linijki:

$IPTABLES -t mangle -A PREROUTING -i $INTDEV1 -j IMQ --todev 1
$IPTABLES -t mangle -A POSTROUTING -o $INTDEV1 -j IMQ --todev 2
$IPTABLES -t mangle -A PREROUTING -i ppp+ -j IMQ --todev 1
$IPTABLES -t mangle -A POSTROUTING -o ppp+ -j IMQ --todev 2

które odpowiadają za kierowanie ruchu z/do interfejsów LAN i ppp do interfejsów IMQ, na których odbywa się LANowy podział pasma. Zmieńmy PREROUTING i POSTROUTING na FORWARD:

$IPTABLES -t mangle -A FORWARD -i $INTDEV1 -j IMQ --todev 1
$IPTABLES -t mangle -A FORWARD -o $INTDEV1 -j IMQ --todev 2
$IPTABLES -t mangle -A FORWARD -i ppp+ -j IMQ --todev 1
$IPTABLES -t mangle -A FORWARD -o ppp+ -j IMQ --todev 2

a następnie odpalmy /serwer/start_all i ograniczenia dla LAN powinny zniknąć.

Q: A co jak mam dwa lub więcej łączy WAN?

A: Dużo roboty. Za dużo żeby opisać w FAQ. Powstał na ten temat nowy artykuł (kliknij).

Q: A jak wygląda sprawa z przekierowaniami portów?

A: Panel LMS nie przewiduje tego w swoim interfejsie a na razie skończył mi się czas na przeróbki. W najnowszej wersji macie pliczek:

/serwer/forward.conf

gdzie wpisujecie 3 parametry:

• port od strony WAN
• adres IP w LAN
• port od strony LAN

Przekierowanie zadziała dla protokołu TCP i UDP.

Q: Jak włączyć logowanie połączeń do sysloga?

A: Należy do pliku:

/serwer/skrypty/firewall.sh

dopisać po limitach połączeń następującą linijkę:

$IPTABLES -A FORWARD -o $EXTDEV -s $INTNET1 -p tcp -m state --state NEW -j LOG --log-level info --log-prefix "SYN-INTNET1 "

Domyślnie logowanie jest wyłączone bo tak

Q: Jak ustawić kiedy włącza się taryfa nocna a kiedy dzienna?

A: W pliku /etc/cron.d/vsmart masz wszystko opisane. Wartości prędkości dla lanowych taryf nocnych definiujemy z poziomu panelu LMS. Dla wanowych znajdują się w pliku /serwer/serwer.conf

Q: A jak poradzić sobie w wypadku gdy mamy 3 karty ethernetowe 1WAN +2LAN?

A: Trochę zabawy będzie. Załóżmy, że chcemy na drugim interfejsie o nazwie eth2 dodać podsieć 192.168.102.0/24 z bramą 192.168.102.254:

• w panelu LMS: Sieci IP -> Nowa podsieć -> Dodajemy:
  • Nazwa Sieci: LAN2
  • Adres sieci: 192.168.102.0 / 24 (256-adresów)
  • Interfejs: eth2
  • Gateway: 192.168.102.254
  • Serwery DNS: 192.168.102.254, 8.8.8.8
• w panelu LMS: Sieci IP -> Nowa podsieć -> Dodajemy (jeszcze raz):
  • Nazwa Sieci: LAN2-NOWI
  • Adres sieci: 10.10.11.0 / 24 (256-adresów)
  • Interfejs: eth2
  • Gateway: 10.10.11.254
  • Serwery DNS: 10.10.11.254 , 8.8.8.8
  • Zakres DHCP: 10.10.11.1 do 10.10.11.253
• w pliku /etc/rc.local dopisujemy pod wpisem /usr/sbin/ip link set eth1 up
  

  /usr/sbin/ip a a 192.168.102.254/24 brd 192.168.102.255 dev eth2
  /usr/sbin/ip a a 10.10.11.254/24 brd 10.10.11.255 dev eth2
  /usr/sbin/ip link set eth2

• w pliku /etc/rc.local dopisujemy na samym dole:
  

  /usr/sbin/pppoe-server -I eth2 -L 192.168.102.254 -N 1000 -k

• w pliku /serwer/serwer.conf dopisujemy w sekcji # interfejs(y) LAN:
  

  INTDEV2=eth2
  INTNET2=192.168.102.0/24

• w pliku /serwer/serwer.conf dopisujemy w sekcji #nieautoryzowani klienci:
  

  NOWI2=10.10.11.0/24

• w pliku /serwer/skrypty/firewall.sh oraz /serwer/skrypty/nat.sh znajdujemy wszystkie wpisy zawierające zmienne $INTDEV1, $INTNET1 oraz $NOWI a następnie kopiujemy je poniżej miejsca, gdzie występują i zmieniamy odpowiednio na $INTDEV2, $INTNET2 oraz $NOWI2 np:
  

  $IPTABLES -t mangle -A PREROUTING -i $INTDEV1 -j IMQ --todev 1
  $IPTABLES -t mangle -A POSTROUTING -o $INTDEV1 -j IMQ --todev 2
  $IPTABLES -t mangle -A PREROUTING -i $INTDEV2 -j IMQ --todev 1
  $IPTABLES -t mangle -A POSTROUTING -o $INTDEV2 -j IMQ --todev 2

  $IPTABLES -A INPUT -s $INTNET1 -m state --state NEW -p tcp --sport 1024: --dport 53 -j ACCEPT
  $IPTABLES -A INPUT -s $INTNET2 -m state --state NEW -p udp --sport 1024: --dport 53 -j ACCEPT

  $IPTABLES -t nat -A POSTROUTING -s $NOWI -o $EXTDEV -j MASQUERADE
  $IPTABLES -t nat -A POSTROUTING -s $NOWI2 -o $EXTDEV -j MASQUERADE

  itd...

• do /serwer/skrypty/firewall.sh pod linią $IPTABLES -A FORWARD -m state --state invalid -j DROP dopisujemy
  

  $IPTABLES -A FORWARD ! -o ${EXTDEV} -j ACCEPT

• następnie reboot i powinno działać

Q: Ile waży router po pełnej instalacji?

A: Zależy od wagi zastosowanego komputera. Myślę, ze od 1 kg do 100 kg. Natomiast dane na dysku zajmują 1.3 GB hehe.

Q: A co z limitami ilości połączeń TCP dla userów? Jest coś takiego?

A: Jest. W /serwer/serwer.conf zmienna CONNLIMIT odpowiada za to. Domyślnie to 100 na głowę.

Q: Jak zmienić dane sprzedawcy na fakturze?

A: Ostatni raz na takie pytania odpowiadam. Od tego macie manual LMSa. A więc: Konfiguracja -> Firmy i odpowiednia edycja danych.

Q: Jak zrobić aby user po podłączeniu do sieci dostał komunikat o braku autoryzacji a następnie po połączeniu PPPoE otrzymał dostęp do Internetu?

A: Należy komputerowi klienta wpisać następujący adres MAC: 00:00:00:00:00:00 (trudny nie? :P). Klient wtedy otrzyma autoryzację tylko dla PPPoE natomiast TCP/IP będzie niedostępne dla jego adresu IP oraz wykluczone z DHCP.

Q: W jaki sposób mogę zmienić tę beznadziejną adresację 192.168.100.x i 192.168.101.x dla LAN?

A: Trzeba wykonać kilka kroków aby zmienić te adresacje:

1. /etc/rc.local - modyfikujemy wpisy odnośnie dodawania adresów IP na interfejs eth1
2. /serwer/serwer.conf - to samo co wyżej
3. /serwer/skrypty/nat.sh - zmieniamy 192.168.100.254 na nowy adres bramy dla klientów
4. /etc/pptpd.conf - tak jak wyżej
5. w panelu LMS: Sieci IP -> lista a następnie wykonujemy modyfikacje podsieci
6. reboot i powinno działać

W przyszłości dorobię automatyczną synchronizację adresacji z LMSem

Q: Może coś więcej na temat komunikatów dla klientów?

A: Mamy ich 3 rodzaje:

• Komunikat dla nowych klientów - pojawia się tylko w przypadku korzystania z protokołu TCP/IP (nie PPPoE, nie PPtP). Jest uruchomiony poprzez Apache na porcie nr 202. Polega na wykonaniu nata docelowego (DNAT) dla portu nr 80 oraz sieci źródłowej 10.10.10.0/24 na socket 192.168.100.254:202. W efekcie nowy klient widzi w przeglądarce powitanko.
• Przypomnienie o płatnościach - pojawia się w przypadku załączenia żółtego trójkąta przy komputerze klienta w LMS. Chodzi na porcie nr 200. W momencie włączenia przez klienta przeglądarki, widzi on przypomnienie, które w tle ściąga mu blokadę. Komunikat wyświetla się raz na określony czas, który można zmienić w pliku: /etc/cron.d/vsmart. Domyślnie jest 1 */3 * * * co oznacza "załączaj co 3 godziny w pierwszej minucie tej godziny". Polega na wykonaniu nata docelowego (DNAT) dla portu nr 80 oraz adresu IP klienta na socket 192.168.100.254:200.
• Całkowita blokada klienta - pojawia się, kiedy klient ma wyłączoną żarówkę przy komputerze w LMS (tzw. komputer odłączony). Port 201. Klient ma zablokowane wszystkie usługi - widzi tylko komunikat i nie ma możliwości samodzielnego odblokowania. Polega na wykonaniu nata docelowego (DNAT) dla portu nr 80 oraz adresu IP klienta na socket 192.168.100.254:201.

Q: Jak modyfikować treść komunikatów dla klientów?

A: Musisz wiedzieć cokolwiek o HTML. Komunikaty znajdują się w następujących miejscach:

• Komunikat dla nowych klientów: /var/www/info/202/index.php
• Przypomnienie o płatnościach: /var/www/info/200/index.php (nie wywalać iframe bo przestanie działać odblokowywanie!)
• Całkowita blokada klienta: /var/www/info/201/index.php

Pamiętaj! Przed modyfikacjami zrób backup modyfikowanych skryptów!

Q: Jak działa dynamiczny podział pasma od strony WAN?

A: Normalnie W skrypcie /serwer/skrypty/htbwan.sh mamy 7 kolejek (podano od najwyższego priorytetu):

• classid 1:2 - waga 15% - ack, icmp, sip-sygnalizacja
  
• classid 1:3 - waga 30% - ssh, gg, vnc, vpn, https
• classid 1:4 - waga 30% - smtp, smtps, http, pop3, pop3s, imap, shoutcast
• classid 1:5 - waga 10% - http-video, ftp
• classid 1:6 - waga 10% - klasa domyślna - wszystko co, nie sklasyfikowane
• classid 1:7 - waga 5% - p2p złapane za pomocą layer-7

Wagi są ważne, gdy prędkość na interfejsie WAN osiąga to, co mamy wpisane w /serwer/serwer.conf. Wtedy dopiero tak na prawdę zaczyna działać kolejkowanie. Do kolejkowania zastosowałem mechanizm HTB oraz ESFQ, który korzysta z conntracka. Efekt jest taki, że mechanizm potrafi rozłożyć równo ruch pomiędzy adresami IP w LAN. Nie ważna jest ilość połączeń od/do danego adres IP w LAN tak jak to było w standardowych SFQ. Działanie mechanizmu można podejrzeć uruchamiając skrypty:

/serwer/diagnostyka/wan-down

/serwer/diagnostyka/wan-up

Q: Jak działa podział pasma per klient od strony LAN?

A: Również normalnie W skrypcie /serwer/skrypty/htblan.sh tworzone są statyczne kolejki z prędkościami dla IP klientów. Działanie mechanizmu można podejrzeć uruchamiając skrypty:

/serwer/diagnostyka/lan-down

/serwer/diagnostyka/lan-up

Q: Jak zrobić automatyczne załączanie blokad?

A: Jest zrobione, wystarczy dostosować toto do swoich potrzeb.

Na tapetę weźmy znów harmonogram zadań (cron) dla projektu czyli plik: /etc/cron.d/vsmart

Przypomnienie o płatnościach.

1 8 20 * *      root    /var/www/bin/lms-blok-light -q

oznacza, ze przypomnienie zostanie załączone o godzinie 8:01 20-go dnia miesiąca. Zaglądając do powyższego skryptu znajdźmy wpis:

HAVING balance < 0 AND balance > -100

który mówi nam, że blokadzie podlegają klienci o saldzie ujemnym do -100 PLN.

Blokada całkowita.

2 8 27 * *      root    /var/www/bin/lms-blok-hard -q

oznacza, ze przypomnienie zostanie załączone o godzinie 8:02 27-go dnia miesiąca. Zaglądając do powyższego skryptu znajdźmy wpis:

HAVING balance <= -100

który mówi nam, że blokadzie podlegają klienci o saldzie ujemnym niższym niż -100 PLN.

Q: Jakie sa parametry połączenia PPPoE oraz PPtP?

A: Następujące są:

• PPPoE - uwierzytelnianie: chap, mschap lub mschap-v2, kompresja: brak, szyfrowanie: brak
• PPtP - uwierzytelnianie: mschap-v2, kompresja: brak, szyfrowanie: mppe-128

Q: Jak przydzielić komputerowi prędkość testową, niezależną od zobowiązania?

A: Nie było takiej funkcji w LMS więc zrobiłem to trochę na około. Należy dodać grupę komputera, w opisie której wpisujemy coś w formacie:

download/upload

w jednostkach kbps np. 1024/1024. W szczególności możemy wpisać 0/0 co oznaczać będzie brak limitów prędkości LAN czyli użytkownik będzie korzystał z dynamicznego podziału pasma na WAN. Następnie komputer klienta należy przypisać do takiej grupy. Grupy maja pierwszeństwo nad zobowiązaniami.

A jak poradzić sobie w wypadku gdy mamy 3 karty ethernetowy 1WAN +2LANA jak poradzić sobie w wypadku gdy mamy 3 karty ethernetowy 1WAN +2LAN

Sprawa pierwsza - PPPoE

Jeśli jesteś "admin" i masz swoją super-sieć to powinieneś już wiedzieć, że czysty protokół IPv4 oraz związane z nim nierozłącznie adresy IP oraz MAC mają dość poważne wady co do utrzymania bezpieczeństwa sieciowego. Mam na myśli różnego rodzaju podkradanie i podsłuchiwanie transmisji. Mamy do wyboru w zasadzie dwie opcje autoryzacji Twoich użytkowników - albo statycznie wpiszesz im konfigurację w ustawieniach TCP/IP albo podasz im poprzez protokół DHCP (znów patrz Wiki jak  nie wiesz o co kaman). W obu przypadkach aby zapewnić minimalny poziom autoryzacji musisz wklepać na swoim super-firewallu każdą parę IP-MAC. Jest to rozwiązanie dość szybkie i wygodne w realizacji i wdrożeniu. Problem pojawia się, gdy liczba użytkowników Twojej sieci rośnie i pojawia się dość dużo ruchu nadmiarowego wynikającego z natury protokołu IP. Nie wspomnę już o sytuacji, kiedy tzw. "intruz-morderca" będzie chciał skorzystać sobie za darmo z Twojej sieci.

Podkreślmy dobitnie, że nie będę rozklejał się tu nad możliwymi zabezpieczeniami dostępu do sieci (pancerny pancerz na kabel, WEP, WPA, WPA2 itd) ponieważ to działa w troszkę wyższej "warstwie". Tutaj zajmiemy się protokołami transmisyjnymi 2/3 warstwy z modelu OSI (Wiki? :P).

Mamy więc intruza. Intruz podłączył się do sieci firmowej opartej na przełącznikach ponieważ admin zapomniał zamknąć szafki w kiblu, gdzie akurat znajdował się jeden wolny port w switchu. Dość absurdalna sytuacja ale znam głupsze. Intruz nasłuchuje broadcasty latające po sieci (zwłaszcza pakiety ARP) i zapisuje sobie wszystko skrupulatnie. Następnie wykonuje atak "man-in-the-middle" na bramę domyślną w sieci i zbiera dane dostępowe do Naszej-Klaty, skrzynek pocztowych i inne rzeczy, które nie są szyfrowane. Później zmienia swój adres MAC na któryś z podsłuchanych oraz wpisuje odpowiedni IP i co ma po chwili? Dostęp do naszego super-zabezpieczonego Internetu

Dobrym lekarstwem na taką sytuację jest zmiana protokołu IP na PPPoE. Zasada działania jest prosta. U nas mamy koncentrator PPPoE natomiast klient aby uzyskać połączenie z siecią musi wpisać login i hasło, który otrzyma od nas. Po autoryzacji klienta zostaje otwarte połączenie punk-punkt między jego komputerem a koncentratorem i generalnie rzecz biorąc - nic innym użytkownikom do tego Nie ma broadcastów - nie ma możliwości ataków takich jak w IPv4. Pamiętajmy, że klient tak czy inaczej paradoksalnie otrzyma adres IP na swojej końcówce tego połączenia jednak tylko i wyłącznie do celów logicznych.

Można by powiedzieć, że każdorazowe odpalanie połączenia PPPoE po starcie systemu przypomina trochę czasy modemów i sławnych juz 56kbps. Prawda. Ale zawsze można zamontować sobie router, który nawiąże to połączenie u klienta za nas i załatwi tym samym problem klikania w ikonkę połączenia. Swoją drogą za te minimum 100zł, które trzeba by wydać na router wolałbym sobie raz więcej kliknąć

Połączenie PPPoE ma też swoje wady. Nie lubi gubienia się ramek a co za tym idzie link do klienta, czy to kablem czy radiem, musi być stabilny. Inaczej zobaczymy sporadyczne DC. Poza tym zalecam stosowanie szyfrowanka MPPE oraz autoryzancji ms-chap-v2 z uwagi na wysoki poziom trudności w połamaniu tego co oczywiście nie znaczy, że nie da się.

UWAGA. Połączenie PPPoE działa tylko w ramach jednego segmentu sieci (bridża) czyli w warstwie drugiej OSI. Każdy router po drodze uniemożliwi nam podłączenie się do koncentratora ponieważ ma on za zadanie właśnie rozdzielić segmenty sieci.

Protokół PPtP

Jest to protokół tunelowy PPP. W tym akurat wypadku oznacza to, że jest zapakowany w protokół warstwy wyższej czyli IPv4. Po co? Wyobraźmy sobie, że mamy super-tajną firmę, w której działa sieć lokalna a dostęp do zasobów serwerów (otoczenie sieciowe, bazy danych itd) ograniczony jest tylko do tej sieci ze względów bezpieczeństwa. Głupotą byłoby narażać nasze bazy danych osobowych na samą możliwość kontaktu ze światem Internetu zewnętrznego prawda? Okej - mamy też pracowników, który dużo podróżują i potrzebują szybki dostęp do baz danych firmy. Nie rozwiążemy tego problemu dopóki, nie wdrożymy dowolnego rozwiązania spod hasła VPN. PPPtP jest jednym z wyjść i jednym z najlepszych i najprostszych jeśli ludzie w naszej firmie korzystają z Windows. Umożliwia użytkownikowi po podaniu loginu, hasła oraz zdalnego serwera (np. bramy w naszej firmie, serwera VPN) wykonanie tunelu do lokalnej sieci poprzez np Internet. Logicznie wyglądałoby to tak, jakby użytkownik znajdował się w sieci lokalnej a fizycznie może być nawet na księżycu (polecam bajkę "Jak ukraść księżyc").

Instalacja pod Debianem

Oprócz paczek z oprogramowaniem dla routera należy doinstalować w systemie (dpkg -i plik.deb) następujące 3 paczki deb, które póki co przekompilowałem na architekturze i386:

• pppd 2.4.3-1 [i386] [amd64]
• pppoe 3.10 [i386] [amd64]
• pptpd 1.3.4 [i386] [amd64]

Należy zwrócić uwagę na plik z paczki:

/etc/ppp/chap-secrets

w którym znajdują się hasła użytkowników. PPPoE serwer uruchamiamy np. następującym poleceniem:

/usr/sbin/pppoe-server -I eth1 -L 192.168.1.1 -N 1000 -k

gdzie -I to intefejs, -N maksymalna ilość połączeń, -k parametr oznaczający wsparcie jądra dla PPPoE. Serwer PPtP uruchamiamy wklepując:

/usr/local/sbin/pptpd

bez żadnych parametrów. Pamiętajmy aby otworzyć port 1723 ponieważ na nim właśnie słucha PPtP.

• jajko 2.6.24.5 (domyslne smp ze Slacka 12.1) działało mi od dwóch lat na kilkunastu routerach bez kernel panic
• było ono zmontowane z domyślnego konfiga ze Slacka oraz połatane imq, esfq i layer7
• działało również pod Debianem bez żadnego "ale" (co w sumie oczywistym jest)

Na warsztat poszedł domyślny konfig jajeczka 2.6.34. Zaciągnięte zostały też vaniliowe źródła z kernel.org oraz patche Dj Gregora z linuxbox.pl. Swoją drogą z tego co zauważyłem Dj jest fanem Slackware (podobnie jak ja kiedyś) więc dziwne by było gdyby nie popełnił patchów dla domyślnego jądra tego systemu. Szacun. Kolejność ataku była następująca:

• patchowanie
• make menuconfig
• zapis konfigu i wyjście
• make menuconfig
• zaznaczenie odpowiednich modułów (IMQ Target, esfq, layer7)
• włączenie do jajka modułu Virtio Block Device, Virtio PCI i Virtio Baloon
• zapis konfiga
• make bzImage modules modules_install
• procedura tworzenia paczki (długa historia) z jądrem
• kompilacja i paczkowanie iptables, iproute, l7-protocols

Efekty - paczki do pobrania: [i386] [amd64]

Co będzie potrzebne:

• Dowolna dystrybucja systemu GNU Linux.
• Zalecane jądro z serii 2.6.x. Jądro musi mieć wkompilowane następujące opcje w sekcji NETWORKING: IP: Advanced Router, IP: Policy Routing. W sekcji NETFILTER: Connmark. Domyślnie w nowszych dystrybucjach opcje te są już wkompilowane. Jednak w przypadku problemów jest to pierwszy aspekt, który należy sprawdzić.
• Zbiór aplikacji iproute2, odpowiedni dla danej wersji jądra.
• Filtr pakietów iptables.

Słowem - wszystko prócz dystrybucji znajdziecie w projekcie v-smart dla [i386] lub [amd64]

Konfiguracja routingu.

Konfiguracja routingu w przypadku podziału ruchu na dwa lub więcej łączy składa się z kilku części. W pierwszej kolejności należy dodać odpowiednie tablice routingu do pliku:

/etc/iproute2/rt_tables

Zasada jest taka, że domyślny routing zapisany jest w tablicy o nazwie main z numerem 254. Kolejne wpisy należy dodawać z numerami niżymi np. 200, 201, 202 itd. Przykładowy wpis w powyższym pliku ma format:

nr_tablicy nazwa_tablicy

Następnie w każdej nowo dodanej tablicy routingu należy umieścić identyczne wpisy dotyczące podsieci lokalnych jak w tablicy main, której zawartość odczytać można za pomocą polecenia:

ip route list

Dodawanie wpisów do tabeli wykonać można za pomocą polecenia:

ip route add table [tablica] [podsiec] dev [interfejs]

Trasa domyślna (ang. default) dla każdej nowo dodanej tabeli przebiega przez inne łącze zatem do każdej należy dodać bramę domyślną następującym poleceniem:

ip route add table [tablica] default via [adres_bramy]

Zgodnie z zasadami, które rządzą protokołem TCP/IP, na każdy odebrany przez router pakiet musi zostać wygenerowana odpowiedź. Odpowiedź ta musi wrócić do nadawcy tą samą trasą którą nadeszła. Na obecnym etapie konfiguracji routingu – odpowiedź ta zostanie wysłana poprzez bramę domyślną dla systemu umieszczoną w tablicy main. W konsekwencji – jeśli dowolny pakiet nadejdzie z łącza, dla którego routing określają dodatkowe tablice różne od main – nie zostanie wygenerowana na niego odpowiedź co uniemożliwi dalszą transmisję. Rozwiązaniem tego problemu jest „podpowiedź” dla routera, którędy powinien wysyłać pakiety otrzymane trasą różną od main:

ip rule add from [podsiec_bramy] table [tablica]

Ostatnim krokiem w konfiguracji omawianego routingu jest stworzenie zasad, które pokierują pakiety (połączenia) o określonych właściwościach daną trasą (przez dane łącze). Najprostszym rozwiązaniem jest tzw. „markowanie” pakietów lub połączeń odpowiednimi znacznikami (ang. mark). Znaczniki te są liczbami całkowitymi dodatnimi, różnymi od zera. Dla każdego nowego łącza (nowej tabeli) należy utworzyć osobny, unikatowy znacznik, który zostanie wykorzystany w momencie sterowania ruchem (punkt następny). Do tego celu można wykorzystać polecenie:

ip rule add fwmark [znacznik] table [tablica]

Sterowanie ruchem.

Sterowanie ruchem pakietów (połączeń) między kilkoma łączami rozwiązuje się za pomocą filtru iptables. Filtr ten dostarcza między innymi opcje znakowania (markowania) pojedynczych pakietów lub całych połączeń określonymi znacznikami. Składnia polecenia dla pojedynczych pakietów jest następująca:

iptables –t mangle –A PREROUTING [kryteria] –j MARK –-set-mark [znacznik]

natomiast dla połączeń:

iptables –t mangle –A PREROUTING [kryteria] –j CONNMARK –-set-mark [znacznik]

iptables –t mangle –A PREROUTING –m connmark –-mark [znacznik] –j CONNMARK –-restore-mark

Znakowanie całego połączenia polega na oznaczeniu pakietu, od którego rozpoczyna się połączenie a następnie automatycznym oznaczeniu każdych następnych pakietów należących do danego połączenia logicznego. Znakowanie połączeń przydatne jest w momencie, gdy pakiet rozpoczynający transmisję ma inny charakter niż pozostałe uczestniczące w dalszej części połączenia. Sytuacja taka ma miejsce w przypadku połączeń p2p, VoIP, FTP i innych.

Parametr [kryteria] określa właściwości pakietów, które zostaną zamarkowane określonym znacznikiem a następnie pokierowane przez routing skonfigurowany w punkcie 3 na odpowiednie łącze (odpowiednią trasą). Poszczególne elementy składające się na ten parametr można łączyć ze sobą w ich iloczyn logiczny. Poniżej przedstawiono kilka przykładowych parametrów:

[-p tcp --dport 80] – caly ruch WWW

[-s [adres_ip]] – ruch z danego adresu IP

[-s [podsiec_lokalna]] – ruch z danej podsieci

Jeśli w sieci lokalnej nie ma możliwości dysponowania publicznymi adresami IP, należy zastosować mechanizm zwany NAT-em źródłowym w celu udostępnienia połączenia dla podsieci z puli prywatnych. Ponieważ przepływ pakietów realizowany będzie przez kilka łączy, najwygodniej wykorzystać mechanizm zwany MASKARADĄ, który automatycznie dostosuje NAT źródłowy do pakietów po routingu:

iptables –t nat –A POSTROUTING –s [podsiec_lokalna] –j MASQUERADE

Konfiguracja głównego routingu oraz udostępniania połączenia internetowego dla podsieci 192.168.1.0/24 oraz 192.168.2.0/24

ip address add 80.70.60.130/30 brd 80.70.60.131 dev eth0

ip link set eth0 up

ip address add 80.70.50.66/30 brd 80.70.50.67 dev eth1

ip link set eth1 up

ip address add 80.70.40.34/30 brd 80.70.60.35 dev eth2

ip link set eth2 up

ip address add 192.168.1.1/24 brd 192.168.1.255 dev eth3

ip address add 192.168.2.1/24 brd 192.168.1.255 dev eth3

ip link set eth3 up

ip route add default via 80.70.60.129 dev eth0

iptables –t nat –A POSTROUTING –s 192.168.1.0/24 –j MASQUERADE

iptables –t nat –A POSTROUTING –s 192.168.2.0/24 –j MASQUERADE

Tabele routingu w pliku /etc/iproute2/rt_tables

200 wan2

201 wan3

Trasy do podsieci lokalnych dla nowo dodanych tabel

ip route add table wan2 192.168.1.0/24 dev eth3

ip route add table wan2 192.168.2.0/24 dev eth3

ip route add table wan3 192.168.1.0/24 dev eth3

ip route add table wan3 192.168.2.0/24 dev eth3

Trasy domyślne dla nowych tabel

ip route add table wan2 default via 80.70.50.65

ip route add table wan3 default via 80.70.40.33

Reguły zwrotne dla nowych tabel

ip rule add from 80.70.50.64/30 table wan2

ip rule add from 80.70.40.32/30 table wan3

Reguły routingu

ip rule add fwmark 10 table wan2

ip rule add fwmark 11 table wan3

Sterowanie ruchem – przykładowe założenia

a) ruch HTTP z podsieci 192.168.1.0/24 przez łącze WAN2

b) ruch HTTP z podsieci 192.168.2.0/24 przez łącze WAN3

c) ruch HTTPS dla adresów różnych od 192.168.2.128-192 przez łącze WAN2

d) ruch POP3 (odbieranie poczty) poprzez łącze WAN3

e) ruch FTP dla stacji roboczej o adresie 192.168.2.113 poprzez łącze WAN2

Realizacja założeń sterowania ruchem zgodnie z powyższą kolejnością

a)

iptables –t mangle –A PREROUTING –p tcp --dport 80 –s 192.168.1.0/24 –j MARK --set-mark 10

b)

iptables –t mangle –A PREROUTING –p tcp --dport 80 –s 192.168.2.0/24 –j MARK --set-mark 11

c)

iptables –t mangle –A PREROUTING –p tcp --dport 443 –s ! 192.168.1.128/26 –j MARK --set-mark 10

d)

iptables –t mangle –A PREROUTING –p tcp --dport 110 –j MARK --set-mark 11

e)

iptables –t mangle –A PREROUTING –p tcp --dport 20 –s 192.168.2.113 –j CONNMARK --set-mark 10

iptables –t mangle –A PREROUTING –p tcp --dport 21 –s 192.168.2.113 –j CONNMARK --set-mark 10

iptables –t mangle –A PREROUTING –m connmark –-mark 10 –j CONNMARK –-restore-mark

Na koniec

Należy zauważyć, że cały pozostały ruch, który nie został sklasyfikowany przez reguły skierowany zostanie przez domyślny routing poprzez łącze WAN1. Dobrą taktyką jest, aby łącze dla głównego routingu było symetryczne i aby wszelkiego rodzaju ruch p2p przechodził właśnie przez nie ponieważ nie ma skutecznych w 100% metod, aby go sklasyfikować i przerzucić na inne łącze. Za to w przypadku ruchu HTTP, HTTPs, POP3, SMTP, FTP i podobnych (działających na określonych portach) sterowanie pakietami lub połączeniami jest zawsze skuteczne.

Pewnym ograniczeniem przy tego typu sterowaniu ruchem jest brak możliwości stosowania mechanizmów kontrolujących przepustowość, które korzystają z markowania pakietów od/do określonego nadawcy/odbiorcy. Są to mechanizmy dość często stosowane w sieciach lokalnych jednak ich wydajność jest niewielka a stopień skomplikowania dość duży. Dobrą alternatywą przy kontrolowaniu przepływności łączy jest stosowania wirtualnych interfejsów IMQ w połączeniu z mechanizmami sprawiedliwego podziału łącza ESFQ od strony WAN routera. Było o tym tutaj.

Co mamy dzisiaj? Bardzo niskie ceny łączy, bardzo "duże" prędkości dla klientów połączone z miłością do waszej-klaty.pl, wszelkiego rodzaju *tubów i torrentów, bez których nawet kobiety już nie mogą żyć (bo skąd tu filmy ściągać jak nie przez utorrent he he). Pojawia się dość trudne pytanie dla małych ISP pt. "Jak tu kurza twarz zarobić na biednych klientach, którzy chcą coraz więcej za coraz mniejsze pieniądze". Możliwości jest kilka:

• zamknąć sieć w sensie sprzedać się dużemu ISP i otworzyć budę z kebabami na dworcu (większy zysk)
• olać klientów i ich narzekanie, co jest dość często stosowane z powodu braku środków
• POMYŚLEĆ, POSZUKAĆ, ZNALEŹĆ rozwiązanie, które będzie pokarmem dla "głodnych" klientów-pasożytów, którzy, co byśmy nie zrobili, i tak będą narzekać oraz dla nas, biednych małych ISP, którzy mając 10/10Mbps łącze chcemy zmieścić w tym 200 klientów ze średnią prędkością dla nich w okolicach 1Mbps.

Da się. Potrzebny komputer średniej mocy obliczeniowej, w miarę świeża dystrybucja linuxa oraz dużo kawy, fajek (dla tych co palą of koz) i święty spokój. Zatem adminie - przed przystąpieniem do "ataku" odstaw żonę do koleżanek z kilkoma stówkami w kieszeni na zakupy, dzieci oddaj teściom na weekend i do roboty haha!

A teraz poważnie. Napiszmy jak to wszystko powinno działać. Załóżmy, że mamy już skrzynkę z linuxem, dla uproszczenia debian lenny z paczkami [i386] lub [amd64], oraz dwoma interfejsami sieciowymi:

• eth0 jako WAN (PUBLICZNE_IP)
• eth1 jako LAN (LOKALNE_IP, LOKALNA_PODSIEC)

Kluczem do sukcesu jest znalezienie mechanizmu, który umie rozłożyć ruch od/do klientów sprawiedliwie. Sprawiedliwie nie oznacza standardowego HTB + sfq, gdyż takie połączenie dzieli po równo trafik per połączenie. Więc jeśli mamy dwóch klientów w sieci LAN i każdy ma otwarte jedno połączenie (np do redtube) to będzie sprawiedliwie - obaj będą cieszyć się multimediami. Inaczej wygląda sprawa, jeśli jeden z nich odpali klienta sieci torrent i rozkręci się do 2k połączeń. Wtedy drugi już nie zazna przyjemności z redtube - zostanie wycięty w pień przez ilość połączeń p2p konkurenta.

Sprawiedliwie oznacza podział per IP źródłowe / docelowe (upload / download). Taką możliwość oferuje mechanizm o nazwie ESFQ, który w połączeniu z HTB potrafi dzielić również w przypadku zastosowania NATa. Dodatkowo przypomnę po raz n!^2, że linuxowe HTB potrafi "ciąć" jedynie ruch WYCHODZĄCY z interfejsu. Zatem możemy zapomnieć, że bez wykorzystania IMQ (patrz google) zrobimy cokolwiek mądrego w kwestii podziału pasma. Tomek pewnie zaraz skrytykuje, że nie używa IMQ i się da ale my swoje wiemy bo przeprowadziliśmy dużo testów. Dokumentacja kernela oraz IMQ też mówią swoje.

Kilka słów w kwestii priorytetyzacji ruchu. Przedstawię jak to wygląda u mnie - oceńcie sami czy przyda się Wam czy nie. I tutaj przytoczę sławne już zdanie: "To że działa to u mnie wcale nie oznacza, że będzie działać to u Ciebie"

PRZEPIS NA ROUTER

system: klikamy

iptables: klikamy

htb: klikamy

testowanie: klikamy

Opisy poszczególnych poleceń znajdują się w powyższych plikach. Plik htb.txt można spokojnie wkleić do skryptu shellowego i odpalić po uprzednim uzupełnieniu parametrów. Testujcie śmiało jeśli macie cierpliwość. Efektem spodziewanym jest uzyskanie priorytetu wyższego lub niższego dla usług zdefiniowanych w htb.txt oraz iptables.txt oraz sprawiedliwe rozłożenie ruchu per IP w sieci LAN.

Omówiony wyżej dynamiczny sposób podziału pasma zamierzamy zamontować do naszych routerów uruchomionych przy wykorzystaniu wirtualizacji Proxmox. Wcześniej został sprawdzony na kilkuset klientach i działa na 75% prawidłowo naszym zdaniem. BTW.. jak znajdziecie taki, który spełnia wasze oczekiwania w 99.9% to dajcie znać.

PS. Ponieważ często pytacie o pattern l7 do łapania rapidshare itp, poniżej podaje howto.

Tworzymy sobie pliczek:

/etc/l7-protocols/protocols/rapidshare.pat

i klepiemy w nim takie dwie linijki:

rapidshare

rapidshare.com

Wielkiej filozofii w tym nie ma. Po prostu łapie toto połączenia do wszystkiego (bo jest connmark w iptables), co chociaż w jednym pakiecie zawiera rapidshare.com a większość serwerów rapida siłą rzeczy ma to w swojej domenie U mnie dziala.

Należało przyjąć pewne założenia:

• Połączenia między wirtualnymi routerami realizowane są w bridżach (np. przejście z jednego do drugiego)
• Połączenia "na zewnątrz" (np. ze switchem) realizowane są za pomocą vlan-ów z powodu braku dużej ilości interfejsów fizycznych serwera
• Vlan-y są podpięte do bridżów, obsługiwanych przez Proxmoxa
• Posiadamy switcha, który umożliwia uruchomienia łącza trunkowego najlepiej po interfejsie gigabitowym

Utworzono trzy bridże (z poziomu /etc/network/interfaces) opisane poniżej:

vmbr1)

• vlan1
• funkcja WAN do ISP

vmbr2)

• vlan2
• funkcja "szkieletu serwerów"

vmbr3)

• vlan3
• funkcja LAN

Załóżmy że od ISP posiadamy PUBLIC_IP, przez który została przeroutowana PUBLIC_NET/24. Podzieliliśmy PUBLIC_NET/24 na dwie podsieci CORE_NET/25 i PUBLIC_LAN/25. Dodatkowo mamy lokalna podsieć powiedzmy LOCAL_LAN/24. Postawiono trzy wirtualne maszyny "Fully Virtualized (KVM)", których konfiguracja interfejsów wygląda następująco:

R1)

• eth0: PUBLIC_IP - interfejs WAN czyli do naszego ISP (zapięty do vmbr1)
• eth1: IP z sieci CORE_NET/25 - interfejs wewnętrznej sieci szkieletowej (zapięty do vmbr2)
• default route via eth0

R2)

• eth0: IP z sieci CORE_NET/25 - interfejs WAN routera podłączony do "szkieletu serwerów", na który będzie natowany LAN z eth1 (zapięty do vmbr2)
• eth1:  IP z sieci PUBLIC_LAN/25 oraz IP z sieci LOCAL_LAN/24 - interfejs LAN routera (zapięty do vmbr3)
• default route via eth0

S1)

• eth0: IP z sieci CORE_NET/25 - interfejs serwera hostingowego podłączony do "szkieletu serwerów" (zapięty do vmbr2)
• default route via eth0

Odpalono to wszystko. Działa w sensie sieć funkcjonuje prawidłowo (pingi, trace i takie tam). Kolejny etap polegać będzie na testach tego w rzeczywistej sieci. Dodatkowo na R2 zamontowano paczki z projektu rabbit (iptables + iproute + jajo). Pierwsze wrażenia opisane poniżej:

• iptables sypie ostrzeżeniami przy negacji reguł (czyli przy używaniu "!")
• zauważyliśmy, że wirtualne maszyny lubią czasem przestać odpowiadać - jakby bridże się sypały, pomaga oczywiście nieśmiertelny reboot wirtualek

ToDo:

• sprawdzić wtf z iptables, ewentualnie cofnąć projekt rabbit do wcześniejszej wersji
• rozwiązać problem z bridżami - wiemy już, że nie zależy to od wersji Proxa (na 1.1 czyli debian eth i 1.3 czyli debian lenny jest to samo)

Szczegóły wkrótce. BRB

Zanim cokolwiek zrobisz sprawdź projekt routera z LMS (kliknij). Być może zaoszczędzisz sobie dużo roboty

Paczki znajdują się tu: [i386] [amd64]

Paczki zostały przygotowane dla architektur x86 oraz amd64 zatem co kto lubi. Patche pochodzą z serwisu linuxbox.pl - jego właściciel zrobił na prawdę olbrzymią furę dobrej roboty. Krótkie howto co zrobić z paczkami:

1. ściągnąć

2. dpkg -i *.deb

3. reboot

4. przetestować zgodnie z plikiem, w którym to opisano

W moich testach wypadło bez zarzutu. Nie muszę chyba dodawać, że paczki powstały w środowisku zwirtualizowanym przez Proxmoxa?