Per què una VPN TAP compartida encara necessita HTTPS al portal
Una VPN TAP autentica el parell, no el servei que hi ha darrere. Mantingueu la validació del nom d’amfitrió al portal i aïlleu els veïns en qui no confieu.
Dos dispositius tenen credencials VPN vàlides i comparteixen un segment Ethernet pontificat. Només un d’ells ha de respondre pel portal de l’oficina, i l’altre encara pot reclamar l’adreça del portal en aquest segment. El túnel va fer la seva feina: va autenticar tots dos parells i va xifrar cada camí fins al servidor. El que no va fer va ser certificar quin d’ells posseeix un nom de servei, i aquesta llacuna és la raó per la qual el portal encara necessita un certificat vàlid.
Què autentica realment la VPN
L’apretada de mans de la VPN respon una pregunta: quin parell ha completat aquest túnel i amb quin material de clau. Aquesta resposta és per parell i per connexió, i no diu res sobre els serveis que aquell parell exposa després. En un segment TAP, el parell no és ni tan sols una sola adreça, perquè pot presentar qualsevol MAC i qualsevol IP que el pont estigui disposat a aprendre. L’autenticació s’atura a l’extrem del túnel, no a l’aplicació.
Separeu les tres preguntes en lloc de col·lapsar-les en una. Cadascuna té el seu mecanisme i la seva manera de fallar.
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
Un desplegament pot tenir un túnel perfectament autenticat i un servei completament no autenticat al darrere. També pot tenir un certificat validat en un amfitrió l’adreça de segona capa del qual és reclamada per un altre parell, i per això els dos controls pertanyen al disseny en lloc de substituir-se l’un a l’altre. La taula és tot l’argument en tres files.
L’ARP en un segment compartit no és un directori
L’ARP assigna una adreça IPv4 a una MAC a l’enllaç local i accepta respostes de qualsevol en aquest enllaç. En un segment pontificat permissiu, un parell pot reclamar una adreça que pertany a un altre dispositiu, i el pont reenvia les trames a qui ha respost més recentment. Xifrar cada camí de client fins al servidor no ho canvia, perquè les trames es desxifren abans d’arribar al pont. La frontera de confiança de l’ARP és el segment, no el túnel.
Mireu què ha après realment l’amfitrió: ip neigh show llista les assignacions actuals i el seu estat, i una entrada que canvia entre dues adreces MAC durant el funcionament normal és un símptoma que val la pena investigar en lloc de descartar. En un segment petit i sa, aquestes entrades es mantenen estables durant molt de temps.
L’aïllament de parells i la política del pont existeixen exactament per a aquest cas. Un disseny encaminat sol ser la resposta millor quan el servei és només IP i els dispositius no tenen cap motiu per veure les trames dels altres.
Mantingueu la validació del certificat on és el servei
El TLS de l’aplicació respon la pregunta que el túnel no pot: és aquest el servei al qual volia arribar. El navegador comprova el nom d’amfitrió contra el certificat, i aquesta comprovació és l’única part de la cadena que anomena el portal en lloc del parell.
Inspeccioneu què presenta el servidor abans de decidir que l’avís és cosmètic. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal imprimeix la cadena i els noms alternatius del subjecte. Si el nom que heu escrit no és en aquesta llista, l’avís és correcte i el certificat és el que cal arreglar. Ensenyar els usuaris a saltar-se’l converteix un control funcional en decoració.
La guia de pontificació d’OpenVPN descriu el model Ethernet i les opcions de política que l’envolten, i és la referència correcta per a allò que el segment ha de permetre. Llegiu-la abans de relaxar una regla de pont, perquè el model que descriu és el que assumeix cada comprovació anterior.
Decidiu si aquests parells han de compartir un segment
La solució més barata sol ser deixar de compartir la segona capa quan el requisit és només la connectivitat IP. Una VPN encaminada dona a cada client la seva pròpia adreça, elimina el domini de difusió compartit i converteix el trànsit entre parells en una decisió de política en lloc d’un valor per defecte. Aleshores el portal té una adreça a protegir i cap veí que la pugui reclamar.
Si el segment ha de quedar-se, comproveu el paràmetre del costat del servidor que permet als clients arribar els uns als altres: grep -n client-to-client /etc/openvpn/server.conf. Amb això desactivat, el trànsit dels clients passa pel servidor i s’hi pot filtrar. Amb això activat, els parells intercanvien trames directament a través del pont i els vostres punts de filtratge són el pont i el tallafoc de l’amfitrió.
Anoteu en quines proteccions confia realment cada amfitrió: autenticació del túnel, aïllament del segment o TLS de l’aplicació. Un amfitrió que depèn de les tres està bé. Un amfitrió que depèn de la primera i assumeix que les altres dues van venir amb ella és el que acaba servint el contingut equivocat.