Limite un receptor VPN ás interfaces que pretendía
Un receptor comodín e unha regra de devasas son controis distintos. Lea os sockets reais con ss e despois comprobe a familia de enderezos e a devasa.
Un servizo VPN é accesible desde onde estea ligado o seu socket e a súa devasa o permita. Son dúas decisións separadas, e normalmente a xente só toma unha delas. Ler o receptor real leva dez segundos e resolve unha cuestión que as conxecturas non poden. Empece por aí e logo cambie un control cada vez.
Todo o seguinte supón que pode executar ordes no host con root ou sudo.
Lea os sockets antes de cambiar nada
En Linux, ss -lunp enumera os receptores UDP co seu enderezo local, porto e proceso, e ss -ltnp fai o mesmo con TCP. Busque o porto da VPN e lea con coidado a columna de enderezo. 0.0.0.0:51820 e [::]:51820 significan todas as interfaces, mentres que 10.0.0.5:51820 significa un enderezo nunha interface. O manual de ss documenta as columnas se a saída non lle resulta familiar. Se falta o nome do proceso, execute a mesma orde con sudo, porque a columna de propietario necesita privilexios.
Anote o enderezo. É o feito do que depende o resto desta guía.
Líguese a un enderezo, non a un desexo
OpenVPN liga o receptor a un enderezo concreto coa súa directiva local, e esa é a forma admitida de acotalo a nivel de proceso. Non todas as implementacións ofrecen un equivalente, e un protocolo sen opción de ligazón non se pode estreitar deste xeito. Se a súa non ten ningunha, a devasa é o seu único control, e as notas de despregamento deberían dicilo claramente. Nun host con varias direccións, líguese á que mira cara ao túnel; ligarse a un enderezo flotante adoita ser un erro.
Un servizo que debe sobrevivir a un cambio de enderezo necesita un plan para a ligazón obsoleta, non só unha liña de configuración.
Comprobe a familia de enderezos por separado
IPv4 e IPv6 son sockets separados. Un proceso ligado a 0.0.0.0 aínda pode aceptar IPv6 mediante un socket de dobre pila, ou pode que non, segundo a opción do socket e o valor predeterminado da plataforma. Ler só a liña IPv4 enganou a máis dunha revisión de despregamento. Enumere ambas as familias antes de concluír que o receptor é estreito.
Se IPv6 non forma parte do deseño, desactivalo a nivel de socket é máis limpo que esperar que a devasa o cubra. É unha decisión de política, así que anótea xunto co resto de eleccións de interface.
Superpoña a devasa á ligazón
Unha ligazón estreita non substitúe unha regra de devasa, e unha regra de devasa non estreita unha ligazón comodín. Use ambas: líguese onde a implementación o admite e logo permita o porto só desde as fontes que deberían alcanzalo. Os grupos de seguridade da nube sitúanse diante da devasa do host, así que comprobe ambos cando a ruta cruza unha fronteira de VPC. A regra efectiva é a intersección das dúas, e cada capa só pode restar accesibilidade.
Probe desde unha fonte permitida e desde unha excluída deliberadamente. Unha conexión desde localhost non demostra nada sobre a fronteira pública.
Anote o que escolleu
Anote o enderezo ligado, a interface que o posúe, a regra de devasa e o seu propósito. Unha NIC de recambio ou un enderezo de nube reasignado poden cambiar a exposición sen que ninguén edite o perfil. Póñalle data á nota, porque os enderezos de nube móvense entre revisións máis a miúdo do que a xente espera.
Esa nota é o que converte a próxima revisión nunha comparación en lugar dun proxecto de arqueoloxía.