Tallafoc al núvol davant del tallafoc de l'amfitrió per a un servidor VPN
Dos filtres guarden el mateix port VPN. Recorregueu l’ordre de fronteres des de la política del núvol fins a l’oient de l’amfitrió i, després, demostreu la correcció amb una sessió nova.
Permeteu el port VPN a la política del núvol i l’intercanvi de claus encara pot morir a la instància: l'amfitrió executa el seu propi filtre i la seva pròpia vinculació de l’oient, i qualsevol dels dos pot descartar el que el núvol ha aprovat. També passa al revés, quan una regla de l’amfitrió permet el port i una política superior el descarta abans. Dos propietaris, dos conjunts de regles, un sol camí de paquets. Recorregueu-lo en ordre en lloc d’endevinar a la capa més sospitosa.
Comenceu per la vora i aneu cap endins
L’ordre és fix: punt final públic, interfície del recurs, política del núvol adjunta, adreça de l’amfitrió, oient del procés i regles d’entrada locals. Cada etapa o deixa passar el paquet o acaba la investigació, i per això començar per l’amfitrió és el que fa perdre més temps.
El trànsit de client reenviat és una etapa a part, que s’inspecciona després de desencapsular el túnel. La capa del núvol només veu el túnel exterior, així que pot aprovar una connexió i no tenir res a veure amb una petició de servei interna. Un túnel que connecta però no arriba a un equip intern sol assenyalar el reenviament, no un port tancat.
Llegiu la política del núvol abans de tocar l’amfitrió
Confirmeu la regla d’entrada del port VPN, el seu protocol i l’abast d’origen que coincideix amb el client de prova. Reviseu també la llista de control d’accés de la subxarxa: un segon filtre amb regles i valors per defecte propis. Tots dos han de permetre el flux abans que un paquet arribi a la instància. Una permissió en un i una denegació a l’altre és la forma habitual d’aquest error.
Estrebeu l’abast fins que signifiqui alguna cosa. Obrir el port VPN a tot internet és fàcil de demostrar i difícil de defensar, mentre que una regla fixada a una adreça es trenca quan el client de prova canvia de xarxa. Anoteu l’identificador de la regla i el propietari de la política, perquè el proper canvi sigui traçable fins a una persona.
Confirmeu l’oient i, després, la cadena d’entrada
A la instància, comproveu que el procés VPN està lligat a l’adreça i el port que espereu, per exemple amb ss -lntp 'sport = :1194'. Un dimoni lligat només a 127.0.0.1 accepta clients locals i res a través del túnel, cosa que des de fora sembla exactament un port filtrat.
Després llegiu les regles locals amb la sintaxi que faríeu servir per canviar-les, com ara iptables -S INPUT o nft list chain inet filter input. Una regla escrita en un fitxer però mai carregada, o un descart per defecte sense cap permís que hi encaixi, descarta paquets en silenci. Per a una passarel·la que reenvia, reviseu també la configuració de reenviament i de camí invers. Decideixen què passa amb els paquets encaminats a través de la instància i no adreçats a ella.
Amb estat en una capa, sense estat a la següent
Els grups de seguretat recorden els fluxos que han permès i deixen tornar les respostes. Les llistes de control d’accés de subxarxa i molts tallafocs d’amfitrió no guarden aquest estat, així que una regla que només cobreix la direcció de sortida deixa passar la petició i descarta la resposta. No porteu mai una suposició sobre trànsit de retorn entre capes sense llegir la regla de la segona capa.
Els comptadors ho resolen més de pressa que llegir cada regla del compte. Un comptador que puja vol dir que el paquet hi va arribar i hi va ser descartat, mentre que un de congelat a zero vol dir que no hi va arribar mai; iptables -vnL INPUT i nft list ruleset mostren aquests recomptes quan les regles es van carregar amb comptadors.
Proveu amb una sessió nova, no amb una d’oberta
Deixeu intactes la xarxa d’origen i el perfil de prova mentre compareu vistes, i obriu una connexió nova després de cada canvi. Arribar a la consola web al 443 no diu res sobre si el dimoni VPN està lligat al 1194, així que proveu el port que necessiteu. Una sessió existent és el pitjor testimoni aquí. Continua funcionant mentre es rebutja cada inici de sessió nou.
Abans d’editar una política remota, assegureu-vos una via de retorn que no depengui del camí que canvieu. Després obriu una segona sessió d’administració al costat de la prova VPN: una d’establerta abans pot sobreviure a la regla que bloqueja les noves. Anoteu els dos propietaris de les polítiques perquè cap reconstrucció no restauri mig camí; si les dues capes hi estan d’acord i el túnel encara falla, captureu a la interfície de l’amfitrió i comproveu l’adreça i el port que el client fa servir de debò.