L2TP, GRE o IPsec: quina capa ha de transportar la sessió?

Dues preguntes s’entrecreuen sempre que L2TP, GRE i IPsec acaben a la mateixa nota de disseny: quina sessió estic transportant, i quina capa la protegeix? Si falla la primera, tot el que hi ha aigües avall continua coherent per dins mentre es resol el problema equivocat — una superposició encaminada construïda on els usuaris havien de marcar, o un concentrador d’accés telefònic que fa les vegades de passarel·la entre seus. El full de treball de sota obliga a fer aquesta distinció abans que ningú entri en un dispositiu. Emplena’l per ordre i cada línia es converteix en una cosa que pots provar tota sola.

Comença per la sessió, no per la llista de protocols

Un usuari remot amb una sessió PPP i una superposició encaminada entre dues passarel·les són relacions de xarxa diferents, fins i tot quan totes dues acaben embolcallades en IPsec. La primera acaba un enllaç per usuari i necessita assignació d’adreces, autenticació d’una persona o d’un dispositiu i una política que anomeni quines xarxes internes pot assolir aquest usuari. La segona encamina paquets entre llocs on ningú no marca.

Escriu una frase que anomeni quina de les dues estàs construint i torna-la a llegir com si fossis la persona que l’ha d’operar. Si la frase necessita la paraula 'i', estàs construint les dues, i el full necessita dues columnes en lloc d’una columna de compromís que serveix a mitges cadascuna. Si anomena un usuari però cap pool d’adreces, o un prefix però cap política d’encaminament, la frase encara és incompleta. La redacció sona burocràtica, però és el lloc més barat per atrapar un disseny que d’una altra manera descobriria un tiquet de suport.

Assigna a cada capa exactament una tasca

L2TPv2 transporta sessions PPP entre els seus dos extrems. PPP executa la negociació de l’enllaç i, quan es negocia, l’autenticació de l’usuari; L2TP no afegeix cap criptografia, així que un dimoni L2TP nu no implementa cap part de la relació de seguretat IPsec i només pertany dins d’un enllaç en què ja confies.

GRE és un encapsulament entre dues adreces. Transporta paquets de la capa de xarxa per una superposició lògica i, per si sol, no ofereix ni confidencialitat ni identitat de parell autenticada. No és cap defecte: la capçalera es va dissenyar simple perquè continuï sent barata de processar en maquinari d’encaminament. La conseqüència és que GRE respon a 'com moc aquest paquet entre dues adreces' i a res més, que és exactament la pregunta que li has de fer.

Això deixa IPsec com la capa que selecciona el tràfic, autentica els parells i xifra el que se li ha dit que protegeixi. Quin tràfic protegeix és una decisió de configuració que ha de coincidir amb l’encapsulament que generen realment els extrems, perquè una política escrita per a l’adreça externa de GRE es comporta diferent d’una escrita per als prefixos interns. L’especificació GRE manté visiblement separats la càrrega útil, la capçalera GRE i el protocol de lliurament extern, i la teva política necessita la mateixa separació.

Escriu el camí del paquet abans de la configuració

Agafa un paquet i enumera cada capçalera que s’afegeix, en l’ordre en què s’afegeix, anomenant el dispositiu que l’afegeix. Per a un usuari d’accés telefònic normalment és PPP dins L2TP dins IPsec; per a una superposició de llocs, el paquet IP intern dins GRE dins IPsec. Si dos dispositius afegeixen la mateixa capçalera, tens un bucle o un túnel duplicat, i cap edició de política ho arreglarà.

La mateixa llista fixa la MTU, perquè la mida interna utilitzable és la MTU de camí mesurada menys les capçaleres que acabes d’enumerar i res més. No copiïs un número d’un missatge de fòrum: suma la sobrecàrrega d’IP extern, UDP i ESP, després GRE o L2TP, després PPP on correspongui, i resta-ho de la MTU de camí que has mesurat de veritat. Els símptomes que només apareixen en transferències grans, o les sessions que s’estableixen i després moren a la primera resposta gran, solen remuntar-se a aquesta suma feta a ull.

Comprova cada capa per separat, de fora cap a dins

Executa les comprovacions per ordre i atura’t a la primera que falli. Cada línia respon una pregunta diferent, així que una fallada apunta a una columna del full en lloc de dir que el túnel està trencat.

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?

En un equip Cisco l’equivalent depèn del rol, i la sintaxi exacta varia segons la plataforma i la versió: show crypto session per als parells IPsec, comptadors d’interfície per a la interfície GRE o de túnel, i la verificació VPDN o PPP per al rol d’accés telefònic. Un conjunt d’ordres que acaba PPP no demostra res sobre el suport de GRE, i una interfície GRE que funciona no demostra res sobre el servei PPP, així que verifica el rol que has configurat de veritat en lloc del del diagrama.

Anota cada sortida al costat de la línia del full a la qual pertany. Les notes preses mentre la fallada és activa valen més que una topologia redibuixada després de memòria.

Ordena el desmuntatge i torna a verificar

El desmuntatge es fa al revés per un motiu: treu el tràfic protegit de la política IPsec abans de retirar l’encapsulament per al qual es va escriure, o la política continua apuntant a una interfície que ja no existeix i la següent càrrega de configuració falla en un punt que sembla no tenir relació. A Linux això vol dir esborrar les entrades d’estat i de política abans de la interfície de túnel; en un encaminador, treure l’entrada de crypto map o de perfil abans del túnel.

Després de la reconstrucció, repeteix les quatre observacions d’acceptació una a una: abast extern, una associació IPsec establerta, una sessió PPP establerta on el disseny n’inclogui una, i encaminament intern cap a una adreça de destinació real. Un llum verd no és prova de les altres tres, i aquest buit és la fallada que sobreviu més temps en producció — un túnel que està actiu, xifrat i no encamina res perquè la ruta interna no es va afegir mai.

Guarda el full emplenat al costat de la configuració del dispositiu. Qualsevol columna que no puguis emplenar és una capa sense tasca assignada, i una capa sense tasca assignada sol ser una capa que no hauria de ser a la pila.