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

To spørsmål floker seg sammen når L2TP, GRE og IPsec havner i samme designnotat: hvilken økt bærer jeg, og hvilket lag beskytter den? Tar du det første feil, forblir alt nedstrøms internt konsistent mens feil problem løses — et rutet overlegg bygget der brukerne skulle ringe inn, eller en innringingskonsentrator som står i stedet for en gateway mellom nettsteder. Regnearket nedenfor tvinger fram den forskjellen før noen logger på en enhet. Fyll det ut i rekkefølge, og hver linje blir noe du kan teste for seg.

Start ved økten, ikke ved protokollisten

En ekstern bruker med en PPP-økt og et rutet overlegg mellom to gatewayer er forskjellige nettverksrelasjoner, selv når begge til slutt pakkes inn i IPsec. Den første avslutter en lenke per bruker og krever adressetildeling, autentisering av en person eller enhet og en policy som navngir hvilke interne nettverk brukeren kan nå. Den andre videresender pakker mellom nettsteder som ingen ringer inn til.

Skriv én setning som navngir hvilken av de to du bygger, og les den deretter som om du var personen som må drifte den. Hvis setningen trenger ordet «og», bygger du begge, og regnearket trenger to kolonner i stedet for én kompromisskolonne som tjener hver av dem halvveis. Hvis den nevner en bruker men ingen adressepool, eller et prefiks men ingen videresendingspolicy, er setningen fortsatt ufullstendig. Formuleringen høres byråkratisk ut, men det er det billigste stedet å fange et design som ellers vil bli oppdaget av en helpdesk-sak.

Gi hvert lag nøyaktig én oppgave

L2TPv2 bærer PPP-økter mellom sine to endepunkter. PPP kjører lenkeforhandlingen og, når den forhandles, brukerautentiseringen; L2TP legger ikke til noen kryptografi, så en bar L2TP-daemon implementerer ingen del av IPsec-sikkerhetsrelasjonen og hører bare hjemme inne i en lenke du allerede stoler på.

GRE er en innkapsling mellom to adresser. Det bærer pakker på nettverkslaget over et logisk overlegg og tilbyr i seg selv verken konfidensialitet eller en autentisert peer-identitet. Det er ikke en mangel: headeren ble designet enkel for at den skal forbli billig å behandle på videresendingsmaskinvare. Konsekvensen er at GRE svarer på «hvordan flytter jeg denne pakken mellom to adresser» og ingenting annet — nettopp spørsmålet du bør stille det.

Det lar IPsec stå igjen som laget som velger trafikk, autentiserer peerne og krypterer det det ble bedt om å beskytte. Hvilken trafikk det beskytter er en konfigurasjonsbeslutning som må samsvare med innkapslingen endepunktene faktisk genererer, fordi en policy skrevet for GREs ytre adresse oppfører seg annerledes enn en skrevet for de indre prefiksene. GRE-spesifikasjonen holder nyttelast, GRE-header og ytre leveringsprotokoll synlig adskilt, og policyen din trenger samme adskillelse.

Skriv pakkeveien før konfigurasjonen

Ta én pakke og list opp hver header som legges til, i den rekkefølgen den legges til, og navngi enheten som legger den til. For en innringingsbruker er det vanligvis PPP inne i L2TP inne i IPsec; for et overlegg mellom nettsteder, den indre IP-pakken inne i GRE inne i IPsec. Hvis to enheter legger til samme header, har du en løkke eller en duplisert tunnel, og ingen policyredigering retter det.

Den samme listen avgjør MTU, fordi den brukbare indre størrelsen er den målte veil-MTUen minus headerne du nettopp listet opp og ingenting annet. Ikke kopier et tall fra et foruminnlegg: legg sammen overhead for ytre IP, UDP og ESP, deretter GRE eller L2TP, deretter PPP der det gjelder, og trekk fra den veil-MTUen du faktisk målte. Symptomer som bare vises ved store overføringer, eller økter som etableres og deretter dør på det første store svaret, fører vanligvis tilbake til at denne addisjonen ble gjort på gefylen.

Kontroller hvert lag for seg, utenfra og inn

Kjør kontrollene i rekkefølge og stopp ved den første som feiler. Hver linje svarer på et annet spørsmål, så en feil peker på én kolonne i regnearket i stedet for å si at tunnelen er ødelagt.

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 ekvivalenten rollespesifikk, og den nøyaktige syntaksen avhenger av plattform og utgivelse: show crypto session for IPsec-peerne, grensesnitttellere for GRE- eller tunnelgrensesnittet, og VPDN- eller PPP-verifiseringen for innringingsrollen. Et kommandosett som avslutter PPP beviser ingenting om GRE-støtte, og et fungerende GRE-grensesnitt beviser ingenting om PPP-tjenesten, så verifiser rollen du faktisk konfigurerte i stedet for den i diagrammet.

Noter hver utdata ved siden av regnearklinjen den hører til. Notater tatt mens feilen er aktiv er verdt mer enn en topologi som tegnes på nytt etterpå fra hukommelsen.

Ordne nedtakingen, og verifiser deretter på nytt

Nedtakingen går i omvendt rekkefølge av en grunn: fjern den beskyttede trafikken fra IPsec-policyen før du fjerner innkapslingen den ble skrevet for, ellers peker policyen fortsatt på et grensesnitt som ikke finnes lenger, og neste konfigurasjonsinnlasting feiler et sted som ser urelatert ut. På Linux betyr det å slette tilstands- og policypostene før tunnelgrensesnittet; på en ruter å fjerne crypto map- eller profile-posten før tunnelen.

Etter gjenoppbyggingen gjentar du de fire akseptobservasjonene én om gangen: ytre nåbarhet, en etablert IPsec-assosiasjon, en etablert PPP-økt der designet inneholder en, og indre videresending til en reell destinasjonsadresse. Ett grønt lys er ikke bevis for de tre andre, og det gapet er feilen som overlever lengst i produksjon — en tunnel som er oppe, kryptert og videresender ingenting fordi den indre ruten aldri ble lagt til.

Oppbevar det utfylte regnearket ved siden av enhetskonfigurasjonen. Enhver kolonne du ikke kan fylle ut er et lag uten tildelt oppgave, og et lag uten tildelt oppgave er vanligvis et lag som ikke bør være i stakken.