Hindi mo kailangan ang pagtuklas ng Bonjour para mag-print sa VPN

Malamang sinabihan ka na ang pag-print mula sa iPhone sa VPN ay nangangailangan ng pagtuklas ng Bonjour na tumawid sa tunnel. Ang paniniwalang iyon ay nagtutulak sa mga tao patungo sa mga TAP bridge at multicast relay na walang inaayos. Tumatanggap ang AirPrint ng tahasang destinasyon: maaaring ibigay ng configuration profile sa telepono ang address, path ng resource at port ng isang printer. Hindi kailangang mangyari ang pagtuklas para lumitaw ang entry na iyon sa print sheet. Ang hindi ginagawa ng payload ay lumikha ng ruta, gawing nagsasalita ng IPP ang isang printer na hindi AirPrint, o awtorisahin ang trabaho.

Nagsisimula ang alamat sa isang tunay na obserbasyon

Ang Bonjour ay link-local multicast ayon sa disenyo. Hindi dinadala ng routed point-to-point tunnel ang mga grupong iyon, kaya hindi makakapag-browse ang telepono sa VPN ng mga printer sa malayong LAN, at gayundin ang laptop sa parehong tunnel. Ang tamang konklusyon ay hindi na kailangan ng pag-print ng bridge; ito ay kailangan ng pag-browse ng ibang mekanismo ng paghahatid, at ang tahasang listahan ang mekanismong iyon.

May mga multicast relay at mahusay na pinapamahalaan ng ilang network ang mga ito, ngunit nilulutas nila ang pangangailangan sa pagtuklas na maaaring wala ka. Kung ang deployment ay kailangan lamang mag-print sa isang aprubadong device, ang pag-publish ng device na iyon ay mas maliit, masusubok at mas madaling bawiin kaysa sa pagpapalawak ng broadcast domain sa tunnel.

Ano ang aktwal na dinadala ng payload

Ang payload na com.apple.airprint ay may array ng mga diksyunaryo ng printer. Tumatanggap ang bawat diksyunaryo ng IPAddress, na maaaring literal na address o hostname, isang ResourcePath, opsyonal na Port at opsyonal na ForceTLS. Dokumentado ng Apple ang Port at ForceTLS mula sa iOS 11, kaya kailangang linawin ito ng halo-halong fleet bago ang rollout.

Ang path ang field na hinuhulaan ng mga tao. Sinasalamin ng ResourcePath ang halagang rp sa Bonjour record ng printer na _ipps._tcp o _ipp._tcp. Madalas itong ipp/print sa mga modernong printer na walang driver at madalas na partikular sa vendor sa mas lumang mga printer. Ang pagkopya ng path mula sa ibang modelo ay lumilikha ng queue na lumilitaw at pagkatapos ay tinatanggihan ang bawat trabaho.

Ang isang item sa array ay ganito ang hitsura, na may placeholder na halaga na hindi pa nasubok na endpoint:

<dict>
    <key>ResourcePath</key>
    <string>ipp/print</string>
    <key>IPAddress</key>
    <string>printer-07.office.example</string>
    <key>Port</key>
    <integer>8631</integer>
    <key>ForceTLS</key>
    <true/>
</dict>

Ang fragment na iyon ay hindi profile. Isa itong elemento ng AirPrint array sa loob ng payload, at kailangan pa rin ng payload ang sarili nitong metadata at pirma o paghahatid ng MDM. Ang diksyunaryo ng printer ng AirPrint ang sanggunian para sa mga kahulugan ng field.

Kunin ang mga halaga mula sa printer, hindi mula sa resulta ng paghahanap

Sa Mac na nagpi-print na sa device, ipinapakita ng ippfind o dns-sd -B _ipp._tcp ang inihayag na instance, at karaniwang inililista ng web interface ng printer mismo ang IPP path at port. Isulat ang lahat ng apat na halaga sa tala ng deployment para hindi na kailangang muli silang makuha ng susunod na tao mula sa screenshot.

Pagkatapos ay sadyang magpasya tungkol sa TLS. Kapag totoo ang ForceTLS, kailangang magtiwala ng telepono sa certificate na ipinakikita ng printer, at nabibigo ang self-signed certificate maliban kung ideploy mo rin ang trust anchor. Ang pag-off ng TLS para gumana ang queue ay desisyon tungkol sa network path, hindi ng paikot na paraan para sa abalang certificate.

Paghahatid, pagkatapos ay dalawang magkasalungat na pagkabigo

Ihatid ang payload sa pamamagitan ng iyong channel sa pamamahala ng device kung mayroon, at ituring ang manu-manong naka-install na profile sa work phone bilang ang eksepsiyon na ito nga. Kapag naka-install na, dapat lumitaw ang printer sa print sheet nang walang anumang trapik ng pagtuklas. Ang paglitaw na iyon ang tanging bagay na dapat garantiyahan ng payload.

Ang printer na lumilitaw ngunit nabibigo sa bawat trabaho ay may problema sa ruta, port, path o TLS, at wala sa mga ito ang nalulutas ng payload.

Ang printer na hindi kailanman lumilitaw ay may problema sa paghahatid o payload sa halip: hindi na-install ang profile, mali ang array, o may halagang hindi tugma sa device. Muling basahin ang mga halaga at ang target na device bago hawakan ang VPN. Ang pagdaragdag ng discovery relay para ayusin ang problema sa listahan ay mamahaling pagkakamali, dahil hindi kailanman umasa ang listahan sa pagtuklas.

Panatilihing madaling pamahalaan ang entry

Mas mainam ang hostname kaysa literal na address kung saan kontrolado mo ang zone, para hindi mapawalang-bisa ng pagbabago ng address ang bawat naka-install na profile. Kailangang ma-resolve ang hostname na iyon mula sa telepono habang naka-on ang tunnel, na nagbabalik dito sa usapan tungkol sa split-DNS at hindi sa pag-print.

Isulat ang may-ari ng printer at may-ari ng profile sa talaan ng deployment. Kapag lumipat ang queue, sadyang i-update ang na-publish na destinasyon, dahil ang lumang entry ay hindi mag-e-expire nang mag-isa at patuloy na itinuturo ang mga user sa isang retiradong device.

Wala sa mga ito ang nagpapaging-AirPrint-capable sa isang printer. Nag-publish ang payload ng destinasyon, at kailangan pa ring magsalita ng IPP ang device.