L2TP, GRE eller IPsec: kva lag skal bera økta?

To spørsmål flokar seg kvar gong L2TP, GRE og IPsec hamnar i same designnotat: kva økt ber eg, og kva lag vernar henne? Er det fyrste gale, held alt nedanfor seg internt konsistent medan det løyser det gale problemet — eit rutra overlegg bygt der brukarane trongde å ringja inn, eller ein innringingssentral som står i staden for ein nettstad-til-nettstad-gateway. Arbeidsarket nedanfor tvingar fram den skilnaden før nokon loggar inn på ei eining. Fyll det ut i rekkjefølgje, og kvar line vert noko du kan prova på eiga hand.

Start med økta, ikkje med protokollista

Ein fjernbrukar med ei PPP-økt og eit rutra overlegg mellom to gatewayar er to ulike nettverksrelasjonar, jamvel når båe til slutt vert pakka inn i IPsec. Det fyrste avsluttar ei lenkje per brukar og krev tildeling av adresser, autentisering av ein person eller eining, og ein policy som nemner kva interne nett den brukaren kan nå. Det andre sender pakkar mellom nettstader som ingen ringjer inn til.

Skriv éin setning som nemner kva av dei to du byggjer, og les henne så opp att som om du var personen som må driva henne. Treng setninga ordet «og», byggjer du båe, og arbeidsarket treng to kolonnar i staden for éin kompromisskolonne som tener kvar av dei halvt. Nemner ho ein brukar men ikkje ein adressepool, eller eit prefiks men ikkje ein videresendingspolicy, er setninga framleis ufullstendig. Formuleringa høyrest byråkratisk ut, men dette er den billegaste staden å fanga eit design som elles vert oppdaga gjennom ein billett hos brukarstøtta.

Gi kvart lag nøyaktig éi oppgåve

L2TPv2 ber PPP-økter mellom sine to endepunkt. PPP styrer lenkjesamtalen og, når han er forhandla, autentiseringa av brukaren; L2TP legg ikkje til noka kryptografi, så ein berr L2TP-demon implementerer ingen del av tryggingsrelasjonen i IPsec og høyrer berre heime i ei lenkje du allereie stolar på.

GRE er ein innkapsling mellom to adresser. Det ber pakkar på nettverkslaget over eit logisk overlegg og gjev, åleine, korkje konfidensialitet eller ein autentisert identitet til motparten. Det er ingen feil: hovudet vart forma enkelt for at det skal halda seg billeg å handsama på videresendingsmaskinvare. Fylgja er at GRE svarar på korleis ein flyttar denne pakken mellom to adresser og ikkje noko anna, og det er nettopp spørsmålet du bør stilla det.

Då står IPsec att som laget som vel trafikk, autentiserer motpartane og krypterer det det fekk beskjed om å verna. Kva trafikk det vernar er eit konfigurasjonsval som må passa til innkapslinga endepunkta faktisk lagar, fordi ein policy skriven for den ytre adressa til GRE oppfører seg annleis enn ein skriven for dei indre prefiksa. GRE-spesifikasjonen held last, GRE-hovud og ytre leveringsprotokoll synleg fråskilde, og policyen din treng same fråskilnaden.

Skriv pakkevegen før konfigurasjonen

Tak éin pakke og list opp kvart hovud som vert lagt til, i den rekkjefølgja det vert lagt til, og nemn eininga som legg det til. For ein innringsbrukar er det vanlegvis PPP inne i L2TP inne i IPsec; for eit overlegg på ein nettstad er det den indre IP-pakken inne i GRE inne i IPsec. Legg to einingar til same hovud, har du ei løkke eller ein dobbel tunnel, og ingen policyredigering rettar det.

Den same lista avgjer MTU, fordi den nyttbare indre storleiken er målt veg-MTU minus hovuda du nettopp talde opp og inkje anna. Ikkje kopier eit tal frå eit foruminnlegg: legg saman ytre IP-, UDP- og ESP-overhead, så GRE eller L2TP, så PPP der det gjeld, og trekk frå veg-MTU-en du faktisk målte. Symptom som berre kjem fram ved store overføringar, eller økter som kjem opp og så døyr på den fyrste store responsen, peikar vanlegvis attende på at den addisjonen vart gjort på slump.

Kontroller kvart lag for seg, utanfrå og inn

Køyr kontrollane i rekkjefølgje og stopp ved den fyrste som feilar. Kvar line svarar på eit anna spørsmål, så ein feil peikar på éin kolonne i arbeidsarket i staden for å seia at tunnelen er broten.

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å ein Cisco-boks er det tilsvarande rolestytt, og den nøyaktige syntaksen avheng av plattform og utgåve: show crypto session for IPsec-motpartane, grensesnittteljarar for GRE- eller tunnegrensesnittet, og VPDN- eller PPP-stadfestinga for innringsrolla. Eit kommandosett som avsluttar PPP provar inkje om GRE-støtte, og eit fungerande GRE-grensesnitt provar inkje om PPP-tenesta, så stadfest rolla du faktisk konfigurerte og ikkje den i teikninga.

Skriv kvar utskrift ved sida av den lina i arbeidsarket ho høyrer til. Notat tekne medan feilen er levande er meir verd enn ein topologi som vert teikna opp att seinare etter minnet.

Set opp rekkjefølgja for nedriving, og stadfest så på nytt

Nedriving går i omvend rekkjefølgje av ei grunn: ta den verna trafikken ut av IPsec-policyen før du fjernar innkapslinga han var skriven for, elles held policyen fram med å peika på eit grensesnitt som ikkje finst lenger, og neste konfigurasjonslasting feilar ein stad som ser irrelevant ut. På Linux tyder det å sletta tilstands- og policyoppføringane før tunnegrensesnittet; på ein ruter, å fjerna kryptokartet eller profiloppføringa før tunnelen.

Etter ombygginga, gjer dei fire godtaksobservasjonane om att ein om gongen: ytre nåbarheit, ein oppretta IPsec-assosiasjon, ei oppretta PPP-økt der designet omfattar ei, og indre videresending til ei verkeleg måladdresse. Eitt grønt lys er ikkje prov for dei tre andre, og det gapet er feilen som overlever lengst i produksjon — ein tunnel som er oppe, kryptert, og sender inkje vidare fordi den indre ruta aldri vart lagd til.

Hald det utfylte arbeidsarket ved sida av konfigurasjonen til eininga. Kvar kolonne du ikkje kan fylla ut er eit lag utan tildelt oppgåve, og eit lag utan oppgåve er vanlegvis eit lag som ikkje bør vera i stakken.