Ten rozdział zawiera ogólne pytania dotyczące netfiltra (i nie tylko) jakie napotkaliśmy na liście dyskusyjnej.
Netfilter i IPtables są zintegrowane z jądrami serii 2.4.x. Pobierz ostatnie jądro z http://www.kernel.org/ lub z jednego z mirrorów.
Narzêdzie przestrzeni użytkownika (userspace) 'iptables' jest dostêpne na stronach domowych i mirrorach : http://www.netfilter.org/, http://www.iptables.org/.
Nie, nie ma. Ale jeśli ktoś chce zacząæ, nie powinno to byæ zbyt trudne z uwagi na przejrzysty interface do stosu sieci.
Proszê informujcie nas o pracy w tej dziedzinie.
Jeśli jesteś przyzwyczajony do maskarady na Linuksach 2.2, zawsze używałeś modułu ip_masq_icq by działaly bezpośrednie połączenia ICQ klient-klient.
Nikt nie zaimplementował ponownie tego modułu do netfiltra, ponieważ protokół ICQ jest ohydny :) Ale myślê, że to kwestia czasu zanim bêdzie dostêpny.
Rusty kiedyś wskazał na to, że tylko moduły dla protokołów z przynajmniej jednym wolnym klientem i jednym wolnym serwerem bêdą integrowane do głównej dystrybucji netfiltra. Co do ICQ, darmowi są tylko klienci, wiêc kryteria odrzucają ten moduł. (wolnym w sensie swobody, nie jak wolny żółw czy darmowy, tj. definicja RMS - Richarda M. Stallmana)
Niektóre z nich nie są wymagane, a niektóre nie zostały jeszcze przeniesione do netfiltra. Netfilter wykonuje pełne śledzenie połączeñ (connection tracking) nawet dla UDP i ma zasadê by nie przeszkadzaæ pakietom w miarê możliwości, wiêc czasami to 'po prostu działa'.
Jądra 2.4.x są stabilną wersją, wiêc nie możemy ot tak wysyłaæ aktualnego kodu do głównego jądra. Cały kod jest rozwijany i testowany najpierw w netfilter patch-o-matic. Jeśli chcesz używaæ którejś z nowych funkcji netfiltra, bêdziesz musiał zastosowaæ jedną lub kilka łat z patch-o-matic. Możesz znaleźæ patch-o-matic w najnowszym pakiecie netfiltra (lub oczywiście w CVS) i ściągnąæ ze strony domowej netfiltra.
patch-o-matic ma teraz trzy różne opcje:
Pierwszy jest po ty by upewniæ siê czy wszystkie ważne poprawki (które zostały wysłane do utrzymujących jądro) są w jądrze. Drugi `most-of-pom` dodatkowo pyta o nowe łaty, które można zastosowaæ bez konfliktów. Trzecia opcja `patch-o-matic` jest dla prawdziwych ekspertów którzy chcą widzieæ wszystkie łatki - ale miej świadomośæ, mogą powodowaæ konflikty.
patch-o-matic ma fajny interfejs użytkownika. Po prostu wpisz
make most-of-pom (lub pending-patches lub patch-o-matic, spójrz wyżej)
lub, jeśli źródła jądra nie są w /usr/src/linux to użyj
make KERNEL_DIR={ścieżka-do-jądra} most-of-pom
w najwyższym katalogu pakietu netfilter. patch-o-matic sprawdza czy każda łatka zaaplikowałaby siê w źródle jądra jakie masz zainstalowane. Jeśli tak, zobaczysz opcje: możesz przeczytaæ wiêcej o łacie, zastosowaæ go lub przejśæ do nastêpnego ...
Wiêcej informacji na temat patch-o-matic jest w netfilter extensions HOWTO. http://www.netfilter.org/documentation/index.html#HOWTO
ipnatctl był używany by postawiæ regułki NAT z przestrzeni użytkownika (userspace) w początkowych wersjach rozwojowych netfiltra podczas jąder 2.3.x. Nie jest już potrzebny, zatem nie jest dostêpny. Cała jego funkcjonalnośæ jest w iptables. Zerknij w NAT HOWTO na stronach domowych netfiltra.
Nie, rdzeñ NAT nie obsługuje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek rodzaju.
SIP (Session Initiation Protocol) jest dośæ złożony, szczególnie w transmisji poprzez firewalle i urządzenia NAT. Wstêpną propozycją była komunikacja pośrednika (proxy) poprzez FCP (Firewall Control Protocol) przy użyciu filtra pakietów. Została założona grupa robocza IETF MIDCOM, a tymczasem ludzie chcą używaæ SIP.
Zespół netfilter/iptables nie ma zasobów by zaimplementowaæ obsługê SIP dla conntrack/NAT, jednak zawsze jesteśmy otwarci dla sponsorów :)
Odpowiedź jest prosta 'tak' i 'nie'.
Jeśli masz na myśli pełny failover, podczas którego cała informacja o stanie jest zachowana: Nie bardzo. Synchronizacja stanu miêdzy wêzłami jest trudnym procesem. Harald (z netfilter core team) opublikowal dokument na ten temat, ale nie znalazł sponsora by ufundowaæ rozwój. Tymczasem, mozesz użyæ naszego 'connection pickup', która [po failoverze] próbuje podchwyciæ już ustanowione połączenia: Może byæ wystarczające w zależności od wymagañ.
Jeśli chcesz przechowaæ połączenia NAT: Nie.
Jeśli filtrujesz bez przechowywania stanu (stateless): Tak