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.

Zatem zabraliśmy się do testów. Nie chodziło o jedna konkretną aplikację zatem odpadł jakiś przypadkowy błąd. Pierwszym pomysłem (zazwyczaj najlepszym) okazał się upgrade Flash Player'a do najnowszej wersji pod niezależnymi przeglądarkami (IE8, FF). Kolejne odpalenie "niedziałających" aplikacji udowodniło samemu programiście, że jednak prawdę inni mówili / pisali. Objaw był następujący.

W Internet Explorer w wersji 8 (wersja Win nie istotna) z Flash Playerem w wersji najnowszej czyli 10.0.42.34 aplikacja flash a konkretnie animacja wywala się mniej więcej w samym środku. Reakcja przeglądarki jest dwojaka: Internet Explorer wykonał błąd i zostanie zamknięty lub reset strony z informacją, że została przeładowana po błędzie. Dodajmy na marginesie, że firefox nie przedstawiał podobnych błędów.

Pierwsza próba zlokalizowania problemu. Wywalamy Flash Player 10 i próbujemy zamontować poprzednią wersję. Ku naszemu zdziwieniu flash-installer informuje nas, że jest wersja nowsza i starszej zainstalować nie można. Kolejne podejście to już pytanie do nieśmiertelnego, ponadczasowego, wszystkowiędzącego wujka Googla, którego mleko firmowe niedługo będziemy oglądać w naszej lodówce a program jego chłodzenia synchronizować będziemy z oczywiście darmowym serwerem GoogleCoolingPlan.com o adresie IP 9.9.9.9 Wujek przedstawił wiele informacji na temat, że problem jest ale niestety żadnych konkretnych jak go rozwiązać.

No niestety. Należało odpalić oryginalna wersję Adobe Flash CS4, znaleźć źródła aplikacji i porzeźbić troszeczkę w kodzie. Po 2-3 godzinach zabawy, testowania, naciskania F5 w przeglądarce znalazła się funkcja rodem z Action Script 2.0, która powodowała problem (w zasadzie metoda a nie funkcja). Załóżmy, że dynamicznie ładujemy obrazek do aplikacji flash, konkretnie do obiektu, za pomocą metody loadClip(). Wszystko jest wporzo dopóki, nie chcemy usunąć tego obrazka stamtąd za pomocą metody removeMovieClip(). Okazuje się, że to jest jedyny sprawca błędu, o którym słychać było głośno od rana. Rozwiązanie jest banalne. Zamiast felernej metody należy klepnąć unloadMovie() w obiekcie i wszystko cudownie zaczyna wracać do normy.

Podsumowując dyskusję chciałbym zauważyć, że jeśli nie mamy dostępu do źródeł aplikacji flash to jesteśmy w stanie zrobić bardzo mało (iść na fajkę, kawę itd). W Sieci znalazłem masę informacji o tego typu problemach i zazwyczaj dotyczyły one darmowych aplikacji lub aplikacji, które zostały wykonane na tzw. zlecenie. W supporcie Adobe nie znalazłem najmniejszej informacji o tym, że w którejś subwersji Flash Player'a cokolwiek zostało zmienione. Niestety pechowa metoda jest dość powszechnie używa w sieci więc zakładam, że problem jest dużo większy niż mi się wydaje.

• 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]

Muszę przyznać, że powoli straciłem wiarę w moc i możliwości Proxmoxa jako narzędzia do wirtualizacji z serii Open-Source. Znalazło się jednak troszkę czasu aby przetestować to na sprzęcie Intela. W obroty poszedł quadzik Q9400 2.66GHz na rdzeniu, płyta Gigabyte GA-EG45M-DS2H z 8GB ramu 4 x KVR800D2N5K2/2G. Na tym sprzęcie do tej pory trzymany był zwirtualizowany hosting firmowy oraz kilka innych wirtualek znajomych, które były kontrolowane przez KVM. Zrobiliśmy test, który wydawał się być najgłupszym pod księżycem (btw. dziś ładny rogalik na niebie świeci :P). Zostawiliśmy odpalone te wszystkie maszyny - w sumie 8 sztuk. Następnie dołożyliśmy jeszcze jedną wirtualkę KVM z routerem moim starym postawionym na archaicznym już Slacku 11-tym. Przy okazji znów wielkie pokłony w stronę Kadzbiego, który to pokazał mi jak przez ssh skopiować działający żywy system na inną maszynę i jeszcze odpalić to hehe. Załatwia to linijka:

