Limiteu la regla SNAT d’OpenVPN abans que trenqui nginx

Dues fallades arriben sempre del mateix tipus d’amfitrió. En la primera, els clients s’autentiquen i després no arriben enlloc més enllà del túnel. En la segona, la VPN s’aixeca i el propi lloc web del servidor deixa de respondre, que és la més alarmant perquè sembla un dany col·lateral. En un VPS basat en contenidors, totes dues solen remuntar-se a la mateixa llista curta de comprovacions, i l’ordre importa: primer el dispositiu, segon la traducció, tercer l’abast.

Confirmeu que el contenidor pot crear un dispositiu tun

Res més no importa si la interfície de túnel no pot existir. Comproveu que /dev/net/tun hi sigui i que la creació d’un dispositiu de prova tingui èxit, perquè molts proveïdors desactiven tun dins dels contenidors per defecte. Cap quantitat de feina amb firewall compensa un dispositiu que mai es va crear.

Si falta el dispositiu, només l’amfitrió o el proveïdor poden habilitar-lo. Sovint un pla diferent és més barat que un fil de suport obert que dura una setmana. Confirmeu-ho abans de llegir una sola línia del registre d’OpenVPN. Altrament passareu la vetllada ajustant regles que mai no veuran un paquet.

Decidiu què fa MASQUERADE en aquesta interfície

En una màquina virtual corrent, la regla de sortida habitual és POSTROUTING MASQUERADE de la interfície principal. En un contenidor OpenVZ el dispositiu visible sovint és venet0, una interfície virtual gestionada per l’amfitrió i no una NIC encaminada, i MASQUERADE no sempre s’hi comporta com assumeixen els tutorials.

La forma viable és una traducció explícita cap a l’adreça que els clients ja assoleixen, amb el reenviament permès en tots dos sentits. Substituir el pool de la configuració del servidor importa tant com substituir l’adreça. Llegiu cada línia abans d’enganxar-la.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sense les regles de reenviament, la traducció igualment passa i el nucli igualment es nega a reenviar. Aquesta combinació produeix l’estat confús en què els comptadors de la regla NAT pugen mentre el client no rep res. Les dues línies FORWARD també han d’anar abans de qualsevol regla drop àmplia a la mateixa cadena. L’ordre forma part de la configuració, no és un detall d’implementació.

Limiteu la regla a un pool i una interfície

El segon símptoma té una causa diferent: una regla POSTROUTING sense restricció d’origen ni de sortida. Aquesta regla reescriu cada paquet que surt de l’amfitrió.

Els serveis que depenen de l’origen original es comporten malament. Un servidor web darrere d’un proxy local pot deixar de respondre, i reiniciar-lo no canvia res perquè la regla encara és al camí. El tràfic que l’amfitrió envia a la seva pròpia adreça pública també en queda afectat, i per això la fallada pot semblar un problema de DNS o de certificat en lloc d’un de firewall. La regla gairebé segur que es va afegir per arreglar el primer símptoma.

La solució és estrenyer la coincidència al pool del túnel i a la interfície de sortida, i després afegir una regla per pool en lloc d’ampliar una sola regla per cobrir-ne diverses.

Feu les regles persistents i esbrineu qui més en té la propietat

Les regles afegides a mà desapareixen en reiniciar, així que deseu-les amb iptables-save o gestioneu-les amb netfilter-persistent on estigui instal·lat. Confirmeu que la restauració s’executa abans que arrenqui OpenVPN. Després reinicieu un cop expressament en lloc de descobrir el forat durant un incident.

En un amfitrió de contenidors, confirmeu també que el fitxer de persistència viu en emmagatzematge de contenidor escribible i que el proveïdor no substitueix el filtratge en arrencar. Algunes plataformes gestionen la política fora del contenidor, on les regles locals o bé s’ignoren o bé lluiten amb les de l’amfitrió.

Verifiqueu amb comptadors i un flux capturat

Des d’un client connectat, comproveu l’adreça pública que informa un servei extern. Si coincideix amb l’adreça del servidor, la traducció funciona; si no, el paquet surt per un altre camí o no surt gens. Després proveu tant un servei allotjat al servidor com un a la internet pública, perquè segueixen camins diferents pel mateix conjunt de regles.

Al servidor, llegiu els comptadors de paquets de les regles NAT i FORWARD amb iptables -t nat -L -v -n i observeu un flux en una captura. Si l’adreça del client apareix a la captura i no segueix cap resposta, el forat és al camí de tornada o en el filtratge del proveïdor, no al perfil del client. Compareu l’origen capturat amb l’adreça a què tradueix la regla, perquè una discrepància vol dir que una altra regla va coincidir primer. Un sol flux observat resol més que una pàgina de lectura de configuració.

Mantingueu el pool, l’adreça traduïda i el nom de la interfície junts al registre de canvis. Una regla correcta per a un pool tradueix malament la següent.