Encaminament per origen per a dos pools VPN: què se us escapa a la regla

Dos pools de clients, una passarel·la i el pla sembla trivial: una regla envia el primer pool per l'enllaç ràpid, una altra envia el segon pool per un túnel de soci. Després les regles estan al seu lloc i el segon pool encara surt per la ruta per defecte. La regla no està trencada. L'origen del paquet no és el que l'autor esperava en el moment de la consulta, perquè la traducció i la consulta passen en punts diferents del trajecte del mateix paquet, i l'ordre és l'oposat del diagrama mental que dibuixa la majoria.

La consulta passa abans que l'origen es reescrigui

Per a un paquet reenviat des d'un client VPN, el nucli executa una seqüència fixa. Arriba a la interfície del túnel, passa per prerouting on viuen conntrack i DNAT, després es pren la decisió d'encaminament, després el reenviament, després postrouting, on SNAT s'aplica al final. Una regla de la forma from es consulta durant aquesta decisió d'encaminament, cosa que vol dir que veu l'adreça original del client, no la traduïda.

Així, afegir una regla de masquerade no canvia quina política coincideix amb el flux sortint. El que canvia és què veu l'extrem llunyà i, per tant, quin camí de tornada existeix. Són dues conseqüències diferents, i les revisions de canvis les confonen constantment. Separeu-les i el disseny sol quedar clar en un minut.

És en la direcció de resposta on l'adreça traduïda apareix a les regles. Un paquet que torna a la passarel·la va adreçat a l'adreça traduïda, i si teniu regles de política basades en la destinació o en la interfície per la qual va arribar, aquest és el valor que fareu coincidir. La mateixa connexió, una font de veritat diferent en cada direcció.

Dos pools amb orígens diferents sí que necessiten taules diferents, i el disseny és sòlid. El que la taula anterior descarta és l'atajo de depurar mirant què ha rebut el lloc remot i deduir-ne la regla.

Una prova des de la passarel·la no és una prova del pool

El trànsit que genera la mateixa passarel·la no passa mai per prerouting, perquè no ha arribat per cap interfície. S'encamina al camí de sortida, amb l'adreça de la passarel·la com a origen, i una regla from basada en un rang de clients no coincidirà. Cada tiquet d'aquest àmbit que diu que funciona des de la caixa però no des del client és aquest mateix fet repetit.

Simuleu el client en lloc d'aproximar-lo. La consulta d'encaminament es pot preguntar directament, amb un origen i una interfície d'entrada:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Executeu-ho una vegada per pool. Si les dues ordres retornen la mateixa interfície, les regles no separen els pools, i el motiu és o una regla que falta o una regla de prioritat més alta que coincideix amb totes dues. Si retornen interfícies diferents però el client encara falla, la fallada és després de la consulta i podeu deixar de mirar les regles.

Prioritat, no posició al fitxer

Les regles s'avaluen en ordre ascendent de prioritat, i el número és el que importa, no l'ordre en què les vau escriure. La taula local és a la prioritat 0, la taula main a 32766 i la regla per defecte a 32767, per això una regla afegida amb la prioritat per defecte cau a prop del final de la llista i perd contra gairebé tot.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Una prioritat explícita fa visible l'ordre volgut al fitxer i a la revisió. També evita que una addició posterior salti en silenci per davant d'una regla existent, que és la causa més habitual que una política que funciona deixi de funcionar després d'un canvi no relacionat.

Una regla coincident que apunta a una taula incompleta és l'altre parany. Si la taula 201 conté una ruta per defecte però cap ruta a la destinació, el paquet es descarta o s'envia al lloc equivocat, i la regla sembla perfectament correcta aïllada. Llegiu la taula, no només la regla. Una regla és un punter, i una taula buida és un punter al no-res.

El camí de tornada encara ha d'existir

La política d'origen tria una sortida. No crea un camí de tornada. Si el segon pool surt per un túnel de soci, el soci ha de saber com arribar a 172.31.8.0/24, ja sigui per una ruta de retorn a la passarel·la o rebent adreces traduïdes que ja coneix.

Triar entre això és una decisió de disseny amb conseqüències visibles. Encaminar el rang de clients de tornada conserva la identitat de cada client al soci i requereix que accepti el vostre prefix. La traducció amaga el pool darrere una adreça i requereix que el soci accepti només aquesta adreça, a costa que els vostres registres i els seus ja no coincideixin sobre qui s'ha connectat.

Triï el que triï, escriviu-ho al costat de la definició del pool. Una ruta de retorn que només existeix a la memòria d'algú és exactament el tipus de cosa que sobreviu fins que el soci canvia un tallafoc, i llavors costa un dia reconstruir-la.

No atrapeu el túnel propi de la passarel·la a la política

Les regles que escriviu per als clients també s'apliquen al trànsit que genera la passarel·la, tret que l'exclogueu. Una regla àmplia basada en una marca o en la interfície de sortida pot capturar la connexió pròpia de la passarel·la amb el soci, i llavors el túnel que transporta la política és encaminat per la política. Això produeix un bucle o una caiguda que sembla una fallada del proveïdor.

Limiteu cada regla tan estretament com permeti el disseny: prefix d'origen, interfície d'entrada i, on es doni suport, una marca que només portin els paquets de clients. Després proveu la connectivitat pròpia de la passarel·la després de cada canvi de regles, perquè la fallada és autoreferent i no apareix en una prova des del client.

La pàgina de manual d'ip-rule documenta la semàntica del selector i de la prioritat. Combineu-la amb una prova de consulta per pool i el disseny esdevé comprovable, que és la diferència entre un encaminament per política que aguanta un any i un que tothom té por de tocar.