pfSense com a servidor i client VPN: dos camins, un sol encaminador

Un sol aparell pot mirar en dues direccions alhora: els usuaris itinerants es connecten cap a dins, i la mateixa caixa es connecta cap a fora a un proveïdor de sortida perquè el trànsit seleccionat surti per una altra xarxa. Habilitar tots dos serveis triga minuts; fer-los conviure demana un disseny, perquè el segon rol reescriu la taula d’encaminament de què depèn el primer. Tres condicions decideixen si l’arranjament funciona, és a dir, si el servei d’entrada conserva la seva pròpia ruta de tornada, si el túnel de sortida encara pot arribar al seu igual i si el trànsit que volíeu reenviar queda seleccionat per a la sortida. Si us equivoqueu en un, obteniu dos túnels que tots dos informen de connectat mentre res útil no travessa entre ells. Les comprovacions de sota estableixen cada condició en l’ordre en què solen aparèixer les fallades.

Anomeneu els dos rols abans de tocar cap paràmetre

Anoteu quatre fets per a cada instància: el seu igual remot, el material d’autenticació, el conjunt d’adreces que reparteix i les xarxes que té al darrere. Les dues instàncies són objectes separats a l’aparell i també ho han de ser a les vostres notes. Gairebé tots els símptomes confusos posteriors vénen de barrejar-ne els valors, i dues instàncies que comparteixen un joc de notes és com el conjunt equivocat acaba al camp equivocat.

El servei d’entrada necessita una xarxa de túnel que no se solapi amb les adreces del túnel de sortida ni amb cap xarxa privada que l’aparell encamini. El solapament és l’únic error que produeix símptomes en tots dos rols alhora, i és molt més barat enxampar-lo sobre el paper. Compareu tots dos conjunts i cada xarxa privada encaminada en un sol lloc abans de configurar qualsevol dels serveis.

El maquinari compartit no implica credencials compartides, i un certificat de client del conjunt d’accés remot no hauria de servir contra el proveïdor de sortida. El material separat també converteix la revocació en una decisió local en lloc d’un esdeveniment d’abast global.

Mantingueu les respostes del servidor al camí WAN

Les respostes que l’aparell genera ell mateix són la primera víctima d’una ruta per defecte descurada. Quan arriba un paquet encapsulat d’un usuari itinerant, la resposta és trànsit d’origen local i ha de sortir per la interfície per la qual va arribar aquell usuari. Si el client de sortida ha instal·lat una ruta per defecte que la captura, la resposta entra al túnel equivocat i la sessió s’encalla mentre el servei encara sembla sa.

No hi ha cap casella única que ho resolgui, perquè la decisió és sobre quin trànsit pot capturar el client de sortida. O bé no estireu cap ruta i dirigiu només el que seleccioneu, o bé estireu rutes i afegiu les excepcions que mantenen en marxa els serveis propis de l’aparell. Escriviu l’elecció al costat de la instància, o la propera persona suposarà l’altra.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Llegiu la taula d’encaminament per la coincidència més llarga i no per l’ordre en què hàgiu configurat res. La pregunta és quina entrada guanya per a l’adreça de l’igual de sortida i quina entrada guanya per a la resposta del servei d’entrada, i aquestes dues respostes poden diferir.

No deixeu que el túnel de sortida es mengi el seu propi extrem

El client de sortida ha d’arribar a l’adreça pública del seu igual per establir el túnel, si més no. Si aquesta adreça s’encamina dins del túnel, el client es persegueix la cua: el transport no s’aixeca mai, o s’aixeca i cau en el moment que s’instal·la la ruta. El registre sembla un temps d’espera d’autenticació i no una fallada d’encaminament, i per això la ruta mereix la primera comprovació.

Comproveu la ruta abans de les credencials i de nou un cop el túnel és aixecat, perquè una entrada pot ser correcta en arrencar i incorrecta un minut després. L’adreça de l’igual ha d’apuntar al camí WAN ordinari, mai al dispositiu de túnel. Quan el transport s’estabilitza, la pregunta interessant passa al trànsit reenviat, que és la decisió següent.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Trieu quins usuaris reben la sortida

La política d’origen pertany a l’entrada on el trànsit entra a l’aparell, així que trieu el conjunt d’accés remot, o identitats més estretes dins seu. Preserveu les destinacions privades i les excepcions de gestió que no s’han d’enviar mai a la sortida, i col·loqueu aquestes regles abans de la regla àmplia. El camí de sortida necessita llavors la seva pròpia traducció o un arranjament de retorn encaminat, cosa que per a la majoria de dissenys vol dir NAT de sortida a la interfície de sortida que cobreixi el conjunt. La traducció no tria una sortida; només reescriu el que ja ha sortit, així que una regla NAT en un WAN aliè no canvia res en la selecció.

Confirmeu que l’extrem remot permet el trànsit reenviat d’aquest disseny, perquè alguns proveïdors ho permeten i d’altres no. La diferència es veu com un túnel que connecta i no porta res, cosa que és fàcil de llegir malament com una fallada local. Proveu els tres fluxos per separat, perquè fallen de manera independent i dos de tres és un disseny mig fet.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

La primera ordre és la connexió exterior de l’usuari itinerant, i funciona quan el client informa que la seqüència d’inicialització s’ha completat. La segona, executada des d’aquell portàtil connectat, hauria d’informar de l’adreça del proveïdor de sortida i no de la vostra adreça WAN. La tercera s’executa a l’aparell lligada a una adreça del conjunt, i prova la política d’origen per al trànsit reenviat sense implicar cap usuari remot. Si en canvi respon des del WAN, la política no ha coincidit, i cap quantitat d’edició de NAT no arregla un problema de selecció.

Decidiu què passa quan la sortida falla

Escriviu el comportament davant la fallada abans que passi: quan el túnel de sortida cau, els usuaris tornen al WAN ordinari o queden bloquejats fins que la sortida torna? Totes dues respostes són defensables, i l’aparell no triarà per vosaltres. Una ruta eliminada o una política que apunta a una passarel·la morta no produeixen automàticament un resultat de bloqueig total. Si voleu bloqueig, la política ho ha de dir explícitament, i s’ha de provar traient la sortida i no raonant sobre ella. Si voleu retrocés, publiqueu-ho als usuaris, perquè el trànsit que pren silenciosament el camí ordinari és exactament el trànsit que algú creia cobert.

Desactiveu la instància de client, mireu a què pot arribar encara un usuari connectat i torneu-la a engegar. Una petició que expira és el resultat de bloqueig total que demanàveu; la que respon amb l’adreça WAN és el retrocés que no vau documentar. Repetiu la comprovació per a IPv6 i per a DNS, perquè una política escrita per a IPv4 no diu res del trànsit AAAA i un resolutor empès per qualsevol dels túnels respon des d’on surt realment la consulta.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

La recepta de Netgate per a OpenVPN encaminat mostra com encaixen la política d’origen, l’assignació d’interfícies i la traducció de sortida, i el seu abast entre llocs és la part que no s’ha de copiar sencera. El que no us dirà és quina de les tres condicions de dalt ja ha trencat el vostre propi disseny.