L2TP, GRE eller IPsec: vilket lager ska bära sessionen?

Två frågor trasslar ihop sig när L2TP, GRE och IPsec hamnar i samma designanteckning: vilken session bär jag, och vilket lager skyddar den? Blir den första fel förblir allt nedströms internt konsekvent medan fel problem löses — ett routat overlay byggt där användarna behövde ringa in, eller en inringningskoncentrator som står i stället för en site-till-site-gateway. Arbetsbladet nedan tvingar fram den åtskillnaden innan någon loggar in på en enhet. Fyll i det i ordning och varje rad blir något du kan testa för sig.

Börja vid sessionen, inte vid protokolllistan

En fjärranvändare med en PPP-session och ett routat overlay mellan två gateways är olika nätverksrelationer, även när båda till slut packas in i IPsec. Den första avslutar en länk per användare och kräver adresstilldelning, autentisering av en person eller enhet och en policy som namnger vilka interna nätverk användaren får nå. Den andra vidarebefordrar paket mellan platser som ingen ringer in till.

Skriv en mening som namnger vilken av de två du bygger och läs den sedan som om du vore personen som ska driva den. Om meningen behöver ordet 'och' bygger du båda, och arbetsbladet behöver två kolumner i stället för en kompromisskolumn som bara halvt tjänar varje. Om den nämner en användare men ingen adresspool, eller ett prefix men ingen vidarebefordringspolicy, är meningen fortfarande ofullständig. Formuleringen låter byråkratisk, men den är den billigaste platsen att fånga en design som annars upptäcks via en helpdeskbiljett.

Ge varje lager exakt en uppgift

L2TPv2 bär PPP-sessioner mellan sina två ändpunkter. PPP sköter länkförhandlingen och, när den förhandlas, användarautentiseringen; L2TP lägger inte till någon kryptografi, så en bar L2TP-demon implementerar ingen del av IPsec-säkerhetsrelationen och hör bara hemma i en länk du redan litar på.

GRE är en inkapsling mellan två adresser. Det bär paket på nätverkslagret över ett logiskt overlay och erbjuder i sig självt varken konfidentialitet eller en autentiserad peer-identitet. Det är ingen defekt: headern designades enkel så att den förblir billig att bearbeta på vidarebefordringshårdvara. Konsekvensen är att GRE besvarar frågan 'hur flyttar jag det här paketet mellan två adresser' och inget annat — precis den fråga du bör ställa till den.

Det lämnar IPsec som lagret som väljer trafik, autentiserar peerarna och krypterar det det fick i uppdrag att skydda. Vilken trafik det skyddar är ett konfigurationsbeslut som måste matcha den inkapsling ändpunkterna faktiskt genererar, eftersom en policy skriven för GRE:s yttre adress beter sig annorlunda än en skriven för de inre prefixen. GRE-specifikationen håller nyttolast, GRE-header och yttre transportprotokoll synligt åtskilda, och din policy behöver samma åtskillnad.

Skriv paketvägen före konfigurationen

Ta ett paket och lista varje header som läggs till, i den ordning den läggs till, och namnge enheten som lägger till den. För en inringningsanvändare är det oftast PPP inuti L2TP inuti IPsec; för ett site-overlay det inre IP-paketet inuti GRE inuti IPsec. Om två enheter lägger till samma header har du en loop eller en dubblerad tunnel, och ingen policyredigering fixar det.

Samma lista avgör MTU, eftersom den användbara inre storleken är den uppmätta path-MTU:n minus de headere du just räknade upp och inget annat. Kopiera inte ett tal från ett foruminlägg: summera overhead för yttre IP, UDP och ESP, sedan GRE eller L2TP, sedan PPP där det gäller, och dra av det från den path-MTU du faktiskt mätte. Symtom som bara visar sig vid stora överföringar, eller sessioner som etableras och sedan dör på det första stora svaret, leder oftast tillbaka till att den additionen gissades.

Kontrollera varje lager för sig, utifrån och in

Kör kontrollerna i ordning och stanna vid den första som misslyckas. Varje rad besvarar en annan fråga, så ett fel pekar på en kolumn i arbetsbladet i stället för att säga att tunneln är trasig.

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?

På en Cisco-box är motsvarigheten rollspecifik, och den exakta syntaxen beror på plattform och release: show crypto session för IPsec-peerarna, gränssnittsräknare för GRE- eller tunnelgränssnittet och VPDN- eller PPP-verifieringen för inringningsrollen. En kommandouppsättning som avslutar PPP bevisar inget om GRE-stöd, och ett fungerande GRE-gränssnitt bevisar inget om PPP-tjänsten, så verifiera den roll du faktiskt konfigurerade i stället för den i diagrammet.

Anteckna varje utdata bredvid arbetsbladsraden den hör till. Anteckningar som tas medan felet är aktivt är värda mer än en topologi som ritas om efteråt ur minnet.

Ordna nedmonteringen och verifiera sedan igen

Nedmonteringen körs baklänges av en anledning: ta bort den skyddade trafiken ur IPsec-policyn innan du tar bort inkapslingen den skrevs för, annars pekar policyn kvar på ett gränssnitt som inte längre finns och nästa konfigurationsladdning misslyckas någonstans som ser orelaterat ut. På Linux betyder det att ta bort state- och policy-posterna före tunnelgränssnittet; på en router att ta bort crypto-map- eller profile-posten före tunneln.

Efter återuppbyggnaden upprepas de fyra acceptansobservationerna en i taget: yttre nåbarhet, en etablerad IPsec-association, en etablerad PPP-session där designen innehåller en, och inre vidarebefordran till en verklig destinationsadress. En grön lampa är inget bevis för de andra tre, och den luckan är felet som överlever längst i produktion — en tunnel som är uppe, krypterad och vidarebefordrar ingenting eftersom den inre rutten aldrig lades till.

Förvara det ifyllda arbetsbladet bredvid enhetskonfigurationen. Varje kolumn du inte kan fylla i är ett lager utan tilldelad uppgift, och ett lager utan tilldelad uppgift är oftast ett lager som inte bör vara i stacken.