L2TP, GRE aŭ IPsec: kiu tavolo portu la seancon?

Ĉiufoje kiam L2TP, GRE kaj IPsec aperas en la sama dezajna noto, du demandoj interplektiĝas: kiun seancon mi portas, kaj kiu tavolo protektas ĝin? Eraru pri la unua kaj ĉio malsupra restos interne kohera dum ĝi solvas la malĝustan problemon — enkursigita tavolaĵo konstruita tie, kie uzantoj devis enkonduki sin, aŭ enkonduka koncentrilo anstataŭanta ej-al-eja kluzo. La suba laborfolio devigas tiun distingon antaŭ ol iu ajn ensalutos aparaton. Plenigu ĝin laŭorde kaj ĉiu linio fariĝos io, kion vi povas testi memstare.

Komencu de la seanco, ne de la protokollisto

Forka uzanto tenanta PPP-seancon kaj enkursigita tavolaĵo inter du kluzoj estas malsamaj retaj rilatoj, eĉ kiam ambaŭ finfine estas volvitaj en IPsec. La unua finigas ligilon por unu uzanto kaj bezonas adresan asignadon, aŭtentikigon de persono aŭ aparato, kaj politikon nomantan, kiujn internajn retojn tiu uzanto rajtas atingi. La dua plusendas pakojn inter ejoj, en kiujn neniu enkondukas sin.

Skribu unu frazon, kiu nomas, kiun el la du vi konstruas, poste relegu ĝin kvazaŭ vi estus la persono, kiu devas ĝin funkciigi. Se la frazo bezonas la vorton «kaj», vi konstruas ambaŭ, kaj la laborfolio bezonas du kolumnojn anstataŭ unu kompromisa kolumno, kiu duone servas ĉiun. Se ĝi nomas uzanton sed ne adresaron, aŭ prefikson sed ne plusendan politikon, la frazo ankoraŭ estas nekompleta. La vortigo sonas burokrata, sed ĝi estas la plej malmultekosta loko por kapti dezajnon, kiun alie malkovrus subtena bileto.

Donu al ĉiu tavolo ekzakte unu taskon

L2TPv2 portas PPP-seancojn inter siaj du finpunktoj. PPP gvidas la ligilan intertraktadon kaj, kiam ĝi okazas, la uzantan aŭtentikigon; L2TP aldonas neniun kriptografion, do nuda L2TP-demono realigas neniun parton de la IPsec-sekureca rilato kaj apartenas nur ene de ligilo, kiun vi jam fidas.

GRE estas enkapsuligo inter du adresoj. Ĝi portas pakojn de la reta tavolo tra logika tavolaĵo kaj, memstare, ofertas nek konfidencon nek aŭtentikigitan identecon de la partnero. Tio ne estas difekto: la kaplinio estis dezajnita simpla por ke ĝia prilaboro restu malmultekosta sur plusenda aparataro. La sekvo estas, ke GRE respondas al «kiel mi movu ĉi tiun pakon inter du adresoj» kaj al nenio alia, kaj ĝuste tion vi devus demandi al ĝi.

Tio lasas IPsec kiel la tavolon, kiu elektas trafikon, aŭtentikigas la partnerojn kaj ĉifras tion, kion oni ordonis protekti. Kiun trafikon ĝi protektas estas agorda decido, kiu devas kongrui kun la enkapsuligo, kiun la finpunktoj efektive generas, ĉar politiko skribita por la ekstera adreso de GRE kondutas alimaniere ol unu skribita por la internaj prefiksoj. La specifo de GRE tenas utilecon, GRE-kaplinianon kaj eksteran transdonan protokolon videble apartaj, kaj via politiko bezonas la saman apartigon.

Skribu la pakan vojon antaŭ la agordo

Prenu unu pakon kaj listigu ĉiun kaplinianon aldonatan, laŭ la ordo de aldono, nomante la aparaton, kiu aldonas ĝin. Por enkonduka uzanto tio kutime estas PPP ene de L2TP ene de IPsec; por eja tavolaĵo ĝi estas la interna IP-pako ene de GRE ene de IPsec. Se du aparatoj aldonas la saman kaplinianon, vi havas buklon aŭ duobligitan tunelon, kaj neniom da politika redaktado riparos ĝin.

La sama listo solvas ankaŭ MTU, ĉar la uzebla interna grando estas la mezurita voja MTU minus la kapliniaĵoj, kiujn vi ĵus listigis, kaj nenio alia. Ne kopiu nombron el forumafiŝo: sumu la eksterajn superkostojn de IP, UDP kaj ESP, poste GRE aŭ L2TP, poste PPP kie ĝi aplikiĝas, kaj subtrahu de la voja MTU, kiun vi efektive mezuris. Simptomoj aperantaj nur ĉe grandaj transigoj, aŭ seancoj, kiuj establiĝas kaj poste mortas ĉe la unua granda respondo, kutime devenas de tio, ke tiu sumado estis farita per konjektado.

Kontrolu ĉiun tavolon aparte, de ekstere enen

Rulu la kontrolojn laŭorde kaj haltu ĉe la unua, kiu malsukcesas. Ĉiu linio respondas al malsama demando, do malsukceso montras al unu kolumno de la laborfolio anstataŭ diri al vi, ke la tunelo rompiĝis.

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?

Sur Cisco-aparato la ekvivalento dependas de la rolo, kaj la ekzakta sintakso dependas de la platformo kaj eldono: show crypto session por la IPsec-partneroj, interfacaj nombriloj por la GRE aŭ tunela interfaco, kaj la VPDN aŭ PPP-kontrolo por la enkonduka rolo. Komandaro, kiu finigas PPP, pruvas nenion pri GRE-subteno, kaj funkcianta GRE-interfaco pruvas nenion pri la PPP-servo, do kontrolu la rolon, kiun vi efektive agordis, anstataŭ tiun en la diagramo.

Notu ĉiun eligon apud la laborfolia linio, al kiu ĝi apartenas. Notoj prenitaj dum la difekto ankoraŭ vivas valoras pli ol topologio poste redesegnita el memoro.

Ordigi la malkonstruon, poste rekontroli

La malkonstruo iras inverse pro kialo: elprenu la protektitan trafikon el la IPsec-politiko antaŭ ol forigi la enkapsuligon, por kiu ĝi estis skribita, alie la politiko daŭre montras al interfaco, kiu ne plu ekzistas, kaj la sekva agorda ŝargo malsukcesas ie, kio ŝajnas senrilata. En Linux tio signifas forigi la statajn kaj politikajn rikordojn antaŭ la tunela interfaco; en enkursigilo, forigi la crypto map aŭ profilan rikordon antaŭ la tunelo.

Post la rekonstruo, ripetu la kvar akceptajn observojn unuope: ekstera atingeblo, establita IPsec-asocio, establita PPP-seanco kie la dezajno inkluzivas unu, kaj interna plusendo al reala celadreso. Unu verda lumo ne estas pruvo por la aliaj tri, kaj ĝuste tiu breĉo estas la difekto, kiu plej longe postvivas en produktado — tunelo, kiu estas supren, ĉifrita, kaj plusendas nenion ĉar la interna vojo neniam estis aldonita.

Tenu la plenigitan laborfolion apud la aparata agordo. Ĉiu kolumno, kiun vi ne povas plenigi, estas tavolo sen asignita tasko, kaj tavolo sen asignita tasko kutime estas tavolo, kiu ne devus esti en la stako.