Pule VPN w trybie dual-stack: obsługa obu rodzin adresów w strongSwan

Wewnętrzne pule IPv4 i IPv6, chronione prefiksy oraz rodzina zewnętrznego tunelu to trzy osobne decyzje. Zaplanuj każdą z nich, zanim nazwiesz to dual stack.

Brama może dać podróżującemu użytkownikowi zarówno adres wirtualny IPv4, jak i IPv6, podczas gdy zewnętrzny tunel nadal biegnie po IPv4. To niezależne decyzje, a traktowanie ich jako jednej jest właśnie tym, na czym plany dual-stack zwykle się rozpadają. Rodziny wewnętrzne klienta, chronione prefiksy, do których może dotrzeć, oraz transport niosący enkapsulację to trzy osobne wybory.

Najwięcej zamieszania bierze się z przykładania słowa dual stack do projektu, który jest dual stack tylko w jednym miejscu. Usługa może być dual stack wewnątrz, single stack na swoim adresie zewnętrznym, a mimo to działać dla klientów zupełnie dobrze. Czego nie potrafi, to działać przez przypadek.

Dwie rodziny wewnątrz, jedna ścieżka na zewnątrz

Połączenie zewnętrzne to IKE po UDP i potrzebuje jednej osiągalnej rodziny adresów z miejsca, w którym klient się znajduje. Wewnętrzny adres IPv6 nie wymaga dostawcy obsługującego IPv6, ponieważ wewnętrzny pakiet jest ładunkiem wewnątrz zewnętrznego. Wiele działających wdrożeń przenosi prefiksy IPv6 przez łącze tylko IPv4.

To, co ścieżka zewnętrzna naprawdę ogranicza, to osiągalność i przechodzenie przez NAT. Jeśli brama ogłasza tylko adres IPv4, klient w sieci tylko IPv6 nie może połączyć się w ogóle, niezależnie od tego, jakie pule skonfigurowano. Rodzinę zewnętrzną wybierz na podstawie populacji klientów, a nie wewnętrznego planu adresów.

Daj klientowi adres w każdej rodzinie

Zażądanie obu rodzin to jedna linia po stronie klienta, pod warunkiem że brama ma co przydzielać. Nazwane pule trzymają źródła osobno od sieci usług, i to właśnie ta właściwość czyni reguły zapory czytelnymi pół roku później.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Wartość vips prosi o adres z każdej rodziny, a lista puli decyduje, skąd te adresy pochodzą. Dokumentacja strongSwan dotycząca wirtualnych adresów IP omawia wiele żądań i przydział pul, w tym to, że klient proszący o konkretny adres wyraża jedynie preferencję, którą odpowiadający może pominąć. Nie buduj reguły dostępu, która zakłada, że klient zawsze otrzymuje tę samą wartość.

Wygeneruj własny unikalny prefiks lokalny zamiast kopiować przykład. Dwie organizacje, które obie fd42::/16 go wdrożą, odkryją kolizję przy pierwszym wzajemnym połączeniu, a diagnozowanie tego nie jest przyjemne.

Selektory opisują miejsca docelowe, nie źródła

Lokalne selektory ruchu podrzędnej SA mówią, jakie sieci chronione stoją za bramą, a selektory zdalne opisują, czego klient może używać jako źródła. Adres puli wirtualnej należy do strony źródłowej tej polityki; umieszczanie go na liście miejsc docelowych to częste błędne odczytanie konfiguracji.

Obie rodziny potrzebują tras powrotnych i dozwolonego przekazywania na bramie. Dodanie prefiksu do selektora bez trasy z powrotem do puli tworzy tunel, który się zestawia, przepuszcza jeden kierunek ruchu i po cichu odrzuca odpowiedź. Selektor to polityka, nie routing.

Trzymaj pule i prefiksy usług w osobnych blokach planu adresów. Gdy się pokrywają, trasa, która powinna dotrzeć do chronionego hosta, może pasować do adresu puli i zniknąć w tunelu.

DNS i ścieżka odpowiedzi decydują, czy wygląda to na skończone

Odpowiedzi resolvera są niezależne od transportu użytego do jego osiągnięcia. Nazwa może zwrócić rekord A, rekord AAAA albo oba, a klient wybiera według własnych reguł preferencji. Jeśli usługa wewnętrzna publikuje rekord AAAA, ale nic nie routuje tego prefiksu, klienci w sieciach dual-stack najpierw spróbują ścieżki IPv6 i pozostaną tam, aż zawiedzie. W konfiguracji tunelu nic wtedy nie wygląda źle.

Zdecyduj więc dla każdej nazwy, które rodziny powinny być użyteczne, a następnie sprawdź, czy odpowiedni prefiks jest w selektorze i ma trasę powrotną. To decyzja dla każdej usługi osobno. Publikowanie obu typów rekordów bez rozróżnienia to sposób, w jaki działająca usługa tylko IPv4 zaczyna przekraczać limit czasu u połowy użytkowników.

Zweryfikuj obie rodziny, zanim uznasz to za skończone

Konfiguracja, która się ładuje, to nie konfiguracja, która działa. Odczytaj stan zgłaszany przez demona, potwierdź przydziały pul, a następnie spójrz na trasy, które klient faktycznie zainstalował.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Pierwsze dwa polecenia pokazują zestawione podrzędne SA i to, w których pulach są jeszcze wolne adresy, dzięki czemu plan, który działa przy pierwszym kliencie i zawodzi przy dziesiątym, staje się widoczny. Ostatnie dwa pokazują, czy klient otrzymał globalny adres IPv6 z puli i dokąd naprawdę trafi ruch do chronionego prefiksu. Porównaj przydzielony adres z pulą, którą skonfigurowałeś, a nie z adresem, na który liczyłeś. Jeśli odpowiadający wybrał inną wartość zgodnie ze swoją polityką, trasy i reguły zapory nadal muszą się zgadzać z jego wyborem.

Następnie przetestuj jednego chronionego hosta na rodzinę i nazwę, która rozwiązuje się na obie. Test jednej rodziny nie mówi nic o tej połowie planu, której nie przećwiczono, i to tam zwykle mieszka brakująca trasa.

Powiązane artykuły