Dlaczego maszyna wirtualna Azure z urządzeniem VPN gubi drogę powrotną
Urządzenie VPN w maszynie wirtualnej Azure potrzebuje zgodności UDR, flagi przekazywania karty sieciowej i polityki gościa. Prześledź jedno żądanie oddziału przez wszystkie trzy.
Maszyna wirtualna Azure z urządzeniem VPN znajduje się w dwóch niezależnych systemach decyzyjnych. Azure decyduje, gdzie pakiet opuszcza podsieć, korzystając z tabel tras i ustawienia przekazywania karty sieciowej. System operacyjny samego urządzenia decyduje, czy przekazać odszyfrowany pakiet dalej. Tunel, który podnosi się bezbłędnie, nadal może zawieść w drugim systemie, i właśnie tam zatrzymuje się większość takich wdrożeń.
Trzej właściciele jednej drogi
Weź sieć oddziału 192.168.50.0/24 i podsieć obciążenia 10.0.10.0/24, przy czym urządzenie jest pod adresem 10.0.0.4 we własnej podsieci. Jedno żądanie dotyka trzech osobnych konfiguracji.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Każdym wierszem w większości organizacji zarządza inny zespół, dlatego ta awaria zwykle przychodzi jako trzy zgłoszenia zamiast jednego.
Trasa, która wskazuje na urządzenie
Skojarz tabelę tras z podsiecią obciążenia i nadaj prefiksowi oddziału następny skok typu Virtual appliance z 10.0.0.4 jako adresem. Użyj osiągalnego prywatnego adresu urządzenia, nigdy jego publicznego punktu wejścia VPN. Następny skok musi być adresem, do którego podsieć obciążenia już dociera. Zostaw resztę routingu obciążenia w spokoju, chyba że świadomie zdecydowałeś się zastąpić trasę domyślną.
Trzymaj urządzenie we własnej podsieci i upewnij się, że trasa wysyłająca ruch oddziału do urządzenia nie przechwytuje także własnej ścieżki wyjściowej urządzenia. Taka pętla wygląda jak zdrowy tunel bez odpowiedzi, a to bardzo nieprzyjemna rzecz do debugowania o 2 w nocy.
Flaga karty sieciowej, o której wszyscy zapominają
Azure ma ustawienie przekazywania IP dla każdej karty sieciowej i jest ono domyślnie wyłączone. Istnieje, ponieważ przekazująca karta odbiera pakiety zaadresowane do czegoś innego, a ciche ich odrzucanie jest bezpiecznym ustawieniem domyślnym dla wszystkich pozostałych.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true włącza je dla jednego interfejsu. Wskazówki Microsoftu dotyczące przekazywania na karcie sieciowej wymagają tego ustawienia na każdej podłączonej karcie, która przekazuje ruch, więc urządzenie z jedną kartą nadal musi mieć je ustawione na tej karcie.
Flaga nie jest trasą ani regułą zapory. Jej włączenie daje zgodę i nic więcej.
Co gość robi z odszyfrowanym pakietem
Gdy tunel się kończy, własny stos urządzenia podejmuje kolejną decyzję. Na gościu Linux przekazywanie IPv4 jest ustawieniem czasu wykonania, i sysctl -w net.ipv4.ip_forward=1 utrzymuje się do następnego rozruchu. Zapisz je trwale w pliku w /etc/sysctl.d/ katalogu zamiast tego. Urządzenie dostawcy ma własny odpowiednik, a instrukcje dla Linuxa wklejone na platformę dostawcy zwykle nie robią zupełnie nic.
Polityka zapory gościa jest znowu osobna, podobnie jak grupa zabezpieczeń sieciowych obciążenia. Zezwolenie na UDP 500 i 4500 do publicznego adresu maszyny chroni tunel; nic nie mówi o tym, czy odszyfrowane żądanie oddziału może dotrzeć do portu obciążenia.
Prześledź jedno żądanie i jego odpowiedź
Wybierz jeden dozwolony przepływ i prześledź go od początku do końca. Oddział potrzebuje trasy dla 10.0.10.0/24 przez połączenie lokacji, urządzenie potrzebuje ścieżki dostarczenia do podsieci obciążenia, a podsieć obciążenia potrzebuje trasy powrotnej w stronę oddziału.
Zdecyduj wcześnie, czy projekt zachowuje adres źródłowy oddziału, czy go tłumaczy. NAT zmienia to, co widzi obciążenie, więc jego reguły dostępu powinny opisywać model, który naprawdę wybrałeś, a nie zgadywany adres bramy.
Udany uścisk dłoni dowodzi jednego ogniwa tego łańcucha. Droga jest kompletna, gdy odpowiedź wraca przez to samo urządzenie i pozwala na to własna polityka obciążenia.