tar -pcf - ./ | ssh remoteuser@remotehost tar -C /path/to/remote/dir -pxf -

która pakuje fizyczny system, w locie przesyła go na zdalną maszynę i na niej rozpakowuje w wybrany katalog. Wystarczyło więc odpalić wirtualną maszynę, zbootować ją np z Gentoo Minimal, przypisać adres IP, odpalić serwer ssh (/etc/init.d/sshd start) a następnie zmienić hasło na użytkownika root i skopiować. Wcześniej przygotowano odpowiednią partycję, sformatowano i zamontowano w /path/to/remote/dir z powyższego ciągu znaczków. Później wydano 4 magiczne polecenia:

mount -o bind /dev /path/to/remote/dir/dev

mount -t proc /proc /path/to/remote/dir/proc

chroot /path/to/remote/dir/

lilo

które przeteleportowały nas w chrootowane środowisko naszego routera i zaaktualizowały lilo w MBR. Po reboocie ku naszemu zdziwieniu wszystko od razu zadziałało. Sieć śmiga przecudnie przy podobnej ilości użytkowników i transferach przez router rzędu 20Mbps (bo takie łącze mamy). Na razie obserwujemy. Proxmox ani router i inne wirtualki nie dają żądnych negatywnych znaków. Warto dodać w celach informacyjnych, że do maszyny z mamusią zostały dołożone dwie fizyczne karty sieciowe Intel PRO Fast Ethernet, z których utworzyliśmy dwa potrzebne bridże.

Zauważmy również, że zostało tu zamontowane podstawowe jądro 2.6.24.5 ze Slackware 12.1 delikatnie połatane. Jądro to nie obsługuje VIRTIO zatem wirtualka też. Jestem gotów wysnuć pewną hipotezę. Niemożliwe było osiągnięcie celu, który założyliśmy na tanim gównianym sprzęcie firmy AMD. Intel w tym wypadku przeszedł nasze oczekiwania (ostrożna hipoteza). W ramach argumentacji dopowiedzmy, że moduł KVM jądra matki, który odpowiada za kontrolę nad wirtualnym routerem jest inny dla Intel i inny dla AMD. Według mnie ten dla Intela jest "lepszy" bo działa.

Tworząc maszynę wirtualną wybieramy typ dysku VIRTIO (nie ATA, nie SCSI) oraz typ karty sieciowej VIRTIO. Opcje te dostępne są w Proxmoxie o wersji wyższej niż 1.3. Instalujemy na tym np. Debian Lenny w wersji netinstall. Instalka ładnie wykryje nam dysk o nazwie /dev/vda i cała reszta tu już to, co znacie z życia codziennego.

Po odpaleniu systemu na dzieciaku wydajemy polecenie lsmod i zobaczymy wśród podładowanych modułów między innymi:

• virtio_pci
• virtio_net
• virtio_blk

Następnie klepiemy polecenie lspci i powinniśmy zobaczyć coś koło tego:

• 00:03.0 Ethernet controller: Qumranet, Inc. Device 1000
• 00:04.0 Mass storage controller: Qumranet, Inc. Device 1001
• 00:05.0 RAM memory: Qumranet, Inc. Device 1002

Dla świętego spokoju dajmy jeszcze df -h i być powinno tam gdzieś na przykład:

/dev/vda1

Na sieci znalazłem info, że za pomocą VIRTIO można nawet 11-krotnie przyspieszyć wirtualny dysk. Aby jednak osiągnąć to, należy zmienić algorytm IO-Schedulera z [cfq] na [deadline] przez rekompilację jądra systemu (na dobre) lub "w locie" za pomocą polecenia:

echo deadline > /sys/block/sda/queue/scheduler

gdzie sda to nasz dysk. Nie testowałem tego jeszcze.

