Como posso redirecionar solicitações HTTP feitas de um iPad?

Já que em um iPad não podemos editar o arquivo hosts (sem jailbreak), como podemos redirecionar arbitrariamente o tráfego da web para outro url?

Isso seria importante para algo como desenvolver um site da Web que usa uma configuração de host virtual onde você deseja redirecionar para uma máquina de desenvolvimento.

(Isso está relacionado a esta pergunta: Posso editar o arquivo host de um iPad? )

A maneira de contornar essa limitação do iPad é usar um servidor proxy HTTP, como o Squid rodando em outra máquina onde você pode editar o arquivo hosts.

No iPad, em Ajustes -> Rede -> Wi-Fi -> (Sua rede) Há uma configuração de proxy HTTP que pode ser definida como manual. Insira suas informações de proxy aqui.

Depois de configurar isso, você poderá manipular o iPad como se estivesse alterando o arquivo hosts.

Descobri que você só precisa modificar as configurações de Wifi em seu iPad para usar o endereço IP de sua máquina de desenvolvimento como um proxy HTTP (conforme explicado no artigo mencionado ):

Dessa forma, basta poder acessar seu aplicativo da web no iPad inserindo a url do host virtual (por exemplo local.mywebapp.com). É fácil e rápido, mas ao contrário da solução de Will Koehler, você não conseguirá acessar a Internet pelo iPad. Mas na maioria das vezes não é realmente um problema, já que você quer apenas testar seu próprio aplicativo.

Configure o arquivo hosts em um computador que executa um servidor proxy, como Fiddler ou Charles, e configure o iPad para usar esse computador como proxy HTTP.

Aqui estão as instruções sobre como fazer isso com o Fiddler: http://conceptdev.blogspot.com/2009/01/monitoring-iphone-web-traffic-with.html

E isso é para Charles: http://www.ravelrumba.com/blog/ipad-http-debugging/

Se você já tem um servidor Apache onde está fazendo desenvolvimento, pode facilmente usá-lo como um proxy de encaminhamento. Isso é particularmente útil para sites WordPress, que realmente gostam de usar o URL absoluto completo.

Exemplo do Ubuntu abaixo:

A primeira etapa é editar o /etc/hostsarquivo em seu servidor de desenvolvimento. Adicione o IP local do servidor, apontando para o seu site.

127.0.0.1 dev.mysite.com

Este arquivo hosts será usado por seu proxy Apache quando ele tentar resolver solicitações de seu iPhone / iPad. Então, vamos configurar a parte do Apache agora ...

Você pode precisar instalar alguns módulos primeiro.

sudo apt-get install libapache2-mod-proxy-html
sudo a2enmod proxy proxy_http proxy_html
sudo apache2ctl graceful

Em seguida, crie um arquivo host virtual, por exemplo /etc/apache2/sites-available/my-proxy

Listen *:8080
<VirtualHost *:8080>
    ProxyRequests On

    <Proxy *>
        Order Deny,Allow
        Deny from all
        Allow from 192.168.1.0/24 
    </Proxy>
</VirtualHost>

Habilite o vhost e reinicie o Apache:

sudo a2ensite my-proxy
sudo apache2ctl graceful

Em seguida, vá para Configurações> Wi-Fi> Sua rede e configure um proxy "Manual". Digite o IP do seu servidor Apache e a porta. É isso aí!

O <Proxy *>bloqueio garante que apenas pessoas em minha rede local possam usar este proxy. Limitar o acesso estritamente é essencial se você estiver usando um proxy de encaminhamento. A página ip2cidr será útil neste ponto. (Como medida extra, a porta: 8080 está bloqueada pelo meu firewall.)

Preciso testar aplicativos da web que estou desenvolvendo em um iPad. Eu uso o Apache na minha máquina de desenvolvimento para executar os aplicativos da web, então a solução mais fácil que encontrei foi usar o mod_proxy Apache.

Minha máquina dev está visível na minha rede doméstica como sapphire.local.

O aplicativo da web que estou testando está hospedado na máquina dev em demo.cms.dev (estou usando POW).

Para configurar o proxy, adicionei a seguinte seção ao httpd.conf.

<VirtualHost *:80>
  ServerName sapphire.local
  ProxyPass / http://demo.cms.dev/
  ProxyPassReverse / http://demo.cms.dev/
  ProxyPassReverseCookieDomain .cms.dev .sapphire.local
  ProxyPreserveHost Off
</VirtualHost>

