OpenVPN o IKEv2: apat na pagsusuri bago pumili ng protocol

Ang pagpili sa pagitan ng OpenVPN at IKEv2 ay karaniwang pinagtatalunan bilang isang tanong sa protocol, at ang balangkas na iyon ay nagsasayang ng desisyon. Ang nagpapasya ay kung sinusuportahan ng iyong server at mga aparato ang parehong kumpletong profile, at kung nakakayanan ng profile na iyon ang paraan ng iyong paglipat sa pagitan ng mga network. Ang dalawang stack ay hindi nagiging isa't isa: ang OVPN file ay hindi IKEv2 profile na may ibang syntax. Ang apat na pagsusuri, na isinasagawa nang sunod-sunod, ay sumasagot sa tanong nang mas mabilis kaysa sa anumang talahanayan ng tampok.

Ang kulang na kliyente ay nagtatapos sa talakayan

Ang Windows at macOS ay may kasamang IKEv2 client, kaya ang IKEv2 profile ay walang dagdag na gastos na i-deploy doon at namamana nito ang mga opsyon sa provisioning na iniaalok na ng operating system. OpenVPN sa parehong mga makina ay nangangahulugan ng third-party na client na i-install, i-update at suportahan, at kailangang tanggapin ng client na iyon ang bawat opsyon na ginagamit ng profile. Bilangin ang mga platform na kailangan mong saklawin bago ihambing ang anumang iba pa, dahil ang platform na walang gumaganang client ay hindi punto ng paghahambing.

Sa Windows, isang command ang naglilista ng mga profile na mayroon na at nagpapakita kung anong uri ang bawat isa. Ang pangalang ipinapalabas nito ang pangalang ginagamit ng mga susunod na pagsusuri.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Ang paghiling na mag-install ng client ang tunay na sagot para sa kolum ng OpenVPN sa mga platform na iyon, at ito ay gawaing deployment at hindi limitasyon ng protocol. Wala sa mga kaayusan ang nag-aalis ng mga pagsusuri sa pagtitiwala, pagpapatunay ng pagkakakilanlan o maintenance. Itanong kung paano ipinamamahagi ang mga profile, paano binabago ang mga kredensyal at paano tinatanggal ang nawalang aparato bago ka magcommit. Ang simpleng pag-install ay maaari pa ring magtago ng proseso ng pagbawi na walang gustong patakbuhin sa katapusan ng linggo.

Ang mobility ay pinagsamang setting, hindi pangako ng protocol

Maaaring gamitin ng IKEv2 ang MOBIKE kapag parehong sinusuportahan at pinagana ito ng dalawang dulo, na nagpapahintulot sa client na mapanatili ang tunnel habang nagbabago ang address nito. RFC 4555 ay tumutukoy sa extension, at mahalaga ang kondisyonal na pananalita: ang server na binabalewala ang kakayahang iyon ay muling nakikipagnegosasyon sa halip. Maaaring magmukhang pareho ang resulta para sa paglilipat ng file at ibang-iba para sa live na tawag.

Subukan ang transisyong talagang mahalaga sa iyo, na may tumatakbo na mapapansin mo. Hayaang tumakbo ang ping -t <internal-host> sa Windows, o simpleng ping sa ibang lugar, pagkatapos lumipat mula Wi-Fi patungo sa cellular at panoorin ang mga patlang. Ang kabiguan ng MOBIKE ay lumilitaw bilang buong muling pagpapatunay sa log ng client, hindi bilang tahimik na pag-update ng address. Ang sinusukat mo ay kung nakakayanan ng tunnel ang pagbabago, hindi kung inaanunsyo ng protocol ang suporta.

Ang mga OpenVPN client ay muling kumokonekta ayon sa pag-uugali ng kanilang platform at mga timer ng profile, kaya ang parehong pagsubok ay maaaring magbunga ng ibang hugis ng pagkagambala. Ihambing ang pangyayaring mahalaga sa iyong mga gumagamit, hindi ang label sa protocol.

Ang mga kredensyal ay pag-aari ng serbisyo, hindi ng stack

