Comença al camp del conjunt al servidor VPN, no en un full de càlcul. El que hi escriviu es converteix en l'espai d'adreces intern per a cada client que es connecti després, i ha de conviure amb la LAN a què arriben aquests clients, els llocs encaminats darrere seu i qualsevol adreça que el client ja tingui a casa. Connecteu un client tan bon punt es desa el conjunt, perquè aquesta primera connexió us diu si el valor funciona a la pràctica. Des d'allà el recorregut s'estén cap enfora: l'adreça que el client ha rebut, el camí que segueix una resposta i el registre que deixeu enrere.

Comenceu al camp del conjunt, abans que es connecti cap client

Cada producte ho exposa de manera diferent, així que trobeu l'objecte que realment assigna adreces. OpenVPN té una directiva de conjunt al costat del servidor que reparteix la propera adreça lliure, una passarel·la IKEv2 té una secció de conjunt lligada a la configuració del par, i WireGuard no en té cap perquè cada par porta la seva pròpia adreça al seu fitxer de configuració. Una directiva de conjunt i una adreça per par no són intercanviables, i editar la incorrecta malgasta la resta del recorregut.

Un cop tingueu el camp, llisteu els rangs que ja existeixen: la LAN de l'oficina, cada lloc encaminat, la VPC del núvol i qualsevol altre conjunt encara en servei. El solapament es decideix per aritmètica de prefix, no per si els números d'amfitrió semblen familiars, així que compareu l'agregat amb cadascun d'aquests rangs. Dos rangs que tots dos semblen 10.x són inofensius quan els seus agregats no es tallen i un incident de suport quan es tallen.

Després decidiu si l'adreça és funció de qui es connecta o de quan es connecta. L'assignació dinàmica reparteix el que és lliure, mentre que l'assignació per identitat lliga una adreça fixa a una credencial. Escriviu l'elecció, perquè canvia com ha de ser una reconnexió més endavant.

Llegiu l'adreça que el client ha rebut realment

Connecteu un client i llegiu què informa el túnel, no què havia promès el conjunt. El client mostra la seva adreça interna a l'estat de la connexió, i a Linux la interfície la porta directament.

Compareu aquesta adreça amb el rang que heu desat. Si és fora del rang, esteu veient un camí d'assignació diferent del que heu editat. Comproveu també la longitud del prefix, ja que un client amb un /32 no té cap par enllaçat i envia cada destinació per la seva ruta per defecte.

ip -4 addr show tun0
ip route get 192.168.50.20

Un client que es connecta des d'un router de casa que fa servir el mateix rang es connectarà i després no arribarà gairebé enlloc. El client conserva la seva ruta local per a aquest prefix, així que l'adreça del túnel xoca amb la xarxa del darrere i el trànsit surt per la interfície incorrecta. Aquest cas no es pot reparar al servidor; el remei documentat és renumerar la xarxa de casa o triar un rang de conjunt prou remot perquè les col·lisions segueixin sent rares. Anoteu tant la fallada com el remei, perquè el servei d'ajuda el tornarà a trobar.

Reconnecteu el mateix client i observeu l'adreça. Un conjunt dinàmic pot retornar el mateix valor o un de diferent i tots dos són correctes, mentre que un conjunt per identitat que canvia l'adreça no compleix el lligam. Aquesta comprovació triga segons i resol si el mode que vau anotar a la primera secció és el mode vigent.

Seguiu una resposta de tornada des del servei

El conjunt només funciona quan les respostes poden viatjar de tornada cap a ell. Un servei a la LAN respon a l'adreça interna, així que la seva passarel·la necessita una ruta per al conjunt o una traducció davant del servei. Quan una petició arriba pel túnel i la resposta surt per un camí diferent, un tallafoc amb estat o una comprovació de ruta inversa la descarta, i el client veu un servei que es connecta i després es penja. Poseu el conjunt al disseny d'encaminament com un sol bloc resumible en lloc d'afegir rutes per amfitrió.

La traducció canvia el que veu la resta del sistema. Quan es reescriu l'origen, l'adreça al tallafoc de l'amfitrió i al registre de l'aplicació és la traduïda, així que una regla escrita contra l'adreça del conjunt no encaixa amb res i una línia de registre no es pot resseguir fins a un client. La documentació de reenviament de strongSwan cobreix la meitat del costat del servidor d'aquest camí per a una passarel·la IKEv2. El DNS porta la mateixa restricció, perquè un nom que es resol a una adreça que el client no pot assolir falla més tard i en un altre lloc.

Dos clients, després una revocació

Connecteu dos clients alhora i llegiu totes dues adreces. Han de ser diferents, utilitzables i dins del conjunt, i cadascuna ha d'arribar al servei al qual està destinada. Un conjunt que reparteix adreces duplicades normalment es mostra aquí i no a la primera prova amb un sol client.

Revogueu una credencial mentre l'altre client continua connectat, després proveu el servei des del client supervivent. Una revocació que pertorba l'altra sessió apunta a estat compartit, molt sovint una credencial o una adreça reutilitzada entre dispositius. Reconnecteu el client revocat i confirmeu que se li denega en lloc de lliurar-li l'adreça alliberada.

Acabeu amb una destinació que s'hauria de denegar. Un client que arriba a tot ha estat connectat, no provat.

Escriviu els quatre valors on els trobarà el proper canvi

El registre és curt: el rang i el prefix del conjunt, el mode d'assignació, el camí de tornada o la traducció en ús i l'abast de DNS que respon per a aquestes destinacions. Poseu-lo al costat de la configuració del servidor en lloc d'un tiquet, i dateu-lo. Qui canviï un dels quatre més endavant necessita els altres tres al davant, perquè un canvi de mida del conjunt trenca la ruta i un canvi de ruta trenca la resposta DNS.

Guardeu-hi la nota de propietat: el rang del túnel pertany al servidor VPN, i una reserva feta a l'abast DHCP de la LAN no reserva res per a un client dins del túnel. Aquesta sola línia evita la reelaboració més comuna, en què algú afegeix una reserva i espera que l'adreça del túnel la segueixi.

Articles relacionats