netfilter/iptables FAQ
Harald Welte <laforge@netfilter.org> ,
Tłumaczenie: Maciej Sołtysiak
Version $Revision: 566 $, $Date: 2003-12-23 20:18:45 +0100 (mar, 23 dic 2003) $,
Tłumaczenie: Środa 15 Października 2003 $
Ten dokument zawiera najczęściej zadawane pytania (Frequently Asked Questions) występujące na liście
dyskusyjnej netfilter. Komentarze / dodatki / objaśnienia są mile widziane
i powinny być kierowane do utrzymującego FAQ.
Pytania ogólne
Ten rozdział zawiera ogólne pytania dotyczące netfiltra (i nie tylko) jakie
napotkaliśmy na liście dyskusyjnej.
Skąd mogę wziąć netfilter/iptables?
Netfilter i IPtables są zintegrowane z jądrami serii 2.4.x.
Pobierz ostatnie jądro z � lub z jednego z
mirrorów.
Narzędzie przestrzeni użytkownika (userspace) 'iptables' jest dostępne na
stronach domowych i mirrorach :
�,
�.
Czy jest wersja netfiltra na Linuksa 2.2?
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.
Czy jest moduł ICQ conntrack/NAT?
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)
Co się stało z modułami ip_masq_vdolive / ip_masq_quake?
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'.
O co chodzi z patch-o-matic i jak to się używa?
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:
make pending-patches
make most-of-pom
make patch-o-matic
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.
�
Gdzie znajdę ipnatctl i więcej informacji na ten temat?
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.
Czy iptables/ip6tables jest w stanie zrobić IPv6 NAT?
Nie, rdzeń NAT nie obsługuje transjacji IPv6 lub IPv6/IPv4 jakiegokolwiek
rodzaju.
Czy są plany obsługi SIP?
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 :)
Czy netfilter/iptables wspiera failover/HA?
Does netfilter/iptables support failover/HA?
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
Problemy podczas kompilacji
Nie mogę skompilować iptables-1.1.1 z jądrem >= 2.4.0-test4
To znany problem. Mechanizm wykrywania które łaty zastosować jest zepsuty.
Spróbuj "make build" zamiast "make".
Lepsze rozwiązanie: zaktualizuj do iptables-1.1.2 lub późniejszych.
Nie mogę skompilować iptables 1.1.0 z ostatnimi jądrami (>= 2.3.99-pre8)
Wewnętrzne struktury w iptables zmieniły się. Uaktualnij iptables do >= 1.1.1
Niektóre łaty patch-o-matic z iptables-1.2.1a nie działają z jądrem >= 2.4.4
Proszę użyj iptables-1.2.2 lub netfilter CVS.
ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP nie kompilują się
Najprawdopodobniej doświadczasz problemów z funkcją zwaną
ip_nat_setup_info.
Jeśli używasz iptables <= 1.2.2, MUSISZ zastosować łaty 'dropped-table' i 'ftp-fixes'.
Jeśli używasz iptables > 1.2.2 lub świeży CVS, proszę nie stosuj
`dropped-table', gdyż jest niekompatybilny z BALANCE, NETMAP, irc-nat, SAME
i talk-nat.
Mam problemy z jądrem z łatami Alana Coxa 2.4.x-acXX
Główny zespół netfiltra opiera rozwój na jądrach Linusa, więc serii -ac
używaj na własne ryzyko.
ERROR: Invalid option KERNEL_DIR=/usr/src/linux-2.4.19
Założę się, że usiłujesz uruchomić coś podobnego do :
# ./runme pending KERNEL_DIR=/usr/src/linux-2.4.19
Ale bash/sh nie jest jak make a zmienna nie moze byc podana jako parametr.
Musisz ustawic zmienna przed uruchomieniem skryptu runme :
# KERNEL_DIR=/usr/src/linux-2.4.19 ./runme pending
Problemy podczas pracy
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb
Ta wiadomość jest drukowana przez kod NAT, ponieważ pakiety multicastowe
trafiają do tabeli NAT, a connection tracking nie obsługuje teraz multicastów.
Jeśli nie masz pojęcia co to jest multicast lub zupełnie nie potrzebujesz tego,
używaj:
iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
Mój syslog lub konsola pokazuje wiadomość:
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
Ta wiadomość jest drukowana przez kod NAT. Zrzuca pakiety, ponieważ by NATować
potrzebuje mieć poprawne informacje o stanie połączenia. Ta wiadomość jest
drukowana dla wszystkich pakietów, dla których connection tracking nie mógł
uzyskać informacji o stanie połączenia.
Prawdopodobne powody to:
osiągnięto maksymalną liczbę wpisów w bazie śledzonych połączeń
nie można określić pakietu odpowiadającego na połączenie (multicast, broadcast)
kmem_cache_alloc zawodzi (brak pamięci)
odpowiedź na niepotwierdzone połączenie
pakiet multicastowy (zobacz poprzednie pytanie)
pakiet icmp jest za krótki
pakiet icmp jest sfragmentowany
pakiet icmp ma złą sumę kontrolną
Jeśli chcesz bardziej szczegółowo logować te pakiety (tj. jeśli
podejrzewasz, że to zdalna sonda (remote probe) / pakiety skanujące), użyj następującej
regułki:
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
Tak, musisz wstawić regułkę w tabeli mangle, ponieważ pakiety są zrzucane
przez kod NAT zanim dotrą do tabeli filter.
ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
Mój syslog lub konsola regularnie pokazuje mi napis w stylu:
ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
foo
Zasadniczo nie ma się czym przejmować, szczególnie gdy N i
M sa 1, a po tej wiadomości jest , reusing.
W szczególności wersje jądra (2.4.19<=x<=2.4.21-pre3), ten
komunikat był drukowany dla FTP - I faktycznie może się zdarzyć podczas
normalnego działania FTP.
Z nadchodzącymi wersjami jądra (>=2.4.21-pre4) ta wiadomość nie jest
drukowana by nie mylić użytkownika. Jeśli nadal otrzymujesz takie
wiadomości, skontaktuj się z listą: �.
Nie udaje mi się użyć netfiltra razem z Linux bridging code
Więc chcesz zbudować całkowicie przezroczysty firewall? Świetny pomysł!
Niestety bridging code pomija normalny stos sieci włącznie z netfilterem.
Ale ktoś pisze nowy bridging code, zerknij na �
Zauważ, że wsparcie dla bridge'ującego firewalla jest uważane za skrajnie
eksperymentalne.
Moduł IRC nie obsługuje DCC RESUME
Jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyć ich.
Jeśli jest to firewall bez NAT, powinno działać.
Łatki mile widziane.
Jak działa SNAT do wielu adresów?
Netfilter stara się jak najmniej zmieniać pakiety. Więc jeśli mamy
świeżo-przeładowaną maszynę i ktoś za SNAT'em otwiera połączenie z loklanym
portem 1234, netfilter tylko zmienia adres IP a port zostaje ten sam.
Jak tylko ktoś inny otworzy inne połączenie z tym samym źródłowym portem,
netfilter musiałby zmienić IP i port jeśli ma tylko jeden IP dla SNAT.
Ale jeśli jest dostępny więcej niż jeden, ponownie tylko musi
zmieniać część IP.
ip_conntrack: maximum limit of XXX entries exceeded
Jeśli zauważysz następujące wpisy w syslogu, wygląda na to, że baza danych
conntrack nie ma wystarczającego miejsca na twoje środowisko. Connection
tracking domyślnie obsługuje do pewnego poziomu liczbę współbieżnych połączeń.
Ta liczba zależy od rozmiaru pamięci (przy 64MB: 4096, 128MB: 8192, ...).
Możesz z łatwością zwiększyć maksymalną liczbę rejestrowanych połączeń, ale
miej na uwadze, że każde połączenie zjada około 350 bajtów nieswappowalnej
pamięci jądra.
By zwiększyć ten limit do np 8192, wpisz:
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
By zoptymalizować wydajność, zwiększ też ilość koszyków funkcji hashującej
używając parametru hashsize podczas ładowania modułu ip_conntrack.o.
Zwróć uwagę na fakt, iż przez cechy obecnego algorytmu haszującego, parzysta
liczba koszyków funkcji haszującej (i w szczególności potęgi liczby 2) są
złym rozwiązaniem.
Przykład (z 1023 koszykami):
modprobe ip_conntrack hashsize=1023
Jak wylistować śledzone / maskaradowane połączenia, podobnie jak 'ipchains -L -M' w 2.2.x
Jest plik w filesystemie proc, zwany /proc/net/ip_conntrack.
Możesz wyświetlić jego zawartość pisząc:
cat /proc/net/ip_conntrack
Jak wylistować dostępne tabele IP?
Wszystkie dostępne tabele IP są w:
cat /proc/net/ip_tables_names
iptables-save / iptables-restore z iptables-1.2 wywala segfaulty
Znany błąd. Uaktualnij do najświeższego CVS lub użyj iptables >= 1.2.1
jak tylko będzie dostępne.
Mijają wieki zanim iptables -L wyświetli regułki
To dlatego, że iptables robi DNS lookup dla każdego adresu. Jako że każda
regułka składa się z dwu adresów, w najgorszym przypadku wychodzi na 2
DNS lookupy na regułkę.
Problem jest, jeśli używasz prywatnych adresów IP (10.x.x.x lub 192.168.x.x),
DNS nie jest w stanie rozwiązać nazwy hosta i czekamy na timeout. Suma
wszystkich timeoutów może być bardzo duża, w zależności od zestawu regułek.
Używaj opcji -n (numeric) w iptables by pominąć reverse DNS lookups.
Jak zrobić by target LOG nie logował na konsolę?
Musisz skonfigurować syslogd odpowiednio:
Target LOG loguje do facility kern przy priorytecie warning (4).
Zobacz strony man od syslogd.conf by przeczytać więcej o facilities i
priorytetach.
Domyślnie, wszystkie wiadomości na priorytecie bardziej poważnym niż debug (7)
są wysyłane na konsole. Jeśli zwiększysz to do 4, zamiast 7, sprawisz, że
logi nie będą się pojawiały na konsoli.
Miej na uwadze, że to także pociąga za sobą inne ważne logi i nie pojawią
się na konsoli (to nie wpływa na syslog).
Jak zbudować transparent proxy używając squida i iptables?
Na początku, oczywiście, potrzebujesz odpowiedniej regułki DNAT lub REDIRECT.
Użyj REDIRECT tylko gdy squid chodzi na tej samej maszynie co NAT. Przykład:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
Potem, musisz skonfigurować odpowiednio squida. Możemy tylko dać
krótkie wskazówki, odsyłam do dokumentacji squida po szczegóły.
squid.conf dla Squid 2.3 powinien wyglądać podobnie do tego:
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Squid 2.4 potrzebuje dodatkowej linii:
httpd_accel_single_host off
Jak używać target LOG / Jak mogę LOGowac i DROPowac?
Target LOG jest czymś co nazywamy "niekończący target", tj. nie kończy
podróży pakietu. Jeśli użyjesz target LOG, pakiet będzie zalogowany i
podróż będzie kontynuowana od następnej regułki.
Więc jak mam logować i zrzucać pakiet jednocześnie? Nic prostszego, możesz
stworzyć własny łańcuch, zawierający te dwie regułki:
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
Teraz za każdym razem jak będziesz chciał logować i zrzucić pakiet, możesz
po prostu użyć "-j logdrop".
Jak mogę zatrzymać robaka XYZ używajać netfiltra ?
Krótka odpowiedz brzmi: nie da się tego zrobić prawidłowo używając
netfiltra. Większość robaków używa prawidłowych protokołów wyższej warstwy
(tj. HTTP, SMTP (np. VB script w załączniku listu), lub wykorzystuje
jakąkolwiek inną znaną dziurę w demonie obsługującym protokół). Mówiąc
protokół wyższych wartsw, mamy na myśli ponad TCP/IP. Jako że iptables nie
rozumie protokołów wyższych wartsw, jest prawie nie możliwe filtrowanie ich
prawidłowo. Do tego potrzeba proxy filtrujących na poziomie aplikacji.
Proszę nie używaj matchu string z patch-o-matic zamiast takiej aplikacji.
Nie da rady sobie z fragmentowanymi pakietami (tj. zapytanie HTTP rozbite na
dwa pakiety TCP), z technikami unikania systemów IDS, itd... zostałeś
ostrzeżony! Match string jest przydatny ale w innych celach.
jądro loguje: Out of windows data xxx
Używasz łaty tcp-window-tracking z patch-o-matic, którego kod śledzi czy
pakiety dopuszczonych strumieni TCP mają zgodne numery
sekwencji/potwierdzenia (sequence/acknowledgement), rozmiary segmentów, itd.
pakietów. Kiedy wykryje, że pakiet jest nieakceptowalny (out of the window),
zaznacza go jako INVALID i drukuje komunikat.
Nowsze wersje logują pakiet i dokładny warunek, którego nie spełnił:
ACK is under the lower bound (prawdopodobnie zbyt opóźniony ACK)
ACK is over the upper bound (potwierdzane dane jeszcze nie dotarły)
SEQ is under the lower bound (retransmitowano dane już potwierdzone)
SEQ is over the upper bound (ponad oknem odbiorczym)
Także, w nowszych wersjach logowanie można całkowicie wyłączyć poprzez
sysctl
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
Dlaczego system śledzenia połączeń (connection tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?
Wpierw, sprawdzy czy nie używasz jądra 2.4.20. Jeśli tak, zaplikuj
natychmiast patch spod adresu: �! The 2.4.20 kernel did contain a bug resulting in lots of bogus UNREPLIED conntrack entries (see �).
Sprawdziłeś /proc/net/ip_conntrack i znalazłeś wpisy połączeń w stanie
UNREPLIED o bardzo wysokim czasie (aż do pięciu dni) i zastanawiasz się
dlaczego marnujemy wpisy conntrack (które oczywiście nie są połączeniami)?
Odpowiedź jest prosta: wpisy UNREPLIED są tymczasowe, tj. jak tylko
zabraknie miejsca (osiągniemy /proc/sys/net/ipv4/ip_conntrack_max), kasujemy
stare wpisy UNREPLIED. Innymi słowy zamiast trzymać puste wpisy, wolimy
trzymać prawdopodobnie cenne informacje dopóki wolne wpisy są naprawdę
potrzebne.
Dlaczego nie zaimplementowano opcji 'iptables -C' (--check) ?
Po pierwsze dlatego, że jesteśmy leniwi ;). A szczerze mówiąc, implementacja
opcji check jest prawie niemożliwa jak tylko zaczynamy stateful firewalling.
Tradycyjne firewalle nie przetrzymujące informacji o stanie połączenia
(są stateless) opierają swoje decyzje tylko w oparciu o informacje zawarte
w nagłówkach pakietów. A że śledzeniem połączeń (i regułami opartymi o '-m
state'), decyzja o filtrowaniu zależy od nagłówka+dane, a także od
nagłówka+dane poprzednich pakietów danego połączenia.
Czemu nie mogę użyć REJECT w łańcuchach PREROUTING ?
REJECT stosuje się do filtrowania. Tabela filter ma łańcuchy
INPUT/OUTPUT/FORWARD, zatem REJECT może być użyty tylko w tych łańcuchach
(i pod-łańcuchach, rzecz jasna).
Użytkownicy Netfiltra nie filtrują pakietów w tabelach nat lub mangle.
'iptables: Invalid argument' po aktualizacji jądra (tabela nat)
Własnie zaktualizowałeś jądro i nagle niektóre komendy (szczególnie
w tabeli 'nat'), powodują ten komunikat, np:
# iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
iptables: Invalid argument
To się zdarza gdy rozmiary struktur między przestrzenia jądra a użtykownika
się zmieniają. Będziesz musiał ponownie skompilować program przestrzeni
użtykownika używając plików nagłowkowych swojego nowego jądra. To się
zdarza tylko gdy zaaplikowałes (ty, lub dostawca twojego jądra) niektóre
łaty do starego lub tylko do nowego jądra. Nie powinno to się zdarzać
z waniliowymi jądrami z kernel.org. Jeśli jednak, poinformuj proszę o tym
listę netfilter-devel.
Dlaczego nie mogę używać REJECT w łańcuchu PREROUTING?
Target REJECT służy do filtrowania. Tabela filter ma łańcuchy
INPUT/OUTPUT/FORWARD, zatem REJECT może być tylko używany w tych łańcuchach
(i podłańcuchach, naturalnie).
Użytkownicy netfiltra nie filtrują pakietów w tabeli nat czy mangle.
Pytania o rozwój netfiltra
Nie rozumiem jak używać target QUEUE z przestrzeni użytkownika (userspace)
Biblioteka zwana libipq jest dostarczona do obsługi pakietów z przestrzeni
użytkownika. (userspace).
Jest dokumentacja do tego w postaci stron w manualu. Musisz skompilować i
zainstalować komponenty rozwojowe iptables:
make install-devel
potem zobacz libipq(3).
Może także będziesz zainteresowany implementacją libipq dla Perla, Perlipq w:
�. Sama implementacja
jest przykładem użycia biblioteki.
Inne przykłady kodu:
testsuite/tools/intercept.c z CVS netfiltra
ipqmpd (zobacz �)
nfqtest, część netfilter-tools (zobacz �)
Jerome Etienne's WAN simulator (zobacz �)
Moja aplikacja oparta na libipq zgłasza "Failed to receive netlink message: No buffer space available"
Oznacza to, że bufor gniazda (socket) Netlink po stronie jądra wyczerpał pamięć;
aplikacja przestrzeni użytkownika nie jest w stanie obsłużyć ilości danych
dostarczonych z jądra.
Czy jest możliwe by zwiększyć bufory jądra bym nie wpadał na ten
problem?
Tak, są to standardowe gniazda (sockety) Netlink i możesz dostroić rozmiary buforów
wejściowych (receive buffer) poprzez /proc/sys/net/core, sysctl lub używać
opcji gniazda (socketa) SO_RCVBUF na deskryptorze pliku.
Możesz także spróbować zapewnić by aplikacja czytała dane najszybciej jak to
jest możliwe. Jeśli nie potrzebujesz całego pakiety, spróbuj kopiować mniej
danych do przestrzeni użytkownika (zobacz ipq_set_mode(3)).
Chcę wnieść wkład w źródła, ale nie wiem jak
Główny zespół netfiltra utrzymuje listę TODO, która zawiera porządane
zmiany / nowe cechy. Możesz pobrać tę listę poprzez anonimowy CVS,
instrukcje są na stronie głównej netfiltra. Ewentualnie możesz także
pobrać przez CVSweb �
Naprawiłem błąd lub napisałem nowy moduł. Co mam zrobić?
Jeśli chcesz to opublikować, wyślij to listy dyskusyjnej netfilter-devel.
Instrukcja jak zostać subskrybentem jest w �.
Prawidłowy sposób wysyłania łat:
Temat zaczynający się od [PATCH]
Załączone prosto w ciele wiadomości, bez MIME.
wpis cvs-checkin/Changelog poza diffem.
forma `diff -u old new', spoza katalogu root pakietu (tj. może być stosowany z -p1 będąc pod odtarowanym katalogiem.
Jeśli napisałeś nowe rozszerzenie, lub dodałeś nowe opcje do starego
rozszerzenia, zwykle dobrze jest zaktualizować także
netfilter-extension-HOWTO by włączyć opis nowej funkcjonalności. Dodatkowo,
przyciągnie to więcej użytkowników do rozszerzenia i pozwoli na uzyskanie
więcej informacji od użytkowników.