Ang mga sertipiko at iba pang kaayusan sa pag-login ay pag-aari ng serbisyong nagtatapos ng koneksyon. Ang kahilingan ng password sa isang client ay walang sinasabi tungkol sa pagiging compatible sa iba, at ang profile na gumagana laban sa ibang gateway ay walang sinasabi tungkol dito. Panatilihing buo ang mga patakaran sa pagkakakilanlan ng server habang inihahambing ang dalawang stack. Ang pagpapalit ng protocol bago mo matukoy ang kabiguan ay karaniwang gumagawa ng pangalawang hindi compatible na profile.

Suriin ang kredensyal na ipapakita ng client bago sisihin ang alinmang protocol, dahil ang nag-expire o maling naisyung sertipiko ay nabibigo sa parehong paraan sa dalawa. Ang output sa ibaba ay nagpapakita ng subject, issuer at mga petsa ng validity nang hindi binabasa ang private key.

openssl x509 -in client.crt -noout -subject -issuer -dates

Para sa koneksyon ng kumpanya, gamitin ang paraang inilalathala ng kumpanya at itigil ang pagtrato sa paghahambing bilang eksperimento. Kung ikaw mismo ang naghahambing sa dalawa, tiyakin muna kung parehong nagtatapos sa isang gateway ang dalawang opsyon, dahil ang isang detalyeng iyon ang nagpapasya kung gaano karami ng resulta mo ang tungkol sa protocol. Ang pagtangging pinapangalanan ang kredensyal ay problema sa kredensyal, at walang dami ng pagpapalit ng protocol ang makakapag-ayos nito.

Suriin kung ano ang talagang niruruta ng tunnel

Pagkatapos kumonekta, tiyakin na umiiral ang rutang kailangan mo at nalulutas ang mga pangalan. Ang profile na umiiral para sa mga panloob na mapagkukunan ay maaaring sadyang iwanan ang ordinaryong pagba-browse sa lokal na landas, at iyon ay desisyon sa patakaran, hindi sira. Ang mahalaga ay kung ang mga destinasyong ginagamit ng iyong koponan ay naaabot sa pamamagitan ng tunnel.

Sa Windows, dalawang command ang sumasaklaw sa ruta at paghahanap ng pangalan. Ang mga katumbas sa Linux ay ip route show default at resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Ang tunnel na bumangon at walang niruruta na kapaki-pakinabang ay karaniwang resulta kapag ang isang profile ay kinopya sa pagitan ng mga serbisyo, at ang pangkalahatang pagsubok sa konektibidad ay hindi ito maipapakita dahil nakataas ang interface. Subukan ang mapagkukunang unang binubuksan ng iyong mga gumagamit, hindi isang pampublikong address na naaabot ng kahit anong landas. Kung ang pangalan ay nalulutas sa isang pampublikong address habang ang ruta ay tumuturo papasok sa tunnel, ang sagot ng DNS at ang ruta ay pag-aari ng magkaibang desisyon at parehong kailangang ayusin.

Timbangin ang maintenance pagkatapos ng mga pagsusuri

Wala sa mga protocol ang mas madaling i-maintain sa abstract. Ang maintenance ay nakadepende sa kung sino ang nagpapatakbo ng gateway, paano nakakarating ang mga profile sa mga aparato at gaano kabilis mawalan ng access ang nawalang aparato. Ang simpleng endpoint client ay maaaring tumayo sa harap ng server na mas mahirap patakbuhin, at nangyayari rin ang kabaligtaran. Itanong kung alin sa dalawa ang kayang panatilihing tumatakbo ng iyong koponan pagkatapos umalis ng taong nagtayo nito.

Piliin ang sinusuportahang koneksyon na sumasaklaw sa trabaho, pagkatapos subukan ito laban sa access na talagang kailangan mo, hindi laban sa listahan ng tampok. Itala kung saang gateway nagtatapos ang bawat opsyon, dahil ang dalawang magkaibang gateway ay ginagawang usapin ng ruta ang paghahambing kung gaano rin usapin ng protocol. Ulitin ang apat na pagsusuri sa aparatong talagang dadalhin mo, at itago ang profile na pumasa doon.