Não precisa da descoberta Bonjour para imprimir através de uma VPN
Um payload AirPrint nomeia uma impressora por endereço, caminho e porta, pelo que a descoberta não tem de atravessar o túnel. A rota, essa porta e o TLS continuam a ter de funcionar.
Provavelmente já lhe disseram que imprimir a partir de um iPhone através de uma VPN exige que a descoberta Bonjour atravesse o túnel. Essa crença empurra as pessoas para pontes TAP e repetidores multicast que não corrigem nada. O AirPrint aceita um destino explícito: um perfil de configuração pode dar ao telefone o endereço, o caminho do recurso e a porta de uma impressora. A descoberta nunca precisa de acontecer para essa entrada aparecer na folha de impressão. O que o payload não faz é criar a rota, fazer uma impressora que não é AirPrint falar IPP ou autorizar o trabalho.
O mito começa com uma observação verdadeira
O Bonjour é multicast de ligação local por conceção. Um túnel encaminhado ponto a ponto não transporta esses grupos, pelo que um telefone numa VPN não pode navegar pelas impressoras da LAN remota, e um portátil no mesmo túnel também não. A conclusão correta não é que a impressão precise de uma ponte; é que a navegação precisa de um mecanismo de entrega diferente, e uma lista explícita é esse mecanismo.
Os repetidores multicast existem e algumas redes gerem-nos bem, mas resolvem um requisito de descoberta que pode não ter. Se a implementação só tiver de imprimir num dispositivo aprovado, publicar esse dispositivo é mais pequeno, testável e muito mais fácil de retirar do que estender um domínio de difusão através de um túnel.
O que o payload realmente contém
O payload com.apple.airprint contém uma matriz de dicionários de impressora. Cada dicionário aceita um IPAddress, que pode ser um endereço literal ou um nome de anfitrião, um ResourcePath, uma Port opcional e um ForceTLS opcional. A Apple documenta Port e ForceTLS a partir do iOS 11, pelo que um parque misto tem de esclarecer isso antes da implementação.
O caminho é o campo que as pessoas adivinham. O ResourcePath reflete o valor rp no registo Bonjour da impressora _ipps._tcp ou _ipp._tcp. É frequentemente ipp/print nas impressoras modernas sem controladores e frequentemente específico do fabricante nas mais antigas. Copiar um caminho de outro modelo produz uma fila que aparece e depois recusa cada trabalho.
Um item da matriz tem este aspeto, com valores de substituição que não são um ponto final testado:
<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>
Esse fragmento não é um perfil. É um elemento da matriz AirPrint dentro de um payload, e o payload ainda precisa dos seus próprios metadados, além de assinatura ou entrega por MDM. O dicionário de impressora AirPrint é a referência para os significados dos campos.
Recolha os valores na impressora, não num resultado de pesquisa
Num Mac que já imprime no dispositivo, o ippfind ou o dns-sd -B _ipp._tcp mostra a instância anunciada, e a interface web da própria impressora lista habitualmente o caminho IPP e a porta. Anote os quatro valores na nota de implementação para que a próxima pessoa não tenha de os deduzir outra vez a partir de uma captura de ecrã.
Depois decida sobre o TLS de forma deliberada. Com ForceTLS verdadeiro, o telefone tem de confiar no certificado que a impressora apresenta, e um certificado autoassinado falha a menos que também implemente a âncora de confiança. Desligar o TLS para fazer uma fila funcionar é uma decisão sobre o caminho de rede, não uma alternativa para um certificado inconveniente.
Entrega, e depois duas falhas opostas
Entregue o payload pelo seu canal de gestão de dispositivos onde exista, e trate um perfil instalado manualmente num telefone de trabalho como a exceção que é. Uma vez instalado, a impressora deve aparecer na folha de impressão sem qualquer tráfego de descoberta. Esse aparecimento é a única coisa que o payload devia garantir.
Uma impressora que aparece mas falha em todos os trabalhos tem um problema de rota, porta, caminho ou TLS, e nenhum deles é resolvido pelo payload.
Uma impressora que nunca aparece tem antes um problema de entrega ou de payload: o perfil não foi instalado, a matriz está mal formada ou um valor não corresponde ao dispositivo. Releia os valores e o dispositivo de destino antes de tocar na VPN. Acrescentar um repetidor de descoberta para corrigir um problema de listagem é um erro caro, porque a listagem nunca dependeu da descoberta.
Mantenha a entrada sustentável
Prefira um nome de anfitrião a um endereço literal onde controla a zona, para que uma alteração de endereço não invalide todos os perfis instalados. Esse nome de anfitrião tem de ser resolvido a partir do telefone enquanto o túnel está ativo, o que o devolve à conversa sobre DNS dividido e não à da impressão.
Escreva o proprietário da impressora e o proprietário do perfil no registo de implementação. Quando a fila se deslocar, atualize o destino publicado de propósito, porque uma entrada antiga não expira sozinha e continua a encaminhar os utilizadores para um dispositivo retirado.
Nada disto torna uma impressora compatível com AirPrint. O payload publica um destino, e o dispositivo ainda tem de falar IPP.