Komunigita VPN-konto: aparatlimo ne estas klienta izolado

Ok samtempaj konektoj estas nombro de licenca paĝo, kaj ĝi diras nenion pri tio, kion tiuj ok aparatoj povas fari unu al la alia. Komunigita saluto povas kunekzisti kun ŝlosiloj por ĉiu seanco, kaj ĝi ankaŭ povas kunekzisti kun kluzo, kiu volonte plusendas la trafikon de unu kliento al alia. La eraro estas trakti la konton kiel sekurecan limon. Anstataŭe demandu kvar apartajn demandojn: kio estis aĉetita, kio protektas la tunelon, kio rajtas transiri inter samuloj, kaj kio povas faligi la lokan ligon.

Kion permiso de konektoj efektive promesas

Aparatlimo kalkulas, kiom da seancoj la provizanto akceptos por unu abono. Ĝi estas komerca kaj operacia regilo, ne deklaro pri identeco aŭ izolado. Iuj provizantoj eldonas apartan atestilon por ĉiu aparato sub unu konto; aliaj reuzas unu legitimilon por ĉiu konekto. La diferenco aperas ĉe revoko, ĉar apartaj legitimiloj permesas al vi fortranĉi unu aparaton, dum komunigita ne lasas al vi tian eblon.

Legu kiel la provizanto eldonas legitimilojn antaŭ ol supozi ion pri ŝlosila apartigo. La kontnomo mem rivelas nenion el tio.

Kontrolu ĉu la kluzo plusendas inter klientoj

Atingebleco inter samuloj estas decido ĉe la servila flanko. Ĉe OpenVPN la koncerna ŝaltilo forestas krom se ĝi aperas en la agordo, sed moderna datenplena elŝarĝo ŝanĝas kie la regulo aplikiĝas.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Agordo sen tiu direktivo lasas samulan trafikon al la gastiga fajroŝirmilo, kiu ankoraŭ povas permesi ĝin. Kiam elŝarĝo aktivas, la kerno traktas la tunelan interfacon anstataŭ la procezo en uzantspaco, do kontrolu regulkalkilojn anstataŭ fidi la dosieron. Blokado de plusendita trafiko inter tunelaj adresoj izolas klientojn sen tuŝi ilian aliron al la kluzo. Konfirmu per provo de unu kliento al servo ĉe alia, kaj antaŭ kaj post la regulo.

Protektu la seanson antaŭ la samuloj

Tunela protekto kaj samula aliro estas malsamaj ecoj, kaj forta ĉifro ne implicas izoladon. En TLS-reĝimo ĉiu kliento derivas siajn proprajn seancoŝlosilojn, do unu kliento ne povas legi la trafikon de alia eĉ kiam la kluzo plusendas ĝin. Malnova aranĝo kun statika ŝlosilo dividas unu ŝlosilon inter ĉiuj, tial reuzi saluton tie havas multe pli malbonajn sekvojn. Ekzamenu la agorditan reĝimon anstataŭ la merkatan paĝon, poste juĝu ĉu konto-kunhavigo taŭgas por la koncernaj datumoj.

Serva aŭtentikigo ĉe ĉiu gastigo ankoraŭ gravas, ĉar la tunelo pruvas nur ke kliento atingis la reton, ne ke ĝi rajtas atingi certan demonon.

Lokaj Wi-Fi-fiaskoj ne estas VPN-kompromitoj

Falinta konekto pruvas ke la loka ligo fiaskis, ne ke iu rompis la tunelon. Interfero, perdita DHCP-luo kaj migrada transdono ĉiuj finas seancon sen tuŝi legitimilojn aŭ ĉifrotekston. Traktu malkonekton kiel trovon pri havebleco kaj tenu ĝin aparte de trovaĵoj pri konfidenco kaj samula aliro. Kie la loka reto ne fidindas, protektu la trafikon de fino al fino anstataŭ apogiĝi nur sur la tunelo.

Skribu la kvar respondojn: permeso, ŝlosilmodelo, samula politiko kaj dependeco de la loka ligo. Tiu registro ŝanĝas vagan zorgon pri komunigita konto en konkretajn regilojn.