Una NIC o dues? Com decidir la disposició d'interfícies d'un servidor VPN

Un sol adaptador físic és suficient per a molts servidors VPN, i tampoc no és un disseny universal. La connexió xifrada arriba a aquest adaptador, el procés VPN la desxifra i el trànsit interior surt per una interfície virtual abans d'arribar a un servei local o a una LAN encaminada. Que funcioni depèn de tres condicions: on viu la destinació, si la LAN té un camí de tornada cap al conjunt de clients i si un enllaç físic compartit us dona l'aïllament que afirmeu. Responeu aquestes tres i el nombre d'adaptadors en surt sol.

Les tres condicions que ho decideixen

La primera condició és la destinació. Un servei al mateix amfitrió VPN s'assoleix només per la interfície del túnel, mentre que un amfitrió a la LAN requereix reenviament i un camí de tornada. La segona condició és aquest camí de tornada, perquè el dispositiu de la LAN ha de saber com arribar al conjunt de clients, sigui per una ruta o per traducció al servidor.

La tercera condició és la separació. Un adaptador vol dir que cada paquet, xifrat o no, comparteix un enllaç i normalment una cadena de polítiques, així que una afirmació d'aïllament que depèn de maquinari separat no la satisfà una sola interfície. És un fet sobre el camí, no sobre com està configurat el sistema operatiu. Encara podeu filtrar el trànsit del túnel, però no podeu afirmar una frontera que no teniu.

Cap de les tres no va del nombre de ports del xassís. Van de l'encaminament, de la propietat d'adreces i de fins a quin punt el disseny depèn de la separació física.

Dos adaptadors continuen sent una opció legítima quan zones físiques, enllaços ascendents separats, rendiment o un camí de recuperació fora de banda ho justifiquen. Són requisits concrets i val la pena dir-los abans que algú encarregui maquinari.

Quan el servei s'executa a l'amfitrió VPN

El cas més simple no necessita cap reenviament. El dimoni rep els paquets del client a la interfície del túnel i els lliura a un sòcol local, i la resposta torna per la mateixa interfície. L'adreça del conjunt de clients és una adreça local real des del punt de vista de l'amfitrió.

Encara hi ha dues coses que han d'estar bé: el servei ha d'escoltar en una adreça que el túnel pugui assolir, i el tallafoc de l'amfitrió ha d'acceptar el trànsit que arriba a la interfície del túnel. Totes dues són visibles a les ordres de sota.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Lligar un servei només a l'adreça pública, o filtrar la interfície del túnel per error, produeix una connexió que arriba a l'amfitrió i després mor. Sembla una fallada de VPN i normalment és una decisió de sòcol o de tallafoc.

Quan la destinació és a la LAN

Aquí és on un disseny d'un sol adaptador guanya la fama de ser delicat. El servidor ha de reenviar els paquets del client cap a la LAN, i el dispositiu de la LAN ha d'enviar les respostes al conjunt de clients. O porteu aquest conjunt com una ruta a la LAN, o traduïu l'adreça d'origen al servidor perquè les respostes tornin al mateix servidor.

Totes dues respostes són legítimes i fallen de manera diferent. Una ruta de tornada manté l'adreça original del client visible per a la destinació, cosa bona per als registres i dolenta per a regles de tallafoc que pressuposen adreces de LAN. La traducció manté la LAN simple i amaga la identitat del client a la destinació.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Un camí asimètric és el símptoma clàssic: la petició del client arriba, la resposta surt per un altre encaminador i la connexió caduca sense cap error en cap dels dos extrems. Captureu als dos costats abans de concloure res sobre el túnel.

Per què un àlies no crea una segona zona

Afegir una segona adreça al mateix adaptador, o crear una interfície fictícia per imitar un segon port, canvia molt poc. Els paquets surten igualment pel mateix enllaç físic, el mateix port del commutador i normalment la mateixa cadena de tallafoc, així que no hi ha cap frontera nova entre ells. És comoditat de configuració, no segmentació. Tractar-ho com una frontera de zona és com una afirmació d'aïllament sobreviu només al paper.

Una zona separada necessita una separació real al camí, i aquest és el requisit que satisfà un segon adaptador. Si una regla depèn que el trànsit orientat a VPN no comparteixi mai un domini de difusió amb el trànsit orientat a LAN, un sol cable no pot oferir aquesta propietat, per molt que s'adreci l'amfitrió.

On un producte documenta una topologia multiinterfície per a un mode concret, seguiu la documentació d'aquell producte en lloc d'inventar una solució alternativa. Els proveïdors també canvien les topologies suportades entre versions, i és una altra raó per llegir la guia actual i no una captura antiga de l'assistent.

Comproveu la disposició contra el trànsit que permeteu

Lliste les classes de trànsit que el servidor ha de portar: client a amfitrió, client a LAN, amfitrió a LAN i la connexió exterior xifrada. Cada classe té un origen, una destinació i una interfície, i la disposició ha de satisfer les quatre alhora. Un disseny que en resol tres és normalment el que genera tiquets.

Després confirmeu les interfícies reals i la captura real, no el diagrama del document de disseny. Les ordres de sota imprimeixen totes dues vistes.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Si la captura exterior mostra el trànsit xifrat i la captura interior mostra el trànsit desxifrat a la interfície del túnel mentre l'adaptador físic porta tots dos, una sola NIC fa la feina. Si la captura interior és buida, el problema és al túnel o a les regles de reenviament, no al nombre d'adaptadors. Decidiu la topologia a partir d'aquestes dues captures i de la taula d'encaminament, i el proper canvi tindrà amb què mesurar-se.