Qui respon realment a l'adreça dedicada de la VPN?

Una adreça que queda sense usar a l'assignació de l'organització no és un oient, i afegir-la a un tallafoc no en crea cap. Alguna cosa ha de tancar l'IKE en aquesta adreça, i el mecanisme canvia segons si la passarel·la posseeix l'adreça o si un dispositiu superior la tradueix. El camí del paquet és el que distingeix els dos casos, i decideix quina funcionalitat de la plataforma necessiteu abans que ningú obri una sol·licitud de canvi. Modela el camí primer, i després tria.

El camí del paquet darrere de l'adreça

Un parell envia IKE a l'adreça que se li ha donat, per UDP 500 o per UDP 4500 quan hi ha travessa de NAT. El dispositiu que tingui aquesta adreça al camí o bé rep el datagrama localment i hi respon, o bé el reenvia a un altre lloc. Aquestes són les dues úniques possibilitats, i tota la resta d'aquest article depèn de quina és certa.

Rebre localment vol dir que en aquest dispositiu hi ha un sòcol lligat a aquesta adreça. Reenviar vol dir que el datagrama es reescriu i s'envia a un altre extrem, que aleshores té el sòcol. Una regla de tallafoc que permet UDP 500 no us diu res sobre quina de les dues coses passa.

Escriviu el registre abans de tocar res: l'adreça amb què contacten els parells, com la lliura la xarxa superior, la interfície local o l'extrem lògic que la rep, i el procés que respon a IKE. Quatre línies, i cadascuna es pot comprovar. Quan una és desconeguda, aquest desconeixement és la feina de disseny i no un detall d'implementació a resoldre després. Omplir-les després d'aprovar la sol·licitud de canvi és com una regla de traducció acaba al dispositiu equivocat.

Model A: la passarel·la posseeix l'adreça

En el primer model la passarel·la té l'adreça ella mateixa, sigui com a adreça secundària en una interfície existent, com a adreça en una interfície dedicada, o com a loopback que la plataforma admet com a extrem de túnel. Són tres funcionalitats diferents amb tres camins de configuració diferents, i una plataforma que n'admet una pot no admetre les altres.

Confirmeu que la plataforma i la versió admeten exactament aquesta disposició abans de dissenyar-hi al voltant. Un bloc enrutat, una adreça addicional en una interfície i un extrem loopback no són intercanviables, i la documentació d'una versió no promet que la següent es comporti igual.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

El sòcol en escolta és la prova. Si no hi ha res lligat a l'adreça, la passarel·la no és el terminador faci el que faci la taula d'encaminament, i una captura de paquets mostrarà els datagrames arribant sense res que els respongui.

No poseu una segona interfície en una subxarxa que ja existeix en un altre lloc de la topologia i assumeu que la plataforma ho resoldrà. Les subxarxes d'interfície superposades produeixen una selecció d'origen ambigua i, en moltes plataformes, una negativa a configurar-se.

Model B: un dispositiu superior la tradueix

En el segon model un tallafoc superior té l'adreça dedicada i reenvia el trànsit a una passarel·la VPN diferent. Això és una traducció de destinació amb camí de retorn, i és un disseny perfectament vàlid sempre que estigui documentat com a tal.

El que no és és una prova que el dispositiu superior hagi adquirit un sòcol VPN local. La traducció reenvia paquets; no converteix la caixa superior en un responent IKE. Si la regla superior se suprimeix o el seu camí de retorn es trenca, la VPN s'atura tot i que la passarel·la estigui sana i els seus propis oients intactes.

Registreu les dues adreces: la que contacten els parells i la que la passarel·la veu realment. Després registreu el transport i el camí de retorn, perquè una traducció que funciona per UDP 500 però no per a ESP encapsulat es connectarà i després no podrà portar trànsit, cosa que és una fallada confusa de depurar més endavant.

La identitat no és l'adreça exterior

IPsec separa l'extrem del túnel del trànsit que protegeix, i l'arquitectura manté aquestes decisions en llocs diferents. Canviar l'adreça amb què contacten els parells no canvia automàticament quins prefixos interiors es permeten, quines rutes s'instal·len ni a quins recursos pot arribar la sessió.

La identitat autenticada torna a ser separada. IKEv2 porta una càrrega d'identitat i un intercanvi d'autenticació que no cal que coincideixin amb l'adreça exterior del paquet, i precisament per això un disseny traduït encara pot autenticar correctament.

Aquesta independència és útil i també un parany. Dos noms DNS que resolen a un oient ordinari no seleccionen backends VPN diferents, i un certificat que anomena una identitat no satisfarà un parell que n'espera una altra. Confirmeu què valida el parell abans d'assumir que només l'adreça ho decideix.

Accepteu el disseny observant una connexió

Inspeccioneu on es lliura realment una connexió autoritzada nova, quina identitat respon i quin flux privat es permet després. Tres observacions, tres capes diferents, i una consulta pública correcta de l'adreça no en prova cap.

Mantingueu també el cas negatiu: un parell que no s'hauria d'acceptar, o un prefix interior que no hauria de ser abastable, verificats després del canvi. El registre que vau escriure al principi és el que fa possible aquesta prova sense reconstruir el disseny de memòria.

El sentit de tot això és permetre al propietari de la xarxa triar un mètode d'assignació admès en lloc de confiar en una afirmació general sobre què pot fer cada tallafoc amb una adreça extra. Aquesta afirmació és exactament on aquests dissenys fallen, perquè sona plausible a totes les plataformes i no és certa en general a cap. El registre de quatre línies ho resol per a la vostra plataforma en deu minuts.