Tres adreces s’emboliquen a cada pla d’IoT sobre VPN, i no són el mateix tipus de decisió. Una és com un operador remot troba el punt final del túnel, una és com el lloc demostra que és el lloc, i una és on el servei del sensor realment escolta. Responeu-les en aquest ordre i el disseny gairebé surt sol. Responeu-les com una sola pregunta i acabareu assignant adreces públiques a dispositius que mai no n’havien necessitat cap. Un sensor darrere d’un túnel de lloc sortint és accessible per a un operador autoritzat sense cap regla d’entrada que apunti al sensor.

Comenceu per qui inicia

Qui marca determina gairebé tot el que ve després. Quan el lloc marca cap a un concentrador, el lloc no necessita cap accessibilitat d’entrada, i el concentrador necessita un nom o una adreça que el lloc pugui resoldre. Aquesta única tria elimina bona part del debat sobre adreçament públic estàtic abans que comenci.

Les tres funcions se separen aleshores netament, i la taula de sota és la forma més curta de la decisió.

DecisionWhat you are actually choosingUsual default
Hub endpointHow the tunnel service is publishedA DNS name, no inbound rule toward the site
Site peerHow the site proves its identity and which prefixes it carriesOne key pair or certificate per site, prefix in the tunnel config
Sensor serviceHow the application is addressed inside the siteA stable private address from the site plan

Cada fila té un propietari diferent, i aquest és el punt real. El concentrador pertany a qui gestiona el servei de VPN, el parell del lloc a l’equip de xarxa, i l’adreça del sensor a qui posseeix el dispositiu.

L’adreça del concentrador és d’arrencada, no una destinació

Un nom que es resol a una adreça pública mantinguda és prou per al concentrador. Un registre DNS pot seguir el punt final quan es mou, sense editar a mà cada configuració de lloc. El que el DNS no fa és crear accessibilitat ni refrescar un client que emmagatzema la resposta antiga, i aquests són problemes separats amb solucions separades.

Si executeu túnels de lloc a lloc sense concentrador, la mateixa lògica val en una altra forma: un costat necessita un punt final abastable, o tots dos costats marquen un tercer. Algú ha de posseir encara aquella adreça i les seves renovacions.

El parell del lloc és una identitat amb un prefix adjunt

El parell és primer una identitat i després un prefix. En termes de WireGuard, el parell té un parell de claus i l’entrada AllowedIPs del concentrador lliga aquesta clau al prefix del lloc. En termes d’IKEv2, un certificat o una clau prèviament compartida identifica el lloc i els seus selectors de trànsit diuen què pot portar. Canviar només una meitat trenca l’arranjament, i per això un canvi d’adreça no s’ha de tractar mai com un canvi d’identitat.

Mantingueu la propietat de la clau o del certificat al lloc i no a l’operador del concentrador, perquè un canvi de proveïdor no esdevingui un canvi d’identitat.

El prefix és la part que la gent oblida planificar. El concentrador ha d’associar la subxarxa del sensor amb el parell correcte, i el client de l’operador necessita una ruta per a ella; una ruta que només existeix al client envia trànsit a un túnel que el descarta en silenci. Escriviu el prefix al registre del lloc al costat de l’empremta de la clau, perquè una passarel·la de substitució no pugui aparèixer amb una cobertura diferent sense que ningú ho noti.

L’adreça del sensor pertany a l’aplicació

Una adreça privada del pla del lloc és suficient, i el que necessita és estabilitat i no accessibilitat pública: una reserva DHCP, una assignació estàtica o un nom a la zona pròpia del lloc. Si el dispositiu no es pot renumerar, la traducció a la passarel·la del lloc és una resposta legítima sempre que la traducció estigui documentada i el trànsit de retorn la segueixi.

Un altre hàbit que val la pena mantenir: no enganxeu mai l’adreça pública del concentrador en un camp de següent salt a l’amfitrió del sensor. La VPN instal·la el seu propi camí, i una adjacència Ethernet ordinària amb un punt final públic és una ficció que produeix una configuració d’aparença convincent.

Les respostes són la meitat que es descuida. El dispositiu ha d’enviar la seva resposta cap al túnel, ja sigui per una ruta al client de l’operador o per la mateixa passarel·la que va traduir la petició. Un sensor amb la passarel·la per defecte equivocada accepta la petició i respon al no-res, i les notes d’reenviament expliquen per què l’arribada i l’encaminament de la resposta són dos requisits i no un.

Decidiu, i després escriviu la frontera

Escriviu la frontera d’accés abans que ningú es connecti. Restringiu la passarel·la al segment d’IoT i als serveis concrets que l’operador necessita, perquè una ruta que funciona tendeix a convertir-se en accés general per accident. Mantingueu el monitoratge de només lectura i l’autoritat de configuració com a rols separats amb identitats separades, i anomeneu la persona que retira l’accés quan acaba el contracte.

L’aprovació pertany al propietari de la xarxa, i ser en una DMZ no és una política d’accés.

La prova després del desplegament és avorrida i concloent: una petició dins del prefix permès que té èxit, un comptador que s’incrementa a la passarel·la i un intent deliberat fora del prefix que falla.

Articles relacionats