Wybierz przestrzeń adresową VPN według przydziału, nie według niejasności
Zakresy referencyjne, współdzielone i dokumentacyjne mają każdego właściciela i cel. Wybierz przestrzeń VPN z rejestru, a następnie zaplanuj nakładanie się, którego nie można usunąć.
Niezwykle wyglądający prefiks wydaje się ucieczką od konfliktu adresów domowych i biurowych, i zwykle nią nie jest. Każdy blok w rejestrze IPv4 specjalnego przeznaczenia ma właściciela, cel i powód istnienia, a pożyczenie jednego, bo wygląda spokojnie, przenosi kolizję zamiast ją usuwać. Wykonaj to jako sekwencję: przeczytaj przydział, zinwentaryzuj to, co już się nakłada, i dopiero wtedy zdecyduj, czy przenumerowujesz, tłumaczysz czy tworzysz nową przestrzeń. Kolejność ma znaczenie, bo trzeci krok zależy od tego, co znalazły dwa pierwsze.
Przeczytaj przydział, zanim pożyczysz zakres
Rejestr specjalnego przeznaczenia IANA oddziela zakresy będące wielokrotnego użytku przestrzenią prywatną od zakresów służących jednemu konkretnemu celowi technicznemu. Użycie prywatne, współdzielona przestrzeń adresowa, benchmark i bloki dokumentacyjne wyglądają w arkuszu tak samo, a po trasowaniu zachowują się zupełnie inaczej.
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
Dwa prefiksy różniące się tylko drugim oktetem nie są tym samym blokiem: 198.18.0.0/15 niesie rezerwację benchmarkową, podczas gdy 192.18.0.0/16 nie niesie niczego takiego. Liczba, która tylko przypomina zakres zastrzeżony, nie dziedziczy jego znaczenia. To pomieszanie jest dość powszechne, by zasługiwać na drugie spojrzenie, zanim trafi do reguły zapory.
Produkty czasami celowo używają specjalnego zakresu w ramach skoordynowanej nakładki, i to jest ich projekt, który należy udokumentować. Nie czyni to tego samego zakresu wolnym miejscem dla niepowiązanej sieci LAN. Przestrzeń publiczna też nie jest kryjówką: prywatna trasa do adresu należącego do kogoś innego kieruje ruch przeznaczony dla jego legalnego celu gdzie indziej.
Zinwentaryzuj nakładanie się, które już masz
Przed wyborem prefiksu wypisz każdą sieć, która będzie osiągalna z tunelu. Witryny, pule klientów, VPC w chmurze i łącza partnerskie liczą się wszystkie, a łącze partnerskie jest tym, o którym ludzie zapominają, dopóki pierwsza próba połączenia nie zawiedzie.
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
Umieść wyniki w jednej tabeli z właścicielem każdego zakresu obok. Zakres, dla którego nie potrafisz wskazać właściciela, to zakres, którego nie przenumerujesz później, i to właśnie inwentaryzacja zamienia spór o „nietypowe” prefiksy w decyzję o konkretnych numerach. Mówi też, czy konflikt, którego próbujesz uniknąć, jest rzeczywisty czy wyobrażony.
Jeśli sieć domowa pracownika zdalnego używa tego samego prefiksu co sieć LAN biura, ten konflikt jest widoczny w inwentaryzacji i można go rozwiązać wprost. To nie dowód, że blok benchmarkowy byłby sprytnym wyborem, i właśnie takie podejście tworzy następną kolizję.
Wygeneruj unikalny ULA zamiast kopiować prefiks
IPv6 rozwiązuje problem ponownego użycia innym mechanizmem, a nie ładniejszym numerem. RFC 4193 definiuje lokalnie przypisane unikalne adresy lokalne z pseudolosowym 40-bit globalnym identyfikatorem, co daje witrynie /48, które bardzo mało prawdopodobnie zderzy się z czyimś innym. Prawdopodobieństwo jest wysokie, nie absolutne, a prefiks ULA nadal nie zapewnia osiągalności internetu.
openssl rand -hex 5
Dziesięć cyfr szesnastkowych to czterdzieści bitów. Postaw przed nimi fd i pogrupuj je w /48: wynik 3f9c1a7b02 staje się fd3f:9c1a:7b02::/48. Wygeneruj jeden na witrynę i zapisz go, zamiast wklejać ten sam wygodny fd00::/48 do każdego wdrożenia.
Następnie potwierdź, że cała ścieżka naprawdę mówi IPv6. Klienci, brama, trasy, prywatny DNS i polityka usług muszą się zgadzać, a przypisanie prefiksu do tunelu nie sprawia, że aplikacja działająca tylko z IPv4 go użyje.
Zaplanuj nakładanie się, którego nie możesz usunąć
Niektóre nakładania się są trwałe, zwykle dlatego, że partner nie przenumeruje, a ty nie możesz go zmusić. Wtedy świadomie wybierasz obsługiwany mechanizm: przenumerowanie po swojej stronie, odizolowany kontekst trasowania lub jawną translację na granicy. Świadomy wybór oznacza zapisanie, który wybrano i dlaczego odrzucono pozostałe dwa. Ta notatka jest tym, co przyszły przegląd zmian naprawdę przeczyta.
Translacja musi zachować ścieżkę powrotną, co oznacza zapisanie zarówno prefiksu oryginalnego, jak i prezentowanego oraz dopasowanie ich do prywatnych nazw DNS, które się w nie rozwiązują. Zmapowany alias może uczynić jedno połączenie jednoznacznym; nie czyni oryginalnych adresów globalnie unikalnymi i nie przetrwa drugiego nakładającego się partnera bez drugiego mapowania.
Zapisz przydział wraz z jego wyjątkiem
Zakończ dokumentem, który wymienia każdy prefiks, jego kategorię, właściciela i powód wyboru. Dodaj wyjątki z ich regułą translacji lub przenumerowania oraz datą, w której ktoś je zatwierdził. Trzymaj go obok reguł zapory, które go wdrażają, a nie w wiki, której nikt nie otwiera podczas incydentu. Dokument jest dostawą, a nie jej streszczeniem.
To właśnie ten zapis powstrzymuje następnego inżyniera przed szukaniem dziwniej wyglądającego numeru, i tak ten problem jest odkrywany na nowo co kilka lat pod nową nazwą. Daje też przeglądowi zmian coś konkretnego do zatwierdzenia zamiast opinii o prefiksach. Zapisz go raz, na końcu przydziału, dopóki uzasadnienie jest jeszcze przed tobą.