Którędy tak naprawdę wychodzi ruch internetowy z waszej zarządzanej VPN

Nie można powiedzieć, kto filtruje ruch publiczny oddziału, dopóki oferta nie pokaże, gdzie ten ruch opuszcza sieć dostawcy. Dostęp do internetu dołączony do zarządzanej VPN to druga usługa, która biegnie ścieżką z własnymi bramami, własnym tłumaczeniem adresów i własną kolejką eskalacji. Większość umów szczegółowo opisuje stronę prywatną, a stronę publiczną zostawia jednemu zdaniu. Poniższe kontrole zamieniają to zdanie w diagram, którego możecie bronić.

Prześledźcie jeden cel publiczny na lokalizację

Wybierzcie host oddziału i prześledźcie jeden cel publiczny, notując ostatni adres należący do dostawcy i pierwszy należący do internetu. Skok między tymi dwoma adresami to wyjście, i często znajduje się ono daleko od lokalizacji, która wysłała pakiet. Zaznaczcie urządzenie, które wykonuje przejście, bo to ono ma filtr decydujący o tym, co wychodzi. Powtórzcie śledzenie z drugiej lokalizacji i porównajcie adresy wyjścia, bo dwa oddziały wyglądające na fakturze identycznie mogą wychodzić przez różne bramy w różnych miastach.

Zanotujcie też adres źródłowy, który cel faktycznie widzi, bo tłumaczenie może nastąpić na skoku, którego nigdy nie narysowaliście. Zapiszcie zaobserwowane odpowiedzi obok narysowanych, a różnica między nimi to miejsce, z którego nadejdzie pierwszy incydent. Inżynier dostawcy, który nie potrafi podać adresu wyjścia dla danej lokalizacji, powiedział wam już coś pożytecznego o projekcie.

Trzy układy wyjścia i co każdy koncentruje

Centralne wyjście, które prowadzicie sami, przyciąga ruch publiczny do waszej własnej bramy, co daje wam politykę filtrowania i dzienniki, ale skupia obciążenie wszystkich lokalizacji na jednym łączu. Wyjście prowadzone przez dostawcę przenosi politykę i dzienniki za granicę umowy, co upraszcza eksploatację i w tym samym ruchu odbiera wam widoczność. Wyjście w każdej lokalizacji utrzymuje ruch publiczny lokalnie i mnoży liczbę powierzchni polityki, które muszą pozostać identyczne.

Zapytajcie, który z trzech dostawca naprawdę oferuje, zanim potraktujecie listę jak menu, i zapytajcie, czy lokalizacja może przejść między nimi bez nowego łącza. Odpowiedź o migracji oddziela to, co umowne, od tego, co wyłącznie techniczne. Zanotujcie też, kto posiada tłumaczenie adresów źródłowych, bo to decyduje, co partner musi wpisać na listę dozwolonych. Współdzielone bramy oznaczają też współdzieloną przepustowość i czasem współdzieloną reputację, co zmienia sposób, w jaki partnerzy traktują wasze adresy. Przepustowość zasługuje na własne pytanie, bo współdzielona brama obsługuje w tej samej chwili innych klientów.

Filtrowanie, tłumaczenie i szyfrowanie mają odrębnych właścicieli

Trasa ustanawia osiągalność i nic nie mówi o inspekcji, więc traktujcie oba jako różne pytania z różnymi właścicielami. Dla każdej ogłoszonej trasy domyślnej nazwijcie urządzenie, które filtruje, urządzenie, które uwierzytelnia, urządzenie, które tłumaczy, i urządzenie, które inspekcjonuje, a następnie wskażcie, kto zarządza każdym z nich. Rozdzielenie tras u dostawcy nie mówi, gdzie kończy się szyfrowanie, a usługa prywatna może zakończyć swój tunel na jednej granicy, podczas gdy wyjście publiczne kończy się na innej. Zapytajcie, czy tłumaczenie odbywa się na krawędzi dostawcy, na współdzielonej bramie czy na waszym własnym wyjściu, i czy istnieją dzienniki sesji oraz jak długo są przechowywane. Policzcie właścicieli w odpowiedziach, bo umowa, która wskazuje jedną stronę do czterech zadań, zwykle zostawia trzy z nich bez dokumentacji.

Szeroka trasa domyślna zaimportowana do kontekstu routingu prywatnego zasługuje na takie samo sprawdzenie, bo import to świadome porozumienie, a nie nieszkodliwa wygoda. Sekcja 11 RFC 4364 omawia kilka układów dostępu do internetu dla VPN BGP/MPLS i traktuje wymianę tras między kontekstem VPN a domyślnym kontekstem przekazywania dostawcy dokładnie jako takiego rodzaju porozumienie. Zapytajcie, co powstrzymuje ruch publiczny przed przypadkowym wejściem na ścieżkę prywatną, i uzyskajcie odpowiedź obok polityki tras, a nie na slajdzie.

Dwa scenariusze awarii do uzgodnienia przed podpisaniem

Wpiszcie w umowę dwa testy: utratę wyjścia internetowego i utratę jednego połączenia prywatnego. Dla każdego wypiszcie zasoby wewnętrzne, lokalne usługi internetowe i ścieżki zarządzania, które muszą nadal działać. Następnie wypiszcie ścieżkę zapasową, która musi pozostać zablokowana, bo droga wokół kontroli centralnych jest gorsza niż czysty przestój. Dajcie oba testy dostawcy i zażądajcie ich oczekiwanego wyniku na piśmie, wraz z wykrywaniem i powiadamianiem.

Wykonajcie te same próby z lokalizacji pilotażowej i porównajcie je z tą pisemną odpowiedzią. Tam, gdzie oba się nie zgadzają, umowa opisuje inną sieć niż ta, którą kupiliście. Dwie komendy pokrywają typowe przypadki: jedna pokazuje ścieżkę, którą obiera cel publiczny, druga adres, który ten cel widzi.

traceroute -n 203.0.113.10
curl -s https://example.net/ip

Wiążcie zobowiązania dotyczące dostępności ze zmierzonym segmentem, a nie z nazwą usługi. Lokalne łącze, szkielet dostawcy i współdzielona brama niosą odrębne zobowiązania i odrębne zespoły eskalacji. Litery L2VPN, L3VPN i MPLS opisują mechanizm przekazywania, a nie gwarancję od końca do końca.

Dowody biją przymiotniki z oferty

Słowa takie jak nadmiarowy, bezpieczny i odporny opisują zamiar, a nie projekt. Zamiast tego poproście o listę urządzeń, lokalizacje wyjścia, schemat tłumaczenia i ścieżkę powiadamiania. Dostawca, który potrafi przedstawić te cztery elementy, ma projekt; ten, który nie potrafi, ma slajd. Trzymajcie odpowiedzi w dokumentacji usługi, a nie w wątku e-mail, i przeglądajcie je przy każdej zmianie umowy.

Układy wyjścia zmieniają się po cichu, gdy dostawcy konsolidują bramy, więc diagram sprzed trzech lat jest obciążeniem. Gdy partner zgłasza nieznany adres źródłowy, powinniście w ciągu kilku minut powiedzieć, czy pochodzi z waszego projektu, czy ze zmiany, której nikt nie ogłosił. To właśnie ta umiejętność, a nie przymiotniki, przetrwa pierwszą awarię.