De ce un VPN TAP partajat are în continuare nevoie de HTTPS pe portal

Două dispozitive au acreditări VPN valide și partajează un singur segment Ethernet punte. Doar unul dintre ele ar trebui să răspundă pentru portalul biroului, iar celălalt poate încă revendica adresa portalului pe acel segment. Tunelul și-a făcut treaba: a autentificat ambii parteneri și a criptat fiecare cale către server. Ce nu a făcut a fost să certifice care dintre ei deține un nume de serviciu, iar această lacună este motivul pentru care portalul are în continuare nevoie de un certificat valid.

Ce autentifică de fapt VPN-ul

Strângerea de mână VPN răspunde la o singură întrebare: care partener a finalizat acest tunel și cu ce material de cheie. Răspunsul este pentru fiecare partener și fiecare conexiune și nu spune nimic despre serviciile pe care acel partener le expune ulterior. Pe un segment TAP partenerul nu este nici măcar o singură adresă, pentru că poate prezenta orice MAC și orice IP pe care puntea este dispusă să îl învețe. Autentificarea se oprește la capătul tunelului, nu la aplicație.

Separați cele trei întrebări în loc să le fuzionați într-una. Fiecare are propriul mecanism și propriul mod de eșec.

O implementare poate avea un tunel perfect autentificat și un serviciu complet neautentificat în spatele lui. Poate avea și un certificat validat pe o gazdă a cărei adresă de al doilea strat este revendicată de un alt partener, motiv pentru care ambele controale aparțin proiectului, nu unul în locul celuilalt. Tabelul este întregul argument în trei rânduri.

ARP pe un segment partajat nu este un director

ARP asociază o adresă IPv4 unei adrese MAC pe legătura locală și acceptă răspunsuri de la oricine de pe acea legătură. Pe un segment punte permisiv, un partener poate revendica o adresă care aparține altui dispozitiv, iar puntea trimite cadrele către cel care a răspuns cel mai recent. Criptarea fiecărei căi a clientului către server nu schimbă asta, pentru că cadrele sunt decriptate înainte de a ajunge la punte. Granița de încredere a ARP este segmentul, nu tunelul.

Uitați-vă la ce a învățat de fapt gazda: ip neigh show listează mapările curente și starea lor, iar o intrare care alternează între două adrese MAC în timpul funcționării normale este un simptom care merită investigat, nu ignorat. Pe un segment mic și sănătos astfel de intrări rămân stabile mult timp.

Izolarea partenerilor și politica punții există exact pentru acest caz. Un proiect rutat este de obicei răspunsul mai bun când serviciul este doar IP și dispozitivele nu au niciun motiv să vadă cadrele celuilalt.

Păstrați validarea certificatului acolo unde este serviciul

TLS-ul aplicației răspunde la întrebarea la care tunelul nu poate: este acesta serviciul la care voiam să ajung. Browserul verifică numele de gazdă față de certificat, iar acea verificare este singura parte a lanțului care numește portalul, nu partenerul.

Inspectați ce prezintă serverul înainte de a decide că avertismentul este cosmetic. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal tipărește lanțul și numele alternative ale subiectului. Dacă numele introdus nu apare în acea listă, avertismentul este corect și certificatul este ceea ce trebuie reparat. A-i învăța pe utilizatori să îl ignore transformă un control funcțional în decor.

Ghidul de punte OpenVPN descrie modelul Ethernet și opțiunile de politică din jurul lui și este referința corectă pentru ceea ce segmentul ar trebui să permită. Citiți-l înainte de a relaxa o regulă de punte, pentru că modelul descris este ceea ce presupune fiecare verificare de mai sus.

Decideți dacă acei parteneri ar trebui să partajeze un segment

Cea mai ieftină soluție este de obicei să nu mai partajați al doilea strat când cerința este doar accesibilitatea IP. Un VPN rutat oferă fiecărui client propria adresă, elimină domeniul de difuzare partajat și transformă traficul între parteneri într-o decizie de politică în loc de una implicită. Portalul are atunci o singură adresă de protejat și niciun vecin care să o poată revendica.

Dacă segmentul trebuie să rămână, verificați setarea din partea serverului care le permite clienților să se atingă: grep -n client-to-client /etc/openvpn/server.conf. Când este dezactivată, traficul clienților trece prin server și poate fi filtrat acolo. Când este activată, partenerii schimbă cadre direct prin punte, iar punctele dumneavoastră de filtrare sunt puntea și firewall-ul gazdei.

Notați pe ce protecții se bazează de fapt fiecare gazdă: autentificarea tunelului, izolarea segmentului sau TLS-ul aplicației. O gazdă care depinde de toate trei este în regulă. O gazdă care depinde de prima și presupune că celelalte două au venit cu ea este cea care ajunge să servească conținutul greșit.