Dlaczego etykieta kraju VPN nie jest adresem, z którego wychodzisz

Wybierasz kraj, łączysz się, a strona wita cię w innym. Etykieta na liście nigdy niczego nie obiecywała w sprawie adresu, z którego wyjdziesz: to pole, które ktoś opublikował, wyprowadzone metodą, której nie widziałeś. Traktowanie tego pola jako adresu to miejsce, w którym zaczyna się zamieszanie.

Trzy osobne rzeczy niosą wartość kraju, i mogą się nie zgadzać, choć nikt nie kłamie. Rozdzielenie ich czyni niezgodność diagnozowalną, a nie tajemniczą.

Trzy różne rzeczy noszą etykietę kraju

Pierwsza to pole samego katalogu, które może być zgłoszone przez operatora, wywnioskowane z bazy adresów albo po prostu skopiowane przy tworzeniu wpisu. Druga to sam adres, który należy do sieci, jaka go ogłasza, i właśnie na to odpowiada wyszukiwanie geolokalizacyjne, korzystając z opublikowanych danych mapowania w postaci opisanej w RFC 8805. Trzecia to to, co aplikacja postanawia pokazać, a to może pochodzić z innej bazy, z ustawienia konta lub z uprawnienia udzielonego na urządzeniu. Tylko druga jest faktem sieciowym, i nawet ona jest wyszukiwaniem, a nie obserwacją.

Spójność między tymi trzema byłaby miła i nigdzie nie jest wymagana. Niezgodność jest dowodem, że wyprowadzono je różnie, niczym więcej.

Sprawdź adres, nie flagę

Przydatne pytanie brzmi: z którego publicznego adresu twój ruch faktycznie wychodzi. Można na nie odpowiedzieć z klienta i nie zależy ono od żadnego pola listy. Porównaj odpowiedź z prefiksem, którego oczekiwałeś, i z tym, co mówi o nim wyszukiwanie geolokalizacyjne, trzymając oba wyniki osobno w notatkach. Różnica między oczekiwanym krajem a wyszukiwaniem to kwestia trasowania lub bazy danych, natomiast różnica między wyszukiwaniem a opinią aplikacji to znów kwestia bazy danych.

Wykonaj sprawdzenie dwa razy, jeśli usługa ma w regionie kilka wyjść. Pula adresów może przydzielać różne adresy przy kolejnych połączeniach, a jedna próbka opisuje tylko jedno z nich.

Bliskość na mapie nie jest bliskością w sieci

Bliski kraj może być dłuższą drogą niż daleki, bo trasa światłowodowa nie podąża za granicą. Wybór węzła pod kątem opóźnienia oznacza mierzenie celu, na którym ci zależy, a nie branie najbliższej flagi. Ta sama logika dotyczy przepustowości, ponieważ lekko obciążone wyjście dwa kraje dalej może pobić zapchane sąsiednie. Najpierw mierz, potem decyduj, i zapisz godzinę, bo obie liczby się zmieniają.

Lokalizacja nie mówi też nic o przechowywaniu ani o tym, kto obsługuje punkt końcowy. To wymaga własnych dowodów, których kolumna kraju nie pomieści.

Potwierdź adres wyjścia sam

Zapytaj klienta i zewnętrzną usługę, jak wygląda twój adres, a potem zapytaj lokalną tablicę trasowania, jak wybrano tę trasę. Polecenia poniżej robią wszystkie trzy rzeczy, a trzecie jest tym, które ludzie pomijają. Zastąp nazwę interfejsu własnym urządzeniem tunelowym.

curl -sS https://api.ipify.org; echo
curl -sS --interface tun0 https://api.ipify.org; echo
ip route get 1.1.1.1
ip -6 addr show dev tun0

Pierwsze dwie linie powinny się zgadzać, a gdy się nie zgadzają, trasa, którą uważasz, że masz, nie jest trasą niosącą twój ruch. Wyszukiwanie trasy wskazuje interfejs i adres źródłowy, których jądro użyłoby dla celu, i to jest mechanizm stojący za adresem wyjścia. Linia IPv6 ma znaczenie, bo maszyna może trzymać tunel dla jednej rodziny i bezpośrednią drogę dla drugiej. Etykieta kraju sama w sobie nie obejmuje żadnego z tych przypadków.

Zapisz zaobserwowany adres, opinię bazy danych i widok aplikacji jako trzy osobne notatki. Wtedy następną napotkaną niezgodność będzie łatwo przypisać.