Sinira ng ikalawang VPN client ang una: hanapin ang pinagsasaluhang resource

Kahapon gumagana ang orihinal na client. Ngayon ay humihingi ng koneksyon ang bago habang ang lumang profile ay tumitigil sa isang yugto na dating nilalampasan nang walang reklamo. Bihirang kasangkot ang mga kredensyal, at karaniwang inosente ang gateway. Ang nagbago ay gusto na ngayon ng dalawang VPN stack ang parehong eksklusibong resource, at nakadepende ang pag-aayos sa pagpangalan dito. Daanan ang mga layer sa halip na i-install muli ang dalawa.

Daunan ang apat na layer nang sunud-sunod

Kailangan ng produktong VPN ng apat na resource na maaaring magbanggaan: isang background service na madalas tumangging tumakbo nang dalawang beses, isang fixed port, isang virtual adapter o kernel filter na nakakakita ng trapiko bago ang routing table, at ang karapatang mag-install ng mga ruta sa harap ng default. Ang pag-alam kung alin ang sumuko ay ginagawang isang tanong na may nasusubok na sagot ang malabong hidwaan.

Itugma ang sintomas sa isang layer bago hawakan ang anuman. Ang client na hindi nagsisimula ay tumuturo sa serbisyo; ang nagsisimula ngunit hindi kailanman nakikipagnegosasyon ay tumuturo sa port; ang kumokonekta habang nawawala ang lahat ng koneksyon ng isa ay tumuturo sa filter o sa default route. Isulat ang pagtutugmang iyon, dahil nakakatipid ito ng isang oras ng muling pag-install ng mga app nang may pag-asa.

Magsimula sa serbisyong hindi tumatakbo nang dalawang beses

Sa Windows ang corporate client ay karaniwang higit pa sa tunnel, dahil nag-i-install ito ng serbisyo, filter driver, at kung minsan ay credential provider kasama ng profile. Itala kung aling mga serbisyo ang tumatakbo bago ang pagbabago at muli pagkatapos, pagkatapos ay ihambing ang dalawang listahan sa halip na mag-reboot hanggang may gumana. Maaari ring magbukod ang mga serbisyo sa isa't isa sa pamamagitan ng mga dependency, kung saan ang pagsisimula ng isa ay humihinto sa isa pa, at ang parehong pattern ay lumilitaw sa macOS sa mga gawain ng launchd at isang pinagsasaluhang daemon. Ang client na nagsisimula at lumalabas sa loob ng ilang segundo ay nag-uulat ng pagmamay-ari, hindi ng configuration.

Basahin ang estado ng serbisyo at ang log nito bago basahin ang profile. Ang serbisyong nagsimula at huminto sa parehong minuto ay ang pattern na hahanapin, at ang sarili nitong event log ay nagpapangalan sa dependency na nag-alis dito. Hindi kayang ayusin ng profile ang isang prosesong hindi tumatakbo, at ang oras na ginugol sa pag-edit nito ay oras na hindi ginugol sa tunay na hidwaan.

Pagkatapos ay itanong kung kanino ang port

Ang pagmamay-ari ng port ang pinakamalinaw na ebidensyang makukuha mo, dahil direktang pinangalanan ng pagkabigo sa pag-bind ang hidwaan. Dalawang implementasyon ng IKE ay hindi maaaring parehong sumagot sa parehong lokal na address at UDP port, at walang dami ng muling pagsubok ang makakabago niyon.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Alinmang linya ang tumugma sa iyong platform, ang sagot na gusto mo ay isang proseso at ang serbisyong nagbunga nito. Kung ang tagapakinig ay ang built-in na serbisyong IKE, ang ikalawang client ang nanghihimasok; kung ahente ito ng vendor, ang built-in na client ang nanghihimasok. Magpasya kung alin ang maaaring magsimula sa pag-log in at i-disable ang autostart ng isa sa halip na patayin ito bawat session.

Nasa ilalim ng iyong mga ruta ang filter driver

Hinaharang ng network filter driver ang trapiko sa pagitan ng adapter at protocol stack, kaya maaari nitong muling isulat o harangan ang mga packet anuman ang sabihin ng routing table. Ganito binabalewala ang isang rutang mukhang tama, at kaya naman maaaring tumabi ang matagumpay na ping sa isang browser na walang kayang i-load.

Nakagapos din ang mga component ng vendor sa mga partikular na koneksyon. Ang lumang filter na nakagapos sa isang adapter ay maaaring pumigil sa isang profile na kung hindi ay tama na tapusin ang handshake nito, at ang pagkalas ng component na iyon mula sa mga property ng adapter ay mas makitid at mas naibabalik kaysa sa ganap na pagtanggal ng produkto. Dahil ang pagkakagapos ay bawat koneksyon, ihambing ang mga adapter sa halip na ang buong stack.

Magpasya kung aling produkto ang may-ari ng boot, pagkatapos ay itala ito

Ang pagtira nang magkasama ay makatotohanan lamang kapag ang dalawang client ay sumasakop sa magkaibang layer ayon sa disenyo, tulad ng IPsec stack sa tabi ng proxy na humahawak lamang ng trapiko ng aplikasyon. Kung saan gusto ng dalawa ang parehong port, parehong filter layer, o karapatang mag-publish ng default route, patuloy silang maghahalinhinan at ang bawat kabiguan ay magmumukhang bagong depekto.

Piliin ang may-ari nang sadya. Kabilang sa mga anyong nakakaligtas sa reboot ang pagpapatakbo ng ikalawang client sa loob ng virtual machine, pagpapanatili nito sa dedikadong hardware, o pag-standardize sa isang client na nagsasalita ng dalawang protocol. Ang pag-disable sa autostart at serbisyo ng natatalo ay mas maliit na pagbabago kaysa sa muling pagbuo ng routing table pagkatapos ng bawat simula, at naibabalik ito sa isang pag-edit ng setting.