Kial kunhavata TAP-VPN ankoraŭ bezonas HTTPS ĉe la portalo
TAP-VPN aŭtentikigas la kunulon, ne la servon malantaŭ ĝi. Konservu gastnoman validigon ĉe la portalo kaj izolu najbarojn, kiujn vi ne fidas.
Du aparatoj havas validajn VPN-legitimilojn kaj kunhavas unu pontitan Eterreton-segmenton. Nur unu el ili devas respondi pri la oficeja portalo, kaj la alia ankoraŭ povas pretendi la portaladreson en tiu segmento. La tunelo faris sian taskon: ĝi aŭtentikigis ambaŭ kunulojn kaj ĉifris ĉiun vojon al la servilo. Kion ĝi ne faris, estis atesti, kiu el ili posedas servnomon, kaj ĝuste tiu manko estas la kialo, ke la portalo ankoraŭ bezonas validan atestilon.
Kion la VPN efektive aŭtentikigas
VPN-manpremado respondas unu demandon: kiu kunulo finis ĉi tiun tunelon kaj kun kiu ŝlosilmaterialo. Tiu respondo estas po kunulo kaj po konekto, kaj ĝi diras nenion pri la servoj, kiujn tiu kunulo poste elmetas. En TAP-segmento la kunulo eĉ ne estas unu adreso, ĉar ĝi povas prezenti ajnan MAC kaj ajnan IP, kiun la ponto pretas lerni. Aŭtentikigo haltas ĉe la tunela finpunkto, ne ĉe la aplikaĵo.
Apartigu la tri demandojn anstataŭ kunfandi ilin en unu. Ĉiu havas sian propran mekanismon kaj sian propran fiaskmanieron.
| 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 |
Eldono povas havi perfekte aŭtentikigitan tunelon kaj tute neaŭtentikigitan servon malantaŭ ĝi. Ĝi ankaŭ povas havi validigitan atestilon sur gasto, kies duanivelan adreson pretendas alia kunulo, kaj tial ambaŭ kontroloj apartenas al la dezajno anstataŭ unu anstataŭigi la alian. La tabelo estas la tuta argumento en tri vicoj.
ARP en kunhavata segmento ne estas adresaro
ARP mapigas IPv4-adreson al MAC en la loka ligo kaj akceptas respondojn de iu ajn en tiu ligo. En permesema pontita segmento kunulo povas pretendi adreson, kiu apartenas al alia aparato, kaj la ponto plusendas kadrojn al tiu, kiu respondis laste. Ĉifri ĉiun klientan vojon al la servilo tion ne ŝanĝas, ĉar kadroj malĉifriĝas antaŭ ol ili atingas la ponton. La fidlimo de ARP estas la segmento, ne la tunelo.
Rigardu, kion la gasto efektive lernis: ip neigh show listigas la nunajn mapigojn kaj ilian staton, kaj rikordo, kiu dum normala funkciado alternas inter du MAC-adresoj, estas simptomo inda je esploro anstataŭ je ignorado. En sana malgranda segmento tiuj rikordoj restas stabilaj longe.
Kunula izolado kaj ponta politiko ekzistas ĝuste por ĉi tiu kazo. Enkursigita dezajno kutime estas la pli bona respondo, kiam la servo estas nur IP kaj la aparatoj havas neniun kialon vidi la kadrojn de la alia.
Konservu la atestilan validigon tie, kie estas la servo
La TLS de la aplikaĵo respondas la demandon, kiun la tunelo ne povas: ĉu ĉi tio estas la servo, kiun mi volis atingi. La retumilo kontrolas la gastnomon kontraŭ la atestilo, kaj tiu kontrolo estas la sola parto de la ĉeno, kiu nomas la portalon anstataŭ la kunulon.
Esploru, kion la servilo prezentas, antaŭ ol decidi, ke la averto estas kosmetika. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal presas la ĉenon kaj la alternativajn nomojn de la subjekto. Se la nomo, kiun vi tajpis, mankas en tiu listo, la averto estas ĝusta kaj la atestilo estas tio, kion oni devas ripari. Instrui uzantojn klaki preter ĝi transformas funkciantan kontrolon en ornamon.
La OpenVPN-pontiga gvidilo priskribas la Eterreton-modelon kaj la politikajn opciojn ĉirkaŭ ĝi, kaj ĝi estas la ĝusta referenco por tio, kion la segmento devas permesi. Legu ĝin antaŭ ol malstreĉi pontan regulon, ĉar la modelo, kiun ĝi priskribas, estas tio, kion ĉiu kontrolo supre supozas.
Decidu, ĉu tiuj kunuloj entute devas kunhavi segmenton
La plej malmultekosta solvo kutime estas ĉesi kunhavi la duan tavolon, kiam la postulo estas nur IP-atingebleco. Enkursigita VPN donas al ĉiu kliento sian propran adreson, forigas la kunhavatan dissendan domajnon kaj igas trafikon inter kunuloj politika decido anstataŭ defaŭlto. Tiam la portalo havas unu adreson por protekti kaj neniujn najbarojn, kiuj povas ĝin pretendi.
Se la segmento devas resti, kontrolu la agordon sur la servila flanko, kiu lasas klientojn atingi unu la alian: grep -n client-to-client /etc/openvpn/server.conf. Kiam ĝi estas malŝaltita, klienta trafiko pasas tra la servilo kaj povas esti filtrita tie. Kiam ĝi estas ŝaltita, kunuloj interŝanĝas kadrojn rekte tra la ponto, kaj viaj filtradpunktoj estas la ponto kaj la gasto-fajroŝirmilo.
Notu, je kiuj protektoj ĉiu gasto efektive dependas: tunela aŭtentikigo, segmenta izolado aŭ aplikaĵa TLS. Gasto, kiu dependas de ĉiuj tri, estas en ordo. Gasto, kiu dependas de la unua kaj supozas, ke la aliaj du venis kun ĝi, estas tiu, kiu finfine servas la malĝustan enhavon.