Kopīgs VPN konts: ierīču limits nav klientu izolācija
Atļauja astoņām ierīcēm neko nepasaka par izolāciju vai atslēgu pārvaldību. Atdaliet konta limitus, tuneļa aizsardzību, pārsūtīšanu starp vienaudžiem un vietējo Wi-Fi.
Astoņi vienlaicīgi savienojumi ir skaitlis no licences lapas, un tas neko nepasaka par to, ko šīs astoņas ierīces var nodarīt viena otrai. Kopīga pieteikšanās var pastāvēt līdzās sesijas atslēgām, un tā var pastāvēt arī līdzās vārtejai, kas labprāt pārsūta viena klienta trafiku citam. Kļūda ir uzskatīt kontu par drošības robežu. Tā vietā uzdodiet četrus atsevišķus jautājumus: kas tika nopirkts, kas aizsargā tuneli, kas drīkst šķērsot starp vienaudžiem un kas var nogāzt vietējo saiti.
Ko savienojumu atļauja patiešām sola
Ierīču limits skaita, cik sesijas pakalpojumu sniedzējs pieņems vienam abonementam. Tā ir komerciāla un operatīva kontrole, nevis paziņojums par identitāti vai izolāciju. Daži pakalpojumu sniedzēji izsniedz atsevišķu sertifikātu katrai ierīcei viena konta ietvaros; citi atkārtoti izmanto vienu akreditācijas datu kopu katram savienojumam. Atšķirība parādās atsaukšanas laikā, jo atsevišķi dati ļauj atslēgt vienu ierīci, bet kopīgi šādu iespēju neatstāj.
Izlasi, kā pakalpojumu sniedzējs izsniedz akreditācijas datus, pirms pieņemt kaut ko par atslēgu atdalīšanu. Pats konta nosaukums par to neko neatklāj.
Pārbaudiet, vai vārteja pārsūta starp klientiem
Sasniedzamība starp vienaudžiem ir lēmums servera pusē. OpenVPN gadījumā attiecīgais slēdzis nav pieejams, ja vien tas nav norādīts konfigurācijā, taču mūsdienu datu plaknes izkraušana maina to, kur noteikums tiek piemērots.
grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROPKonfigurācija bez šīs direktīvas atstāj trafiku starp vienaudžiem resursdatora ugunsmūrim, kas to joprojām var atļaut. Kad izkraušana ir aktīva, tuneļa saskarni apstrādā kodols, nevis lietotāja telpas process, tāpēc pārbaudiet noteikumu skaitītājus, nevis uzticieties failam. Pārsūtītā trafika bloķēšana starp tuneļa adresēm izolē klientus, neaizskarot viņu piekļuvi vārtejai. Apstipriniet to ar pārbaudi no viena klienta uz pakalpojumu citā, gan pirms noteikuma, gan pēc tā.
Aizsargājiet sesiju pirms vienaudžiem
Tuneļa aizsardzība un vienaudžu piekļuve ir dažādas īpašības, un spēcīgs šifrs nenozīmē izolāciju. TLS režīmā katrs klients atvasina savas sesijas atslēgas, tāpēc viens klients nevar lasīt otra trafiku pat tad, ja vārteja to pārsūta. Vecā statiskās atslēgas shēma dala vienu atslēgu starp visiem, tāpēc pieteikšanās atkārtotai izmantošanai tur ir daudz ļaunākas sekas. Pārbaudiet konfigurēto režīmu, nevis mārketinga lapu, un tad spriediet, vai konta koplietošana atbilst attiecīgajiem datiem.
Pakalpojuma autentifikācija katrā resursdatorā joprojām ir svarīga, jo tunelis pierāda tikai to, ka klients ir sasniedzis tīklu, nevis to, ka tam jāsasniedz konkrēts dēmons.
Vietējie Wi-Fi traucējumi nav VPN kompromitēšana
Pārrauts savienojums pierāda, ka vietējā saite ir sabojājusies, nevis to, ka kāds ir uzlauzis tuneli. Traucējumi, zaudēta DHCP nomācija un viesabonēšanas pāreja izbeidz sesiju, neaizskarot akreditācijas datus vai šifrēto tekstu. Attiecieties pret atvienošanu kā pieejamības konstatējumu un turiet to atsevišķi no konfidencialitātes un vienaudžu piekļuves konstatējumiem. Kur vietējais tīkls nav uzticams, aizsargājiet trafiku no gala līdz galam, nevis paļaujieties tikai uz tuneli.
Pierakstiet četras atbildes: atļauja, atslēgu modelis, vienaudžu politika un atkarība no vietējās saites. Šis ieraksts neskaidras bažas par kopīgu kontu pārvērš konkrētās kontrolēs.