Na razie testowa konfiguracja chodzi u kolegi, który ma około 150 klientów przez to przepuszczonych. Kolejne problemy jakie spotkaliśmy to kompilacja jądra ze wszystkim odpowiednimi dla routera opcjami. Zaznaczam od razu, że paczki rabbit nie działają na maszyna z dyskiem VIRTIO ponieważ nie zostało to jeszcze wkompilowane a initrd nie używam. To będzie wyzwanie na kilka najbliższych jesiennych szarych wieczorów.

PS. dzięki kadzbi za pomoc.

Instalkę Proxmoxa ściągnąć można z sieci jako obraz iso, z  którym wiadomo co się robi. Sam proces instalacji jest dokładnie opisany na oficjalnej stronie www i jest bajecznie prosty. Warto tylko dodać, że dystrybucja nie posiada wsparcia dla sotfwarowego raida a partycje instaluje jako LVM2 więc przed przystąpieniem do montażu Proxmoxa odwiedź najpierw wujka googla i sprawdź co to jest "Logical Volume Management". Swoją drogą jakiś czas temu uparłem się i postawiłem Proxa na softowym raid1 ale proces ten był mocno skomplikowany i w czasie testów na "żywym organizmie" stwierdziłem, że działa to wszystko strasznie powoli.

Apropos tematu postu. Proxmox umożliwia pracę w dwóch trybach wirtualizacji:

• Containers (OpenVZ)  czyli dziecko korzysta z jaja mamy
• Fully Virtualized (KVM, Qemu) czyli dziecko ma swój własny emulowany sprzęt, do tego potrzeba dzieciakowi Intel-VT lub AMD-V

Pierwsza opcja moim zdaniem nadaje się perfekcyjnie jako baza dla serwerów hostingowych, pocztowych, dns itd ponieważ z poziomu mamusi można przeglądać bezpośrednio system plików dziecka. Jest to nieocenione w przypadku systemów backupowych (backup danych). W przypadku OpenVZ mamy jednak bardzo ograniczone możliwości korzystania z iptables czyli tworzenia firewalla. Obsługa sieci dla OpenVZ odbywa się na poziomie warstwy trzeciej przy użyciu routingu poprzez wirtualne interfejsy lub na poziomie warstwy drugiej (bridż). Wszystkie procesy uruchamiane przez dzieci są widzialne pod:

ps ax

wykonane u mamusi. Daje nam to dodatkową kontrolę nad nimi (np kill -9 hehe). Dodatkowo z poziomu mamy można przejść bezpośrednio na # konsoli wirtualnej maszyny bez znajomości hasła superusera prostym poleceniem:

vzctl enter id_maszyny

Wirtualizacja na poziomie systemu operacyjnego, którą jest OpenVZ umożliwia pracę jedynie w środowisku linux pod ograniczoną ilością dystrybucji. Oficjalne i nieoficjalne templatki VZ można znaleźć bez problemu w sieci.

Druga opcja (Qemu, KVM) przeznaczona jest bardziej dla routerów, które muszą mieć pełny dostęp do iptables oraz dla systemów operacyjnych != linux-kernel. Nic nie stoi na przeszkodzie aby zainstalować sobie WindeXP, Viste (ugh) albo inne cuda na czymś takim. Pytanie tylko po co Pełna wirtualizacja zabiera nam jednak możliwość dostępu do drzewa katalogów dzieci z poziomu matki. Nie ma również możliwości logowania do dziecka bez autoryzacji. Obsługa sieci jest możliwa tylko na poziomie warstwy drugiej (bridż).

Całością zarządzać można na dwa sposoby:

• poprzez konsolę
• poprzez gui ssl-owe przez przeglądarkę

Praca z Proxmoxem jest dość intuicyjna. Jeśli znasz podstawy sieci (warstwa 2 i 3) to odpalenie wirtualizacji zajmie Ci max godzinę zegarową. Jeśli nie - zapytaj kogoś kto zna - będzie szybciej

Kolega Fair jest w trakcie tworzenia panelu dla klienta dla Proxmox, który Wam polecam. Kliknij tu po więcej szczegółów.