Bakit Kailangan Pa Rin ng HTTPS sa Portal ang Pinagsasaluhang TAP VPN

Dalawang aparato ang may valid na mga kredensyal ng VPN at pinagsasaluhan ang isang Ethernet segment na naka-bridge. Isa lamang sa kanila ang dapat tumugon para sa portal ng opisina, at ang isa ay maaari pa ring mag-claim ng address ng portal sa segment na iyon. Ginawa ng tunnel ang trabaho nito: pinatunayan nito ang dalawang kapareha at ini-encrypt ang bawat landas patungo sa server. Ang hindi nito ginawa ay patunayan kung alin sa kanila ang may-ari ng isang pangalan ng serbisyo, at ang puwang na iyon ang dahilan kung bakit kailangan pa rin ng portal ng valid na sertipiko.

Ano ba talaga ang pinapatunayan ng VPN

Ang handshake ng VPN ay sumasagot sa isang tanong: aling kapareha ang tumapos sa tunnel na ito, at sa anong key material. Ang sagot na iyon ay bawat kapareha at bawat koneksyon, at wala itong sinasabi tungkol sa mga serbisyong inilalantad ng kaparehang iyon pagkatapos. Sa isang TAP segment ang kapareha ay hindi man lang isang address, dahil maaari itong magpakita ng anumang MAC at anumang IP na handang matutunan ng bridge. Ang pagpapatunay ay tumitigil sa dulo ng tunnel, hindi sa aplikasyon.

Paghiwalayin ang tatlong tanong sa halip na pagsamahin ang mga ito sa isa. Bawat isa ay may sariling mekanismo at sariling paraan ng pagpalya.

Ang isang deployment ay maaaring may perpektong napapatunayan na tunnel at ganap na hindi napapatunayang serbisyo sa likod nito. Maaari rin itong may valid na sertipiko sa isang host na ang layer-two address ay kinukuha ng ibang kapareha, at iyon ang dahilan kung bakit ang dalawang kontrol ay kabilang sa disenyo sa halip na palitan ng isa ang isa. Ang talahanayan ang buong argumento sa tatlong hilera.

Ang ARP sa pinagsasaluhang segment ay hindi direktoryo

Ang ARP ay nagmamapa ng IPv4 address sa MAC sa lokal na link at tumatanggap ng mga sagot mula sa kahit sino sa link na iyon. Sa isang mapagbigay na naka-bridge na segment, ang isang kapareha ay maaaring mag-claim ng address na pag-aari ng ibang aparato, at ipinapasa ng bridge ang mga frame sa huling sumagot. Ang pag-encrypt sa bawat landas ng kliyente patungo sa server ay hindi nagbabago nito, dahil ang mga frame ay dine-decrypt bago makarating sa bridge. Ang hangganan ng pagtitiwala ng ARP ay ang segment, hindi ang tunnel.

Tingnan kung ano talaga ang natutunan ng host: inililista ng ip neigh show ang mga kasalukuyang mapping at ang kalagayan ng mga ito, at ang entry na nagpapalit sa pagitan ng dalawang MAC address sa normal na operasyon ay sintomas na dapat imbestigahan sa halip na ipagwalang-bahala. Sa malusog na maliit na segment, ang mga nasabing entry ay nananatiling matatag nang matagal.

Ang paghihiwalay ng kapareha at patakaran ng bridge ay umiiral para sa ganitong kaso. Ang naka-ruta na disenyo ay kadalasang mas mabuting sagot kapag ang serbisyo ay IP lamang at ang mga aparato ay walang dahilan upang makita ang mga frame ng isa't isa.

Panatilihin ang pagpapatunay ng sertipiko kung nasaan ang serbisyo

Ang TLS ng aplikasyon ay sumasagot sa tanong na hindi kayang sagutin ng tunnel: ito ba ang serbisyong gusto kong maabot. Sinusuri ng browser ang hostname laban sa sertipiko, at ang pagsusuring iyon ang tanging bahagi ng chain na nagpangalan sa portal at hindi sa kapareha.

Siyasatin kung ano ang ipinapakita ng server bago magpasya na ang babala ay kosmetiko. Ini-print ng openssl s_client -connect portal.example.internal:443 -servername portal.example.internal ang chain at ang mga alternatibong pangalan ng subject. Kung ang pangalan na naipasok mo ay wala sa listahang iyon, ang babala ay tama at ang sertipiko ang kailangang ayusin. Ang turuan ang mga gumagamit na laktawan ito ay ginagawang dekorasyon ang isang gumaganang kontrol.

Gabay sa bridge ng OpenVPN ang naglalarawan ng Ethernet model at ng mga pagpipilian sa patakaran sa paligid nito, at ito ang tamang sanggunian para sa dapat payagan ng segment. Basahin ito bago lumuwag ng isang tuntunin ng bridge, dahil ang modelong inilalarawan nito ang ipinapalagay ng bawat pagsusuri sa itaas.

Magpasya kung dapat bang magbahagi ng segment ang mga kaparehang iyon

Ang pinakamurang pag-aayos ay kadalasang itigil ang pagbabahagi ng layer two kapag ang pangangailangan ay pag-abot sa IP lamang. Ang naka-ruta na VPN ay nagbibigay sa bawat kliyente ng sarili nitong address, tinatanggal ang pinagsasaluhang broadcast domain at ginagawang desisyon sa patakaran ang trapiko sa pagitan ng mga kapareha sa halip na default. Pagkatapos ay may isang address ang portal na poprotektahan at walang kapitbahay na maaaring mag-claim nito.

Kung kailangang manatili ang segment, suriin ang setting sa gilid ng server na nagpapahintulot sa mga kliyente na maabot ang isa't isa: grep -n client-to-client /etc/openvpn/server.conf. Kapag naka-disable ito, dumadaan sa server ang trapiko ng mga kliyente at maaaring i-filter doon. Kapag naka-enable ito, direktang nagpapalitan ng mga frame ang mga kapareha sa pamamagitan ng bridge, at ang iyong mga punto ng pag-filter ay ang bridge at ang firewall ng host.

Isulat kung aling mga proteksyon ang aktwal na inaasahan ng bawat host: pagpapatunay ng tunnel, paghihiwalay ng segment o TLS ng aplikasyon. Ang host na umaasa sa lahat ng tatlo ay maayos. Ang host na umaasa sa una at ipinapalagay na ang dalawa pa ay kasama nito ang siyang sa huli ay naghahain ng maling nilalaman.