Isso roteia as solicitações recebidas em sapphire.local para demo.cms.dev. O método funciona apenas para um aplicativo por vez. Acho que você poderia usar portas diferentes para configurar aplicativos adicionais. Talvez alguém tenha uma solução melhor?

Também é possível usar o aplicativo Weblock - AdBlock para iOS (disponível por US $ 1,99 aqui: https://itunes.apple.com/us/app/weblock/id558818638?mt=8 ) para criar redirecionamentos de tráfego da web.

Isso permite que você redirecione qualquer tráfego que corresponda a determinada regra para o endereço IP especificado. Isso emulará a adição de uma entrada em / etc / hosts em seu dispositivo iOS. Se o nome do host definido nas solicitações for gerenciado pelo IP para o qual você direciona o tráfego, você pode usar isso para testar a API privada ou até mesmo farejar o tráfego enviado de outros aplicativos ou sites. Infelizmente, isso funciona apenas para conexões http / https.

Tudo isso só pode ser feito no Wi-Fi (uma das limitações do Weblock). A principal vantagem é que você pode configurar tudo facilmente a partir do seu dispositivo iOS e não há necessidade de mexer na configuração do servidor DNS / proxy.

Aqui está um exemplo:

1. Eu configurei o Weblock assim: http://i.stack.imgur.com/c5SUh.png
2. Abriu o Safari e digitou www.google.com como URL
3. Esta é a saída no terminal do meu Mac ouvindo a conexão na porta 1234:

    macbook-pro-tk: ~ kpr $ nc -l -v -v 1234
    GET http://www.google.com/ HTTP / 1.1
    Host: www.google.com
    Aceitar: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0,8
    Conexão Proxy: keep-alive
    PREF = ID = 7722bc3c844a7c26: TM = 1402073839: LM = 1402073839: S = 5bSJJsM2p0HgUP7L
    Agente do usuário: Mozilla / 5.0 (iPhone; CPU iPhone OS 7_1_1 como Mac OS X) AppleWebKit / 537.51.2 (KHTML, como Gecko) Versão / 7.0 Mobile / 11D201 Safari / 9537.53
    Accept-Language: en-us
    Aceitar-Codificação: gzip, deflate
    Conexão: keep-alive

O Weblock também é bom para redirecionar seletivamente alguns URLs com expressões regulares. Você pode redirecionar as consultas para determinado ponto de extremidade apenas, enquanto todas as outras consultas vão para o IP retornado do DNS. Na verdade, isso permite uma configuração ainda mais adequada que o / etc / hosts.

Exemplo: Se eu criar uma regra de redirecionamento de URL para htt *: //somedomain.com/api/login* e algum IP e porta, verei apenas o tráfego deste URL neste IP e porta, enquanto todo o outro tráfego para algum domínio. com irá diretamente para o IP retornado pelo DNS. Observe que funcionará para / api / login e / api / login? Someparam = somevalue graças ao caractere curinga * no final da regra.

Eu fiz isso usando o Squidman no Mac. É fácil de configurar e usar.
Eu configurei em 5 minutos seguindo este artigo .

Atualizar

Outra coisa é se você deseja se conectar aos sites rodando no servidor proxy, no meu caso é o meu Mac, você precisa comentar esta linha no squidman-> Preferências-> Template

# protect web apps running on the proxy host from external users
# http_access deny to_localhost

Você pode configurar um servidor DNS interno em sua rede (se ainda não houver um) e configurar um registro A. Em seguida, certifique-se de que seu DHCP está configurado para retornar o referido servidor DNS

Você também pode usar http://xip.io/ usando as instruções nessa página, você pode inserir o endereço IP e ele irá redirecioná-lo para o ip local relevante.

Se você tiver um site ativo, poderá usar para isso:

Você pode adicionar um registro A à sua configuração de DNS: alguma coisa.seudominio.com que aponta para o seu endereço IP local e, em seguida, adicionar uma entrada para alguma coisa.seudominio.com ao seu arquivo de hosts virtuais. Reinicie o Apache, coloque seu dispositivo iOS na mesma rede e pronto.

Aqui está um método sem configuração para teste de computador / dispositivo cruzado de um host Mamp Pro Virtual. A única limitação é que você só pode testar um domínio por vez, mas para mim isso é bom quando estou desenvolvendo. No entanto, é realmente simples alternar entre hosts virtuais diretamente no mamp.

Estou executando o mamp pro 2, leão da montanha. A pasta Meus sites contém as pastas de domínio individuais.

Descobri que se você escolher o ip específico do computador local sob o host virtual 'ip / port' e reiniciar o mamp, esse domínio se tornará o domínio padrão ao visualizar o endereço ip dos computadores localhost, ou nome do computador, na rede.

Para fins de teste, isso funciona muito bem em todos os dispositivos da rede, incluindo o iPad. Se você quiser testar outro host virtual, você pode simplesmente retornar a configuração de ip / porta para "*" e então reatribuir outro domínio ao endereço IP do computador e reiniciar.

A vantagem dessa abordagem simples é que você pode fornecer acesso a clientes diretamente para seus sites de desenvolvimento quando você estiver na mesma rede, sem ter que passar por qualquer configuração em sua máquina.

Espero que isso ajude alguém procurando uma solução simples.

O servidor DNS interno é uma opção, mas era muito complicado de implementar. Tentamos instalar o squid como servidor proxy, mas também não funcionou porque estava redirecionando a URL para um novo servidor e esse redirecionamento foi visto na URL do navegador também.

A coisa que finalmente funcionou para nós foi instalar o Fiddler em um dos servidores e usar esse servidor como servidor proxy no ipad. O Fiddler também possui um recurso para mapear subdomínios para endereços IP, ou seja, algo semelhante a / etc / hosts.

Bom tutorial para fazer isso: http://egalo.com/2012/05/29/testing-mac-web-site-using-local-hostname-on-mobile-device/

Outra maneira é conectar o IPad via Hotspot local com meu MAC OS X e estabelecer um encaminhamento de porta para a VM de desenvolvimento. Para conseguir isso, fiz as seguintes etapas:

• no MAC OS X crie um WLAN-Hotspot link como fazer isso
• conecte o iPAD com o Hotspot-WLAN (no iPAD >> Configurações >> WLAN)
• Adicione o ServerAlias ​​à VM de desenvolvimento local (detalhes abaixo)
• estabelecer ssh-portforwarding
  ssh -NL <IP-of-hotspot-host>:<source-port>:<url-to-local-vm>:80 <user-to-vm>
• no navegador do iPADs abra a página com o IP
  <IP-of-hotspot-host>:<source-port>

Onde obter 'IP-of-hotspot-host':

Após a criação do ponto de acesso, há um ponto WLAN nas
configurações do sistema MAC OS X >> Rede >> WLAN

Adicionando o ServerAlias:

Na minha VM de desenvolvimento (Apache2) em /etc/apache2/sites-available/dkr.dev.local , tive que adicionar o seguinte:

<VirtualHost *: 80>  
    ...  
    ServerAlias ​​<IP-of-hotspot-host>  
    ...  
</VirtualHost>

Se você tem explorado isso e alguns dos links externos, provavelmente encontrará esta resposta:

https://stackoverflow.com/a/24770097/3842985

Trata-se de um servidor DNS leve chamado dnsmasq. Super simples, muito poderoso e pode ser usado em conjunto com seus servidores DNS internos ou externos.

Muito mais fácil do que instalar o squid, mexer no Apache e outras técnicas que seriam demoradas e arriscariam a "integridade" das configurações, ambientes de desenvolvimento, ambientes de teste, etc.

Vale a pena considerar.

Eu adotei isso como uma ferramenta regular para desenvolvimento e rede normal.

Usar um servidor DNS personalizado no PC pode resolver isso. Estou usando e funcionando perfeitamente.

Verifique https://technitium.com/dns/ para baixar o servidor DNS personalizado. Que é construído com a tecnologia .Net. Depois de configurar esta ferramenta, você precisa alterar a configuração DNS para personalizado e definir o IP do seu PC. Para evitar alterar o IP sempre que reiniciar o PC, use o IP estático no PC.

Eu tentaria o Relay Server (parte do Afaria), que pode redirecionar o tráfego móvel com base em perfis.

Atualização: a resposta do tremoloqui parece menos problemática e muito mais barata.

As respostas aqui estão corretas. Um pouco mais de conhecimento: não funcionam com pinning de certificados. O que você pode fazer é (1) usar um certificado curinga de domínio para oferecer suporte ao teste de região dev / test / qa. E / ou (2) usar um servidor proxy reverso como o Apache, por meio do qual você muda para onde o Apache roteia as solicitações dentro de sua rede. Agora, quando você entra no teste SSL Pinning, você está morto na água com os dispositivos físicos e só pode validar com simulador (ios) e emulador (Android).