IPsec amb diverses subxarxes perd el trànsit de tornada? Compteu els reqid

El trànsit surt d'un lloc i no torna mai, les dues passarel·les informen d'una negociació completada, i l'únic indici és un munt de paquets de sortida sense respostes. En un extrem Linux, la causa habitual no és la força del xifratge, l'MTU ni una taula de rutes. És la granularitat de les entrades de política i el número que enllaça cada política amb una associació de seguretat. El procediment següent llegeix aquestes dues bases abans de tocar res més.

Separeu el símptoma abans de canviar res

Una fallada en un sol sentit amb una negociació IKE completada redueix el problema al camí de dades. O la política de sortida coincidia i la resposta es va descartar, o la resposta no va arribar mai perquè l'altre costat no tenia per on enviar-la. Des d'una aplicació, els dos casos es veuen igual, i les bases xfrm els distingeixen.

No comenceu per l'MTU. Una MTU incorrecta produeix bloquejos i símptomes de fragmentació, no una separació neta de direcció amb comptadors de sortida que pugen.

Llegiu la base de polítiques i la base d'estats

A Linux el xifratge el decideixen les entrades de política, així que una política coincident, no una ruta, és el que fa entrar un paquet al túnel. Executeu ip xfrm policy per veure els selectors, la direcció, la prioritat i la plantilla de cada entrada, i ip xfrm state per veure les associacions establertes amb els seus reqid. La política i l'associació s'uneixen per aquest reqid.

Mireu les tres direccions. Sortida i entrada cobreixen el trànsit cap a i des d'aquest host; la direcció d'encaminament importa quan l'host encamina per a altres. Una entrada absent o discordant en una direcció explica un resultat en un sol sentit sense cap fallada criptogràfica.

L'asimetria clàssica: un reqid per a diverses subxarxes

Una fallada habitual ve d'un parell que instal·la polítiques per a totes les subxarxes negociades sota un únic reqid, cosa que passa amb generate_policy require de racoon. El trànsit surt llavors per l'associació establerta en darrer lloc, mentre l'altre costat manté una associació separada per subxarxa. Les respostes arriben per una associació el reqid de la qual no identifica la política que les hauria d'acceptar, i el nucli les descarta després del desxifratge.

La solució és un canvi de configuració, no una regla de tallafoc: generate_policy unique; dona a cada política el seu propi reqid, de manera que les associacions per política del parell tinguin parelles corresponents. Apliqueu-ho, torneu a negociar i compteu els reqid diferents per a les subxarxes esperades abans de declarar l'èxit.

Si dues subxarxes encara comparteixen un reqid mentre l'altre costat n'espera dues, heu trobat l'asimetria. Anoteu la correspondència, perquè és la prova que el canvi següent l'ha corregida o conservada.

Els selectors vénen de la negociació, no de la vostra configuració

Els rangs protegits són el que ambdós extrems van acordar, no el que va demanar una de les parts. Un client que ofereix un parell d'hosts contra un rang remot ampli rep la versió estreta de la passarel·la, i el client no la pot eixamplar. Llegiu els selectors instal·lats en lloc dels del vostre fitxer local.

Quan l'objectiu és el contrari, mantenir una destinació fora del túnel, afegiu una política d'omissió amb un número de prioritat més baix perquè guanyi l'entrada instal·lada automàticament. Una política sense plantilla permet text clar, cosa que la converteix en una excepció deliberada per a un registre de canvis en lloc d'un pas de depuració.

Verifiqueu en aquest ordre, i sapigueu com revertir

Llisteu les polítiques de cada subxarxa en les dues direccions, inclosa l'encaminament si l'host encamina. Compteu els reqid diferents i confirmeu-ne un per política al costat que l'espera. Compareu els selectors instal·lats amb els negociats. Torneu a llegir els comptadors per associació després d'una renovació de clau, perquè l'associació inspeccionada pot haver desaparegut. Comproveu les rutes al final, ja que una ruta absent cap a la subxarxa remota produeix un símptoma similar en un sol sentit amb comptadors de política nets.

Abans de canviar el parell, deseu la sortida actual de les dues ordres xfrm. Si el nou ajustament no restaura la direcció de tornada, restaurar aquesta sortida és una reversió més ràpida que reconstruir el túnel de memòria, i manté honesta la comparació.