L2TP, GRE eller IPsec: hvilket lag skal bære sessionen?

To spørgsmål filtrer sig sammen, når L2TP, GRE og IPsec ender i samme designnotat: hvilken session bærer jeg, og hvilket lag beskytter den? Tager man det første forkert, forbliver alt nedstrøms internt konsistent, mens det forkerte problem løses — et routed overlay bygget der, hvor brugerne skulle ringe ind, eller en indkaldscentral der står i stedet for en site-til-site-gateway. Arbejdsarket nedenfor tvinger den skelnen frem, før nogen logger ind på en enhed. Udfyld det i rækkefølge, og hver linje bliver noget, du kan teste for sig.

Start ved sessionen, ikke ved protokolllisten

En fjernbruger med en PPP-session og et routed overlay mellem to gateways er forskellige netværksrelationer, selv når begge ender med at være pakket ind i IPsec. Den første afslutter en forbindelse per bruger og kræver adressetildeling, autentificering af en person eller enhed samt en politik, der navngiver, hvilke interne netværk brugeren må nå. Den anden videresender pakker mellem sites, som ingen ringer ind til.

Skriv én sætning, der navngiver, hvilken af de to du bygger, og læs den derefter, som var du den person, der skal drive den. Hvis sætningen har brug for ordet 'og', bygger du begge, og arbejdsarket skal have to kolonner i stedet for én kompromiskolonne, der kun halvt tjener hver. Hvis den nævner en bruger, men ingen adressepool, eller et prefix, men ingen videresendelsespolitik, er sætningen stadig ufuldstændig. Formuleringen lyder bureaukratisk, men det er det billigste sted at fange et design, som ellers bliver opdaget via en helpdeskbillet.

Giv hvert lag præcis én opgave

L2TPv2 bærer PPP-sessioner mellem sine to endepunkter. PPP kører linkforhandlingen og, når den forhandles, brugerautentificeringen; L2TP tilføjer ingen kryptografi, så en bar L2TP-daemon implementerer intet af IPsec-sikkerhedsrelationen og hører kun til inde i et link, du allerede stoler på.

GRE er en indkapsling mellem to adresser. Det bærer pakker på netværkslaget over et logisk overlay og tilbyder i sig selv hverken fortrolighed eller en autentificeret peer-identitet. Det er ikke en defekt: headeren blev designet enkel, så den forbliver billig at behandle på videresendelseshardware. Konsekvensen er, at GRE besvarer spørgsmålet 'hvordan flytter jeg denne pakke mellem to adresser' og intet andet — netop det spørgsmål, du bør stille den.

Det efterlader IPsec som laget, der udvælger trafik, autentificerer peerne og krypterer det, den fik besked på at beskytte. Hvilken trafik den beskytter, er en konfigurationsbeslutning, der skal passe til den indkapsling, endepunkterne faktisk genererer, fordi en politik skrevet til GRE's ydre adresse opfører sig anderledes end en skrevet til de indre prefixer. GRE-specifikationen holder nyttelast, GRE-header og ydre transportprotokol synligt adskilt, og din politik har brug for samme adskillelse.

Skriv pakkestien før konfigurationen

Tag én pakke og list hver header op, der tilføjes, i den rækkefølge den tilføjes, og navngiv den enhed, der tilføjer den. For en indkaldsbruger er det normalt PPP inde i L2TP inde i IPsec; for et site-overlay den indre IP-pakke inde i GRE inde i IPsec. Hvis to enheder tilføjer samme header, har du en løkke eller en dobbelt tunnel, og ingen politikredigering retter det.

Den samme liste afgør MTU, fordi den brugbare indre størrelse er den målte path-MTU minus de headere, du netop har opregnet, og intet andet. Kopiér ikke et tal fra et forumindlæg: læg overhead for ydre IP, UDP og ESP sammen, derefter GRE eller L2TP, derefter PPP hvor det gælder, og træk det fra den path-MTU, du faktisk målte. Symptomer, der kun viser sig ved store overførsler, eller sessioner, der etableres og derefter dør på det første store svar, fører normalt tilbage til, at den addition blev gættet.

Kontrollér hvert lag for sig, udefra og ind

Kør kontrollerne i rækkefølge, og stop ved den første, der fejler. Hver linje besvarer et andet spørgsmål, så en fejl peger på én kolonne i arbejdsarket i stedet for at sige, at tunnelen er i stykker.

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-boks er ækvivalenten rollespecifik, og den præcise syntaks afhænger af platform og release: show crypto session for IPsec-peerne, interfacetællere for GRE- eller tunnelinterfacet og VPDN- eller PPP-verifikationen for indkaldsrollen. Et kommandosæt, der afslutter PPP, beviser intet om GRE-understøttelse, og et fungerende GRE-interface beviser intet om PPP-tjenesten, så verificér den rolle, du faktisk konfigurerede, i stedet for den i diagrammet.

Notér hver output ved siden af den arbejdsarkslinje, den hører til. Noter taget mens fejlen er aktiv er mere værd end en topologi, der tegnes igen bagefter fra hukommelsen.

Ordne nedtagningen, og verificér derefter igen

Nedtagningen kører i omvendt rækkefølge af en grund: fjern den beskyttede trafik fra IPsec-politikken, før du fjerner den indkapsling, den blev skrevet til, ellers peger politikken fortsat på et interface, der ikke findes længere, og den næste konfigurationsindlæsning fejler et sted, der ser urelateret ud. På Linux betyder det at slette state- og policy-posterne før tunnelinterfacet; på en router at fjerne crypto-map- eller profile-posten før tunnelen.

Efter genopbygningen gentages de fire acceptobservationer én ad gangen: ydre nåbarhed, en etableret IPsec-association, en etableret PPP-session hvor designet indeholder en, og indre videresendelse til en rigtig destinationsadresse. Et grønt lys er ikke bevis for de tre andre, og det hul er den fejl, der overlever længst i produktion — en tunnel, der er oppe, krypteret og videresender intet, fordi den indre rute aldrig blev tilføjet.

Opbevar det udfyldte arbejdsark ved siden af enhedskonfigurationen. Enhver kolonne, du ikke kan udfylde, er et lag uden tildelt opgave, og et lag uden tildelt opgave er normalt et lag, der ikke bør være i stakken.