Paweł Goleń, blog

Pierwsza sprawa - generowanie certyfikatu dla bramki. Jest to dobrze opisane w manualu dla isakmpd. W manualu jest informacja, że pole subjectAltName nie jest obowiązkowe, ale mocno zalecane. Cóż, moje wrażenie jest takie, że ono tak trochę mocno potrzebne jest. Wcześniej w ramach subjectAltName dałem nazwę DNS, ale okazało się, że chyba nie do końca prawidłową. Bramka ma dwa interfejsy, adres (no, po skorzystaniu z DNS oczywiście) jednego interfejsu to puffy.domena a drugiego (tego z WiFi) puffy.wifi.domena. Certyfikat, który pierwotnie wystawiłem był właśnie dla puffy.domena, natomiast isakmpd jest przybindowane do interfejsu WiFi, w rezultacie isakmpd zachowywało się tak, jakby nie docierało do niego, że ten certyfikat to właśnie do niego należy. Tym razem wystawiłem certyfikat na subjectAltName, ale na adres IP by nie było nieporozumień i od razu zaczęło działać.

Druga sprawa - konfiguracja isakmpd przez isakmpd.conf. Mój plik konfiguracyjny wygląda mniej wiecej tak:

[General]
Listen-on=              X.Y.Z.Q
Use-Keynote=            Yes
Delete-SAs=             Yes

[Phase 1]
Default=                ISAKMP-Default-WiFi

[Phase 2]
Passive-connections=            IPsec-WiFi-connection

[X509-certificates]
CA-directory=           /etc/isakmpd/ca/
Cert-directory=         /etc/isakmpd/certs/
CRL-directory=          /etc/isakmpd/crls/
Private-key=            /etc/isakmpd/private/puffy.domena.key

[my-ID]
ID-type=                IPV4_ADDR
Address=                X.Y.Z.254

[WiFi-clients]
ID-type=                IPV4_ADDR_SUBNET
Network=                X.Y.Z.0
Netmask=                255.255.255.0

[Net-any]
ID-type=                IPV4_ADDR_SUBNET
Network=                0.0.0.0
Netmask=                0.0.0.0

[ISAKMP-Default-WiFi]
Phase=                  1
Configuration=          ISAKMP-WiFi-configuration

[ISAKMP-WiFi-configuration]
EXCHANGE_TYPE=          ID_PROT
Transforms=             3DES-SHA-RSA_SIG
Configuration=          IPsec-WiFi-connection

[IPsec-WiFi-connection]
Phase=                  2
Remote-ID=              WiFi-clients
Local-ID=               Net-any
DOI=                    IPSEC
EXCHANGE_TYPE=          QUICK_MODE

[IPsec-WiFi-configuration]
EXCHANGE_TYPE=          QUICK_MODE
Suites=                 QM-ESP-3DES-SHA-SUITE,QM-ESP-3DES-SHA-PFS-SUITE

A plik ipsec.policy tak:

Authorizer: "POLICY"
Licensees: "DN:DN_SERWERA_WYSTAWIAJACEGO_CERTYFIKATY"
Conditions: app_domain == "IPsec policy" &&
            esp_present == "yes" &&
            esp_enc_alg != "null" -> "true";

No i w tej chwili właściwie się już ipsec zestawiał ładnie, tylko nic poza pingiem i DNS nie działało. No, przesadzam. W każdym razie nie działało mi praktycznie TCP, natomiast ICMP i UDP działało całkiem znośnie. Tutaj w grę wchodziło takie wredne paskudztwo powszechnie MTU zwanym. Należy pamiętać, że ipsec dodaje swój nagłówek... Tutaj poszedłem na całkowitą łatwiznę i skorzystałem z opcji w max-mssscrub (patrz man pf.conf). I to właściwie załatwiło resztę problemów (no nie do końca, bo mogę znaleźć taką wielkość pakietu ICMP, na którą nie dostanę odpowiedzi, ale jest to na razie tak mało znaczące, że pominę to milczeniem, zaczeka na kolejny brzydki dzień), tak więc jestem szczęśliwym posiadaczem dodatkowego zabezpieczenia mojego ruchu wireless, poza WEP chroni go jeszcze IPSec, któremu trochę bardziej ufam ;)

Co jeszcze mogę pokombinować? W tej chwili mam w pf.conf wpis set skip on enc0, czyli "interfejs" ipsec nie jest uwzględniony w regułach firewalla. Nie jest to wielki problem, bo potem i tak ruch jest filtrowany na kolejnym interfejsie, natomiast jeśli ktoś sie podłączy do mojego WiFi i nie skorzysta z ipsec, to ciągle będzie mógł (przynajmniej w teorii) skorzystać z mojego łącza. Podejrzewam, że zrobię tak, że pakiety przychodzące przez enc0 będę znakował i wszystko inne (no, z dokładnością do ruchu DHCP) wchodzące przez interfejs WiFi spuszczał na /dev/drzewo. Myślę, że to nastapi w jednej z dwóch sytuacji - albo jak ktoś nieproszony zacznie się podłączać do mojego WiFi, albo jak dorobię się drugiego laptopa (bo wówczas będę się mógł pobawić więcej).

Ogólnie jestem zadowolony z WiFi, byłbym zadowolony bardziej, gdyby bateria mojego laptopa nie była nieco umarła i rzeczywiście WiFi dawało mi pewną mobilność dodatkową (tak jestem uwolniony od kabelka, ale i tak zasilacz muszę mieć wpięty...). I jeszcze jedna sprawa - niepomiernie irytuje mnie zachowanie Thunderbirda, a konkretnie jego obsługa NNTP. Nie wiem dlaczeog, ale co chwilę dostaję informację, że The operation timed out when attempting to contact news.. A to jest bzudra wierutna, bo w tym samym czasie słucham sobie on-line radia i choć może słuchu doskonałego to ja nie mam, ale jednak usłyszałbym, jakby mi przerywało. Po prostu nie wierzę, że wcina mi pakiety tylko do serwera news, ale już nie te z muzyką. O przepraszam, jeszcze jest szansa, że pakiety te wcina mi już poza moją siecią, ale też jakoś wierzyć mi się nie chce... Podejrzewam, że to raczej Thunderbird ma coś pochrzanione z obsługą wątków i trzymaniem sesji do serwera news. Pierwotne moje podejrzenie było takie, że set optimization aggressive może tutaj być powodem tych problemów (powiedzmy, że Thunderbird nie używa keep-alive i stan established wygasa z szybko, jednak nie potwierdził tych przypuszczeń. Ponieważ grep na logach z iptables również nie wykazał nic specjalnie interesującego, wracam do koncepcji z pomieszaniem w Thunderbird...