Nebula advertise_addrs czy static_host_map: wybierz według właściciela

Ustawienia static_host_map i advertise_addrs oba stawiają adres przed peerem i odpowiadają na różne pytania. Jedno to lokalny plik wymieniający adres overlay i punkt końcowy underlay, do którego należy zadzwonić. Drugie to host, który mówi swoim latarniom, jakie dodatkowe punkty końcowe mogą go osiągnąć. Właściciel jest prawdziwą różnicą: mapę utrzymują wszyscy, którzy jej potrzebują, a reklamę sam host.

Zdecyduj według tego, kto posiada informację

Każdy zmieniający się peer w statycznym pliku każdego peera to praca konserwacyjna, która rośnie z kwadratem floty. To praktyczny powód, by sięgnąć po drugie ustawienie, gdy sam host zna odpowiedź.

Pytanie o właściciela przewiduje też, co się dzieje, gdy adres się zmienia. Ze statyczną mapą ktoś musi pamiętać każdego peera, który ma stary wpis. Z reklamą host publikuje nowy punkt końcowy, a jego latarnie przekazują go dalej, więc zmiana pozostaje lokalna na maszynie, która się przeniosła.

Bootstrap nadal wymaga statycznych wpisów

Klient musi dotrzeć do co najmniej jednej latarni, zanim może kogokolwiek zapytać o inne peery. Ten pierwszy skok nie może pochodzić z wykrywania, więc pochodzi z statycznego wpisu w konfiguracji klienta. Zrób ten jeden wpis poprawnie, a reszty overlay można się nauczyć.

Wpis mapy łączy adres Nebula z jednym lub więcej osiągalnymi punktami końcowymi IP lub DNS oraz portami. Trzymanie tam latarni jest normalne; trzymanie tam każdego peera to wzorzec, który źle się starzeje, bo każdy nowy peer oznacza edycję plików na maszynach, których możesz nie kontrolować. Trzymaj listę na tyle krótką, by człowiek mógł ją jeszcze zweryfikować, czytając ją.

Reklamuj, gdy host zna punkt końcowy

Host za przekierowaniem portów jest osiągalny pod publicznym adresem, który nie jest przypisany do żadnego z jego własnych interfejsów. Nie może odkryć tego adresu, patrząc na siebie. advertise_addrs pozwala mu opublikować punkt końcowy przez swoje latarnie, aby inne peery nauczyły się ścieżki, która naprawdę działa. Ustawienie istnieje właśnie dlatego, że host jest jedyną stroną, która wie, że mapowanie zostało wykonane.

Używaj adresu i portu, do których inne peery naprawdę mogą dotrzeć. To samo rozumowanie dotyczy hosta z kilkoma ścieżkami sieciowymi, gdzie jedna ścieżka jest lepsza dla peerów w danej sieci. Reklama jest stwierdzeniem o underlay, nie prośbą o cokolwiek. Gdy mapowanie się zmienia, zaktualizuj reklamę na hoście i pozwól wykrywaniu ją nieść, zamiast edytować statyczne pliki w całej flocie.

Reklama to nie osiągalność

Opublikowanie punktu końcowego nie tworzy reguły przekierowania routera, nie otwiera firewalla wyżej w ścieżce i nie powoduje rozwiązania nazwy DNS. To osobne kawałki pracy, a poprawna reklama z brakującym przekierowaniem portu daje dokładnie tę awarię, którą próbowałeś naprawić. Reklama jest twierdzeniem o osiągalności, nie mechanizmem, który ją ustanawia.

Sprawdź ścieżkę z zewnątrz, zanim obwinisz wykrywanie. Peer, który uczy się punktu końcowego, ale nie potrafi ukończyć handshake, ma problem z routingiem lub filtrowaniem w underlay, a powtarzanie tego samego adresu w obu ustawieniach tego nie zmieni.

Trzymaj adres overlay oddzielnie od punktu końcowego

Certyfikat węzła identyfikuje jego adres Nebula. Reklamowane adresy należą do sieci bazowej i mogą się zmieniać bez dotykania certyfikatu. Wydanie nowego certyfikatu z innym adresem IP overlay to inna operacja, z własnymi konsekwencjami dla każdej relacji zaufania, która przypięła stary. Trzymaj dwie zmiany oddzielnie w runbooku, inaczej przeniesienie punktu końcowego zostanie zapisane jako ponowne wydanie.

Gdy triage utknie, rozdziel obie warstwy wyraźnie: czy wykrywanie zwraca oczekiwany punkt końcowy i czy handshake do niego dociera? Jeśli wykrywanie jest poprawne, a pakiety zawodzą, problem jest pod overlay. Jeśli wykrywanie jest błędne, problem jest w mapie lub reklamie, i tam należy poprawka.