Ang kliyente ng SoftEther sa pag-boot: AccountStartupSet at ang pagkakasunod-sunod ng daemon

Kapag ni-reboot ang makina, naiiwan ito sa network na nakababa pa rin ang tunnel. Ang kliyente ng SoftEther ay may dalawang estado na itinuturing ng karamihan na isa lang: kung tumatakbo ang serbisyo, at kung pinapayagang umangat ang isang naka-save na account kasama nito. Dapat totoo ang dalawa, at ang pangalawa ay bandila sa bawat account, hindi setting ng boot. Isagawa ang apat na pagsusuri sa ibaba nang sunod-sunod at huminto sa unang pagkabigo.

Tiyakin na ang account ay minarkahan para sa awtomatikong pagsisimula

Nasa record ng account ang bandila sa loob ng sariling configuration ng kliyente, kaya binubura ito kapag ini-reinstall ang kliyente o ibinalik ang walang laman na direktoryo. Buksan ang management console at tingnan ang listahan ng account bago magbago ng anupaman.

cd /opt/softether/vpnclient
./vpncmd

Piliin ang 2 para sa pamamahala ng VPN client at tanggapin ang lokal na server sa pamamagitan ng pagpindot sa Enter.

AccountStartupSet
office-hub
exit

Itinatala ng AccountStartupSet ang account bilang isa na dapat iangat kapag nagsimula ang serbisyo ng kliyente. Hindi nito sinisimulan ang serbisyo o gumagawa ng bagong account, at wala itong nakalimbag na kapaki-pakinabang kapag mali ang pangalan. Basahin muli ang listahan ng account pagkatapos ng utos, dahil tahimik ang typo at mukhang eksaktong bandila na hindi naging epektibo.

Tiyakin na nagsisimula ang serbisyo, at sapat na maaga

Sa Linux, tumatakbo ang kliyente bilang daemon mula sa sariling direktoryo, at kailangan itong nakabangon bago subukan ng anumang hakbang ng boot na gamitin ang account. Sapat ang maikling hook na nagbabago ng direktoryo at nagsisimula nito sa mga sistemang nagpapatakbo pa ng rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Kung wala na ang rc.local, sumulat ng unit ng systemd na may tahasang WorkingDirectory at patakaran sa restart. Nireresolba ng binary ang configuration nito kaugnay ng lugar kung saan ito sinisimulan, kaya ang unit na walang setting na iyon ay maaaring matagumpay na magsimula at walang mabasa. Ang pagkakasunod-sunod ang ikalawang kalahati ng problema: ang pagtatangkang kumonekta na tumatakbo bago makinig ang daemon ay paminsan-minsang nabibigo, na mas mahirap i-diagnose kaysa sa tuloy-tuloy na pagkabigo. Sinasaklaw ng patakaran sa restart ang ikatlong kaso, kapag tahimik na namatay ang daemon pagkalipas ng mga oras.

Suriin ang listahan ng proseso sa halip na magtiwala sa pid file na iniwan ng nakaraang boot.

Tiyakin na nakatanggap ng address ang adapter

Kapag kumonekta ang account, nagpapakita ang kliyente ng virtual adapter at kailangan pa rin ng address ang adapter. Karaniwang sumasagot sa DHCP ang hub na nagpapatakbo ng SecureNAT; ang hub na naka-bridge sa isang pisikal na LAN ay umaasang ang server ng LAN na iyon ang sasagot sa halip.

ip -brief address
dhclient vpn_vpn1

Kunin ang pangalan ng interface mula sa listahan, dahil ang numero sa isang halimbawa ay hindi constant. Kung kailangang static ang address, ilagay ito sa network configuration ng distribution para sa interface na iyon upang muling mailapat pagkatapos ng link event at hindi lamang sa boot. Ang one-shot script ay nag-iiwan sa adapter na walang address sa unang pagkakataong muling kumonekta ang tunnel sa araw. Mukhang patay na tunnel ang pagkabigong iyon kahit maayos ang account.

Ang adapter na walang address ang pinakatahimik na pagkabigo sa listahan, dahil patuloy pa ring nag-uulat ang account na nakakonekta ito.

Tiyakin na ang ruta ay tumuturo sa inaakala mo

Maaari pa ring mabigo ang trapiko kahit malusog ang link at wasto ang address. Tanungin ang kernel kung aling interface ang gagamitin para sa destinasyon sa loob ng subnet ng hub, pagkatapos ihambing ang sagot na iyon sa tunnel.

ip route get 10.10.20.15

Ang lokal na subnet na nagsasapawan sa saklaw ng hub ang nananalo, dahil mas tiyak ang ruta nito at naka-install na.

Iyon ay desisyon sa pagbibigay ng numero, hindi bug ng kliyente, at hindi ito babaguhin ng pag-restart ng serbisyo. Ang configuration ng resolver ang kabilang kalahati: ang address na walang gumaganang DNS server ay gumagawa ng tunnel na pumapasa sa bawat pagsusuri ng link at hindi pa rin makakabukas ng pangalan.

Isulat ang apat na pagsusuri sa mga tala ng muling pagbuo

Itala nang magkasama ang pangalan ng account, utos sa pagsisimula ng serbisyo, at pangalan ng interface, dahil ibinabalik ng muling itinayong host ang data ng account ngunit hindi ang hook ng operating system na naglulunsad ng daemon. Nasa magkakaibang lugar ang mga iyon at karaniwang iba't ibang tao ang nagba-backup.

Ang bandila ay isang linyang muling ilalapat at madaling kalimutan.

Panatilihin ang pagkakasunod-sunod: bandila, serbisyo, address, ruta. Ang checklist na nagsisimula sa gitna ay nagbubunga ng maraming mali ngunit kumpiyansang sagot.