Dwa pytania splatają się, gdy L2TP, GRE i IPsec trafiają do tej samej notatki projektowej: którą sesję przenoszę i która warstwa ją chroni? Błąd w pierwszym sprawia, że wszystko poniżej pozostaje wewnętrznie spójne, a rozwiązywany jest niewłaściwy problem — nakładka trasowana zbudowana tam, gdzie użytkownicy mieli się wdzierać, albo koncentrator dostępowy zastępujący bramę między oddziałami. Arkusz poniżej wymusza to rozróżnienie, zanim ktokolwiek zaloguje się na urządzenie. Wypełnij go po kolei, a każdy wiersz stanie się czymś, co można przetestować osobno.

Zacznij od sesji, nie od listy protokołów

Zdalny użytkownik z sesją PPP i trasowana nakładka między dwiema bramami to różne relacje sieciowe, nawet gdy obie kończą owinięte w IPsec. Pierwsza kończy łącze na użytkownika i wymaga przydziału adresów, uwierzytelnienia osoby lub urządzenia oraz polityki wskazującej, do których sieci wewnętrznych ten użytkownik może dotrzeć. Druga przekazuje pakiety między oddziałami, do których nikt się nie wdziera.

Napisz jedno zdanie, które nazywa, którą z dwóch budujesz, a potem przeczytaj je tak, jakbyś był osobą, która ma je obsługiwać. Jeśli zdanie potrzebuje słowa 'i', budujesz oba, a arkusz potrzebuje dwóch kolumn zamiast jednej kolumny kompromisu, która każdemu służy połowicznie. Jeśli wymienia użytkownika, ale nie pulę adresów, albo prefiks, ale nie politykę przekazywania, zdanie wciąż jest niepełne. Sformułowanie brzmi biurokratycznie, ale to najtańsze miejsce, by złapać projekt, który inaczej odkryje zgłoszenie do pomocy technicznej.

Przypisz każdej warstwie dokładnie jedno zadanie

L2TPv2 przenosi sesje PPP między swoimi dwoma punktami końcowymi. PPP prowadzi negocjację łącza i, gdy jest negocjowana, uwierzytelnianie użytkownika; L2TP nie dodaje żadnej kryptografii, więc czysty demon L2TP nie implementuje żadnej części relacji bezpieczeństwa IPsec i należy tylko do łącza, któremu już ufasz.

GRE to enkapsulacja między dwoma adresami. Przenosi pakiety warstwy sieciowej przez logiczną nakładkę i sam z siebie nie oferuje ani poufności, ani uwierzytelnionej tożsamości drugiej strony. To nie jest defekt: nagłówek zaprojektowano prosto, aby pozostał tani w przetwarzaniu na sprzęcie przekazującym. Konsekwencją jest to, że GRE odpowiada na 'jak przenieść ten pakiet między dwoma adresami' i na nic więcej — dokładnie na pytanie, które należy mu zadać.

Zostaje więc IPsec jako warstwa, która wybiera ruch, uwierzytelnia strony i szyfruje to, co kazano jej chronić. To, który ruch chroni, jest decyzją konfiguracyjną, która musi pasować do enkapsulacji faktycznie tworzonej przez punkty końcowe, ponieważ polityka napisana dla zewnętrznego adresu GRE zachowuje się inaczej niż napisana dla wewnętrznych prefiksów. Specyfikacja GRE wyraźnie rozdziela ładunek, nagłówek GRE i zewnętrzny protokół dostarczania, a twoja polityka potrzebuje tego samego rozdzielenia.

LayerIts one jobWhat it never does
PPPLink negotiation, optional user authentication, address assignmentProtect traffic between gateways
L2TPv2Carry the PPP session between two endpointsEncrypt or authenticate peers
GREEncapsulate network-layer packets between two addressesHide or authenticate the payload
IPsecAuthenticate peers and encrypt selected trafficCarry a dial-in user session by itself

Opisz ścieżkę pakietu przed konfiguracją

Weź jeden pakiet i wypisz każdy dodawany nagłówek, w kolejności dodawania, wskazując urządzenie, które go dodaje. Dla użytkownika dostępowego to zwykle PPP wewnątrz L2TP wewnątrz IPsec; dla nakładki oddziałów wewnętrzny pakiet IP wewnątrz GRE wewnątrz IPsec. Jeśli dwa urządzenia dodają ten sam nagłówek, masz pętlę albo zduplikowany tunel, i żadna zmiana polityki tego nie naprawi.

Ta sama lista rozstrzyga MTU, bo użyteczny rozmiar wewnętrzny to zmierzone MTU ścieżki minus właśnie wyliczone nagłówki i nic więcej. Nie kopiuj liczby z postu na forum: zsumuj narzut zewnętrznego IP, UDP i ESP, potem GRE lub L2TP, potem PPP, gdzie ma zastosowanie, i odejmij od MTU ścieżki, które naprawdę zmierzyłeś. Objawy pojawiające się tylko przy dużych transferach albo sesje, które się nawiązują i giną przy pierwszej dużej odpowiedzi, zwykle prowadzą do tego, że tę sumę oszacowano.

Sprawdzaj każdą warstwę osobno, od zewnątrz do środka

Wykonuj kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie. Każdy wiersz odpowiada na inne pytanie, więc awaria wskazuje kolumnę arkusza, a nie to, że tunel jest zepsuty.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Na urządzeniu Cisco odpowiednik zależy od roli, a dokładna składnia zależy od platformy i wersji: show crypto session dla stron IPsec, liczniki interfejsu dla interfejsu GRE lub tunelu i weryfikacja VPDN lub PPP dla roli dostępowej. Zestaw poleceń kończący PPP nic nie dowodzi o obsłudze GRE, a działający interfejs GRE nic nie dowodzi o usłudze PPP, więc weryfikuj rolę, którą naprawdę skonfigurowałeś, a nie tę z diagramu.

Zapisuj każde wyjście obok wiersza arkusza, do którego należy. Notatki zrobione, gdy awaria jest aktywna, są warte więcej niż topologia przerysowana potem z pamięci.

Uporządkuj demontaż, potem zweryfikuj ponownie

Demontaż przebiega w odwrotnej kolejności nie bez powodu: usuń chroniony ruch z polityki IPsec, zanim usuniesz enkapsulację, dla której ją napisano, inaczej polityka nadal wskazuje interfejs, który już nie istnieje, a następne wczytanie konfiguracji zawodzi w miejscu, które wygląda na niezwiązane. W Linuksie oznacza to usunięcie wpisów stanu i polityki przed interfejsem tunelu; na routerze usunięcie wpisu crypto map lub profilu przed tunelem.

Po odbudowie powtórz cztery obserwacje odbiorcze po jednej: osiągalność zewnętrzna, nawiązane skojarzenie IPsec, nawiązana sesja PPP tam, gdzie projekt ją przewiduje, oraz wewnętrzne przekazywanie do rzeczywistego adresu docelowego. Jedno zielone światło nie jest dowodem dla pozostałych trzech, a ta luka to awaria, która najdłużej przeżywa w produkcji — tunel, który jest podniesiony, zaszyfrowany i niczego nie przekazuje, bo nigdy nie dodano trasy wewnętrznej.

Trzymaj wypełniony arkusz obok konfiguracji urządzenia. Każda kolumna, której nie możesz wypełnić, to warstwa bez przypisanego zadania, a warstwa bez przypisanego zadania to zwykle warstwa, której nie powinno być w stosie.

Powiązane artykuły