Executar una VPN i un lloc web en un sol amfitrió sense col·lisions

Compartir un amfitrió entre un lloc públic i una VPN fa que hereteu dues preguntes, no una: què escolta on i qui autentica qui. Responeu les dues abans de tocar cap fitxer de configuració, perquè els valors per defecte són errònis d’una manera que només es veu sota càrrega. Una pàgina que carrega per HTTPS demostra que l’oient web respon i res sobre l’oient dels parells. El que segueix és un ordre de decisions que evita que es mengin l’un a l’altre.

Decidiu què escolta en quina adreça i transport

Escriviu una taula de tres columnes, adreça, transport i port, i una fila per servei, inclosa la interfície administrativa. TCP 443 per al lloc i UDP 443 per a la VPN no són cap conflicte encara que els números coincideixin, perquè el transport és diferent. Dos serveis a la mateixa adreça, transport i port necessiten un acord que la implementació documenti, no un que inventeu durant una caiguda. Aquesta taula també és l’artefacte que fa revisable el canvi següent.

Adreces separades o un segon port fan visible la propietat en una captura de paquets, cosa que val més que l’elegància. Algunes implementacions de VPN permeten compartir un port amb un servidor web, però el mecanisme és específic: el dimoni inspecciona els primers bytes i reenvia el trànsit que no és el seu protocol. Un servidor intermediari invers HTTP genèric no ho fa, i reescriure les capçaleres no el farà entendre un intercanvi de claus d’un túnel xifrat. Llegiu les notes de desplegament del protocol, com ara la documentació de l’oient d’OpenVPN, i seguiu l’acord que descriu.

Decidiu quina identitat pertany a quin servei

Un certificat de navegador i una credencial de parell de VPN són objectes diferents amb models de confiança diferents. El certificat web el valida una autoritat pública i nomena un nom d’amfitrió, mentre que la credencial de parell autentica un dispositiu o un usuari davant del concentrador i pot ser autosignada o emesa internament. Reutilitzar l’un com l’altre funciona en casos estrets i poques vegades val la pena l’acoblament. Desactivar la verificació perquè encaixi un certificat compartit no és un pla de separació; elimina la comprovació que donava sentit a la credencial.

Mantingueu els dos magatzems independents i anoteu quina autoritat emet cadascun. Quan se’n rota un, l’altre no hauria de necessitar canvis, i si en necessita, l’acoblament és el que cal arreglar.

Decidiu on viu l’administració

La interfície administrativa de la VPN pertany a un camí de gestió, mai a l’oient públic, fins i tot quan l’amfitrió ja serveix internet. Un servidor web al 443 no implica que la consola dels parells hagi de ser abastable des de qualsevol lloc, i la consola sol ser l’objectiu de més valor. Lligueu-la a una adreça de bucle local o de gestió, restringiu-la per origen i manteniu un camí de recuperació que no depengui que el túnel estigui aixecat. El camí de recuperació importa perquè la fallada habitual és quedar-te fora mentre arregles el bloqueig.

Escriviu regles de tallafocs estretes, una per oient, anomenant la interfície o el compte de servei on la plataforma ho permeti. Les regles àmplies que obren l’amfitrió perquè el lloc necessita el 443 són com les interfícies administratives acaben als índexs dels escàners.

Reviseu aquestes regles contra la taula d’oients sempre que s’afegeixi un servei. La revisió és barata i atrapa la regla que algú va afegir a les dues de la matinada.

Decidiu què fer quan els dos competeixen

Compartir un amfitrió vol dir compartir CPU, memòria, descriptors de fitxer i amplada de banda, i el recurs disputat no sempre és l’obvi. Un lloc ocupat pot omplir la taula de connexions, esgotar les ranures de treball o empènyer la cua de disc prou fort perquè el registre de la VPN s’aturi. Mireu l’ús per servei en lloc dels totals de l’amfitrió, perquè una mitjana amaga quin procés passa gana. Si una càrrega de treball pertorba repetidament l’altra, aïlleu-les en lloc d’ajustar al voltant del símptoma.

L’aïllament pot ser un contenidor, un límit de cgroup, una cua separada o un segon amfitrió, i l’elecció correcta depèn de quin recurs competeix. Un canvi de port no arregla res aquí, i una instància més gran no arregla res si el límit és una cua saturada. Decidiu amb un mesurament: anomeneu el recurs, carregueu-lo i després trieu l’aïllament més petit que elimini la competició.

Verifiqueu des de fora, i després un altre cop després d’un reinici

Proveu des d’un dispositiu que no sigui a la xarxa de l’amfitrió: carregueu el lloc, aixequi el túnel i arribeu a un recurs que el necessiti. Després reinicieu cada servei pel seu compte i repetiu l’altra prova, perquè un reinici és quan un acord d’oient compartit perd el seu ordre. Si la VPN arrenca abans del servidor web que posseeix el port compartit, el mecanisme de compartició pot no adjuntar-se mai, i el símptoma és un túnel que ahir funcionava. Feu explícita la dependència en l’ordre de les unitats.

Després confirmeu els límits: el lloc respon al seu port, la VPN respon al seu, i la interfície administrativa respon només des del camí de gestió. Anoteu el resultat al costat de la taula d’oients amb la data. Un amfitrió que passa les tres comprovacions després d’un reinici és un amfitrió que podeu lliurar a algú altre sense cap sessió informativa.