Ang iyong VPN gateway ay kailangan pa rin ng paraan upang mag-install ng mga update

Gumagana ang tunnel para sa lahat ng nasa likod nito, ipinapasa ng gateway ang kanilang trapiko, ngunit ang makina mismo ay hindi makapag-install ng update sa seguridad. Ito ang karaniwang hugis ng problema: binigyan ng pahintulot sa pagpapasa ang mga kliyente, at ang sariling papalabas na koneksyon ng gateway ay hindi kailanman isinama sa plano. Binubuksan ng manager ng pakete ang sarili nitong mga socket, mula sa gateway, patungo sa isang repository na malamang ay hindi mo pinangalanan kahit saan sa patakaran ng firewall.

Tama ang pag-lock down ng isang gateway. Ang pag-lock dito nang lubusan hanggang sa tumigil ito sa pagtanggap ng mga patch ay ibang desisyon, at karaniwang aksidente.

Ang lokal na output ay hindi pagpapasa ng kliyente

Pinamamahalaan ng mga tuntunin sa pagpapasa ang mga paketeng dumarating mula sa ibang lugar at lumalabas sa gateway. Ang sariling trapiko ng update ng gateway ay hindi kailanman tumutugma sa mga ito; ito ay nabubuo nang lokal at dumadaan sa daanan ng output. Ang pagkakaibang iyon ang nagpapaliwanag ng pagkabigo na tila imposible habang perpektong gumagana ang access ng mga kliyente.

Ipinapaliwanag din nito ang puwang sa patakaran na nakakalampas sa mga pagsubok, dahil ang mabilis na pagsusuri mula sa laptop sa likod ng tunnel ay nagpapatunay na gumagana ang kadena ng pagpapasa at walang sinasabi tungkol sa sariling mga koneksyon ng host. Ituring ang gateway bilang dalawang paksa: isang router na may kadena ng pagpapasa at isang host na may kadena ng output. Kailangan ng opinyon ang dalawa, at karaniwang isa lang ang naisusulat.

Pangalanan ang yugtong nabigo

Ang mga error sa update ay nagpapangalan ng magkakaibang hangganan, at ang pagsunggab sa tuntunin ng port bago basahin kung alin ang nabigo ay kumakain ng isang hapon. Ang pangalan ng repository na hindi maresolba ay tanong ng resolver, hindi tanong ng transport.

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

Ang timeout pagkatapos ng matagumpay na paghahanap ay naglilipat ng tanong sa transport: aling address, aling port at aling naka-configure na proxy ang aktwal na sinubukan ng manager ng pakete. Ang pagkabigo ng pagpapatunay ng TLS ay pangatlo, ganap na ibang bagay, at nangangahulugan ito na gumana ang koneksyon nang sapat upang makipag-ayos. Ang reklamo sa pagpapatunay ng archive ay ang ikaapat na yugto, at may kinalaman ito sa mga nilagdaang metadata sa halip na maabot. Apat na yugto, apat na magkakaibang pagkukumpuni, at ang ping ay palaging naglalarawan lamang ng isang protocol na hindi ginagamit ng anumang manager ng pakete.

Basahin ang listahan ng source bago magdagdag ng tuntunin

Ilista ang aktwal na mga URI ng source at ang epektibong configuration ng proxy, hindi ang mga natatandaan mo. Ang tuntuning isinulat para sa simpleng HTTP ay walang silbi kapag ang source ay HTTPS, at ang proxy na kilala ng shell ay maaaring hindi makita ng serbisyong sinimulan sa boot na may ibang environment.

Ang dokumentasyon ng transport na HTTP sa APT ay sumasaklaw sa mga setting ng proxy ng environment at mga partikular sa APT, kabilang ang mga pagpipilian kada host, at ang HTTPS transport nito ay may sariling mga setting ng pagpapatunay. Ang daan ng browser at ang daan ng manager ng pakete ay magkahiwalay na daan, kahit sa parehong makina.

Pansinin kung aling mga pamilya ng address ang nire-resolba ng mga source. Ang tuntuning nagpapahintulot lamang sa IPv4 ay patuloy na mabibigo sa isang host na ang mga source ay mas gusto ang AAAA record, at ang error ay mukhang pabago-bago dahil nakadepende ito sa kung aling sagot ang unang dumarating.

Pumili ng isang daanan ng pagpapanatili at manatili roon

May tatlong mapagtatanggol na opsyon: trapiko ng pagpapanatili sa tunnel, sa pamamagitan ng pinamamahalaang proxy ng update, o sa pamamagitan ng makitid na direktang pagbubukod. Pumili ng isa nang sinasadya at gawing sumasang-ayon ang resolver, dahil ang paghahati kung saan ang mga pangalan ay nire-resolba sa isang direksyon at ang mga koneksyon ay pumupunta sa iba ay lumilikha ng mga pagkabigong walang makapagpapaliwanag.

Anuman ang piliin mo, hindi ito dapat maging walang limitasyong fallback. Kung ipinagbabawal ang direktang papalabas na trapiko kapag patay ang tunnel, ang pagbubukod sa pagpapanatili na tahimik na nagpapahintulot sa lahat ay pagbabago ng patakaran na nagkukunwaring pag-aayos. Itago ang sariling endpoint ng tunnel at ang mga pangangailangan sa bootstrap sa hiwalay na kategorya mula sa access sa repository, dahil tumuturo ang mga ito sa magkakaibang destinasyon at nabibigo sa magkakaibang paraan, kaya hindi masasakop ng isang exemption ang isa pa.

I-verify nang hindi pinapahina ang mga pagsusuri

Ilapat ang saklaw sa pamamagitan ng firewall na mayroon nang patakaran, sa halip na magdagdag ng pangalawang manager dahil ginamit ito ng isang gabay. Pagkatapos ay patakbuhin ang pag-refresh ng metadata at isang tunay na transaksyon ng pakete sa ilalim ng pinapanatiling patakaran, at basahin ang output sa halip na ang exit status lamang.

Ang matagumpay na transport ay hindi pahintulot na luwagan ang pagpapatunay. Ang pagpapatunay ng archive at ang pagkakakilanlan ng TLS server ay magkahiwalay na garantiya, at ang pag-disable ng alinman sa mga ito upang patahimikin ang isang error ay nagbabago ng pinagkakatiwalaan mo, hindi ng maaabot mo.

Tapusin sa sinadyang pagsubok sa kaso na walang tunnel. Ang malaman kung paano kumilos ang gateway na wala ang tunnel nito ay bahagi ng disenyo, ang matuklasan ito sa panahon ng pagkaantala ay hindi. Ibaba ang tunnel, patakbuhin ang pag-refresh ng metadata at tiyakin na nabibigo ang host sa paraang nilayon mo sa halip na tahimik na bumalik sa bukas na daan. Itago ang mga kredensyal ng repository at proxy mula sa mga ibinahaging diagnostic, at mag-iwan ng tala na nagsasabi kung sino ang may-ari ng daanan ng update.