Què cal registrar per a una VPN entre llocs: selectors i abast

Sis mesos després de posar en marxa un túnel, una subxarxa nova deixa d'encaixar amb la política i l'únic document compartit diu VPN d'oficina. Aquesta és la fallada que evita un registre de selectors, i és concreta: un conjunt d'adreces va canviar mentre el paper no. Escriure bé el registre vol dir saber quin de diversos conjunts d'adreces descriviu, i registrar el que l'altre extrem aplica realment i no el que heu configurat.

Configurat no és negociat

En un túnel IPsec basat en polítiques, cada costat proposa selectors de trànsit: rangs d'origen i de destinació per a l'associació filla. El costat que respon pot estrenyer aquesta proposta , de manera que l'associació instal·lada pot cobrir menys del que llista la configuració. Un registre que copia la configuració, doncs, descriu una intenció, no l'abast de protecció actual. Els dos divergeixen en silenci, i res a la pàgina d'estat del túnel ho assenyala.

Conserveu les dues columnes, amb la data en què les vau observar. El selector configurat és el que volíeu; el negociat és el que el nucli aplica ara mateix. Quan difereixen, aquesta diferència explica una fallada sorprenent molt més sovint que un error d'encaminament.

Una associació tampoc no representa cada parell configurat. Un túnel amb diverses combinacions de selectors pot acabar amb diverses associacions filles, i un registre que n'enumera una és un inventari parcial. Enumereu-les en lloc de resumir-les.

Els túnels basats en rutes seleccionen d'una altra manera

Amb una interfície basada en rutes, la taula d'encaminament decideix què entra al túnel i els selectors poden ser deliberadament amplis. És un disseny legítim i no pas un descurcament, i el registre ho ha de descriure així. Anoteu la ruta, la interfície a què apunta i la política de tallafocs que limita quins serveis són abastables. L'abast de protecció és ampli a propòsit, i l'abast del servei fa l'estrenyiment.

Copiar una plantilla basada en polítiques en un túnel basat en rutes produeix un document que descriu un mecanisme que el desplegament no utilitza. El següent enginyer busca llavors selectors que mai no havien de ser-hi, i conclou que el túnel està mal configurat quan només està mal documentat.

La traducció pertany a la mateixa taula

Quan el NAT presenta un rang diferent a l'altre extrem, registreu els prefixos originals i traduïts junts. Anoteu en quina etapa els selectors i les regles d'accés hi coincideixen, perquè l'ordre decideix si el costat llunyà arriba a veure l'adreça que vau anotar. Una taula amb només un dels dos rangs és pitjor que cap taula, perquè sembla completa.

Aquest és el detall que trenca un túnel que funcionava després d'un canvi de NAT: el selector encara coincideix amb el prefix original, l'altre extrem ara en rep un de traduït, i la seva ruta de retorn apunta a una adreça que ja no existeix. Res no registra cap error en el moment en què els dos deixen de coincidir.

El DNS privat pertany al mateix lloc. Un nom que resol a una adreça inutilitzable des del lloc pertinent és un error de documentació amb un tiquet de suport adjunt, i es culparà el túnel.

Adjunteu el requisit de servei

Un rang protegit no és una llista de permisos. Anoteu quins serveis han de ser abastables des de quin origen, i qui és el propietari de l'aplicació que hi ha darrere. Aquests dos camps responen a preguntes diferents, i confondre'ls és com una revisió de seguretat acaba discutint d'encaminament en lloc d'accés.

Després nomeu l'administrador de xarxa que manté la regla. Un inventari de selectors sense propietari es queda obsolet en silenci, i l'obsolet no es distingeix del dolent quan el túnel es trenca a les dues de la matinada. El propietari també és la persona que pot confirmar que un canvi va ser deliberat.

Convertiu el registre en un pla de proves

Per a cada camí necessari, trieu un amfitrió d'origen i un de destinació representatius i anoteu la ruta, el servei i la passarel·la de resposta esperats. Això converteix el document en un pla de proves en lloc d'una descripció. Llegiu l'associació viva amb l'ordre de sota, i compareu-la amb la fila negociada que vau anotar.

swanctl --list-sas

Un esquelet de cinc línies sol ser prou per mantenir el registre honest. La versió de sota cap en un tiquet de canvi sense retallar-se:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Un ping només a la passarel·la no és la prova d'acceptació. No exerceix mai el camí de trànsit, així que pot passar mentre tot flux reenviat falla. Proveu des d'un amfitrió d'un costat a un servei de l'altre i confirmeu que la resposta arriba pel túnel. Si només passa el ping, el registre acaba de trobar el problema de reenviament que havia de prevenir. documentació de reenviament de strongSwan explica com interactuen els selectors, les rutes i el reenviament en un extrem Linux.