Co właściwie powinien rejestrować rejestr adresów wyjściowych VPN?
Rejestr wyjść jest użyteczny tylko wtedy, gdy każdy wpis podaje swoje znaczenie, wydawcę i termin ważności. Klasyfikacja nie jest identyfikacją abonenta.
Rejestry wyjść brzmią jak listy, a lista nie jest trudną częścią. Trudną częścią jest zdecydowanie, co twierdzi każdy wpis, kto może go opublikować i co się dzieje, gdy twierdzenie przestaje być prawdziwe. W tych propozycjach mieszają się trzy różne role adresu, a rejestr, który je miesza, nie potrafi wiarygodnie odpowiedzieć na żadne pytanie. Prześledź jeden wpis od publikacji do wycofania, a wymagania projektowe pojawią się same.
Zacznij od rekordu, nie od listy
Pierwsze pytanie nie brzmi, ile adresów uwzględnić, ale co oznacza jeden wiersz. Czy opisuje, gdzie łączą się klienci, jakie źródło może zobaczyć cel, czy kto posiada przydział w rejestrze? To trzy twierdzenia z trzema właścicielami i trzema trybami awarii. Rejestr, który nie wskazuje, które z nich rejestruje, nie może zostać zweryfikowany, poprawiony ani wygaszony. Właściwe zrozumienie znaczenia to praca projektowa, a lista jest tylko wynikiem.
Napisz definicję wiersza, zanim napiszesz jakikolwiek schemat. Jeśli definicja potrzebuje słowa i, to prawdopodobnie dwa rekordy udające jeden.
Trzy role adresu, które wyglądają podobnie
Role łatwo pomylić, ponieważ jedno wdrożenie może używać wszystkich trzech naraz, i często tak robi. Usługa może zakończyć połączenia na jednym adresie i przekazywać ruch z innego, podczas gdy rejestr zapisuje zupełnie trzeci fakt.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
Blok hostingowy może zawierać wyjścia VPN i niepowiązane obciążenia obok siebie, więc dopasowanie w rejestrze nic nie mówi o tym, co robi dany adres w danym momencie. Wpis, który nie nazywa swojej roli, nie jest dowodem na nic konkretnego. To nazwanie roli czyni rekord podważalnym. Wskaż także rodzinę adresów, ponieważ rejestr, który po cichu obejmuje tylko IPv4, wprowadzi w błąd każdego, kto zakłada coś przeciwnego.
Prześledź jeden wpis od publikacji do wycofania
Weź jeden hipotetyczny adres wyjściowy i prześledź go. Operator publikuje prefiks i swoją rolę w podanym momencie wejścia w życie, konsumenci go pobierają, a później adres przestaje służyć jako wyjście. Każdy krok wymaga reguły: kto może publikować, co prefiks faktycznie obejmuje, kiedy wpis wchodzi w życie i jak jest wycofywany. Strumień bez ścieżki wycofania gromadzi nieaktualne twierdzenia, których nikt nie potrafi odróżnić od bieżących.
Oddziel uprawnienie do publikowania od dokładności etykiety. Rekord rejestru łączący organizację z zasobem dowodzi przydziału, a nie bieżącego wykorzystania, i to są różne twierdzenia z różnymi dowodami. Konsumenci muszą wiedzieć, któremu z tych dwóch ufają.
Zdefiniuj także korektę. Adres przydzielony ponownie klientowi lub niepowiązana usługa ujęta przez błędną etykietę wymaga udokumentowanej ścieżki do poprawki, a nie sporu w kolejce zgłoszeń. Wyzwalacz wycofania należy do tego samego dokumentu co reguła publikacji.
Co może, a czego nie może wesprzeć opublikowany strumień
Publikowane atrybuty prefiksu to utrwalony wzorzec, a istniejące przykłady opisują geografię lub własność, a nie zachowanie. Strumień VPN potrzebowałby własnej semantyki, własnych reguł dowodowych i własnego procesu przeglądu, a zmiana nazwy listy krajów nie daje żadnego z nich. Przewodnik po rejestrze ARIN pokazuje, co twierdzą, a czego nie twierdzą rekordy przydziału, i nowy strumień musi zdobyć tę samą jasność co do własnych twierdzeń. To zadanie specyfikacji, a nie zadanie ponownego etykietowania.
To, co taki strumień może wesprzeć, to decyzja klasyfikacyjna dotycząca źródła sieciowego. To, czego nie może, to zidentyfikować osoby za współdzielonym adresem, dowieść, że cały ruch z tego adresu jest tunelowany, albo zdecydować, czy konkretne żądanie jest nadużyciem. To trzy odrębne pytania z trzema odrębnymi wymogami dowodowymi.
Trzymaj kwestię prawną poza specyfikacją
Specyfikacja techniczna nie może rozstrzygnąć, czy proponowany wymóg rejestracji jest zgodny z prawem, proporcjonalny czy rozsądny. Ta ocena wymaga rzeczywistego tekstu ustawy, naruszonych praw, jurysdykcji i analizy prawnej, której format danych nie może dostarczyć. Format może być dobrze zaprojektowany i mimo to wspierać złą politykę.
To, co specyfikacja może zrobić, to uczynić debatę konkretną. Najpierw zdefiniuj proponowane dane, ich granice i tryby awarii, aby argument polityczny dotyczył realnego mechanizmu, a nie niezdefiniowanej listy, którą każdy uczestnik wyobraża sobie inaczej. To najwięcej, co dokument techniczny może wnieść do kwestii prawnej.