Jak mogę przekierować żądania HTTP wysyłane z iPada?

Ponieważ na iPadzie nie możemy edytować pliku hosts (bez jailbreakingu), jak możemy arbitralnie przekierować ruch internetowy do innego adresu URL?

Byłoby to ważne w przypadku tworzenia witryny sieci Web korzystającej z konfiguracji hosta wirtualnego, w której chcesz przekierować do maszyny programistycznej.

(Jest to związane z tym pytaniem: czy mogę edytować plik hosta iPada? )

Sposobem na obejście tego ograniczenia iPada jest użycie serwera proxy HTTP, takiego jak Squid działający na innym komputerze, na którym można edytować plik hosts.

Na iPadzie pod Ustawienia -> Sieć -> Wi-Fi -> (Twoja sieć) Istnieje ustawienie serwera proxy HTTP, które można ustawić na ręczne. Wprowadź tutaj informacje o serwerze proxy.

Po skonfigurowaniu będziesz mógł manipulować iPadem, tak jakbyś zmieniał plik hosts.

Zauważyłem, że wystarczy zmodyfikować ustawienia Wi-Fi na iPadzie, aby używać adresu IP komputera programistycznego jako serwera proxy HTTP (jak wyjaśniono we wspomnianym artykule ):

W ten sposób wystarczy mieć dostęp do aplikacji internetowej na iPadzie, wprowadzając adres URL wirtualnego hosta (np local.mywebapp.com.). Jest to łatwe i szybkie, ale w przeciwieństwie do rozwiązania Willa Koehlera nie będziesz mieć dostępu do Internetu z iPada. Ale w większości przypadków nie stanowi to problemu, ponieważ chcesz po prostu przetestować własną aplikację.

Skonfiguruj plik hosts na komputerze z serwerem proxy, takim jak Fiddler lub Charles, i skonfiguruj iPada do używania tego komputera jako serwera proxy HTTP.

Oto instrukcje, jak to zrobić za pomocą programu Fiddler: http://conceptdev.blogspot.com/2009/01/monitoring-iphone-web-traffic-with.html

A to dla Charlesa: http://www.ravelrumba.com/blog/ipad-http-debugging/

Jeśli masz już serwer Apache , na którym robisz programowanie, możesz łatwo użyć go jako serwera proxy do przodu. Jest to szczególnie przydatne w przypadku witryn WordPress, które naprawdę lubią używać pełnego bezwzględnego adresu URL.

Przykład Ubuntu poniżej:

Pierwszym krokiem jest edycja /etc/hostspliku na serwerze deweloperskim. Dodaj lokalny adres IP serwera, wskazujący na Twoją witrynę.

127.0.0.1 dev.mysite.com

Ten plik hostów będzie używany przez serwer proxy Apache podczas próby rozwiązywania żądań z Twojego iPhone'a / iPada. Skonfigurujmy teraz część Apache ...

Może być konieczne wcześniejsze zainstalowanie niektórych modułów.

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

Następnie utwórz na przykład plik hosta wirtualnego /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>

Włącz vhost i zrestartuj Apache:

sudo a2ensite my-proxy
sudo apache2ctl graceful

Następnie przejdź do Ustawienia> Wi-Fi> Twoja sieć i skonfiguruj „Ręczny” serwer proxy. Wprowadź adres IP serwera Apache i port. Otóż ​​to!

Te <Proxy *>, zapewnia blokowe, że tylko ludzie na mojej lokalnej sieci może użyć tego proxy. Ścisłe ograniczenie dostępu jest niezbędne, jeśli używasz przekazującego proxy. W tym momencie pomocna będzie strona ip2cidr . (Jako dodatkowy środek, port: 8080 jest blokowany przez mój firewall).

Muszę przetestować aplikacje internetowe, które tworzę na iPadzie. Używam Apache na mojej maszynie deweloperskiej do uruchamiania aplikacji internetowych, więc najłatwiejszym rozwiązaniem, jakie znalazłem, było użycie Apache mod_proxy.

Moja maszyna deweloperska jest widoczna w mojej sieci domowej jako sapphire.local.

Testowana przeze mnie aplikacja internetowa znajduje się na maszynie deweloperskiej pod adresem demo.cms.dev (używam POW).

Aby ustawić proxy, dodałem następującą sekcję do 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>

To kieruje żądania przychodzące z sapphire.local do demo.cms.dev. Ta metoda działa jednocześnie tylko dla jednej aplikacji. Myślę, że możesz użyć różnych portów do skonfigurowania dodatkowych aplikacji. Może ktoś ma lepsze rozwiązanie?

Możliwe jest również użycie aplikacji Weblock - AdBlock na iOS (dostępna za 1,99 USD tutaj: https://itunes.apple.com/us/app/weblock/id558818638?mt=8 ) do tworzenia przekierowań ruchu internetowego.

Pozwala to na przekierowanie dowolnego ruchu pasującego do określonej reguły na określony adres IP. Spowoduje to emulację dodania wpisu do / etc / hosts na twoim urządzeniu iOS. Jeśli nazwa hosta ustawiona w żądaniach jest obsługiwana przez adres IP, na który kierujesz swój ruch, możesz użyć tego do testowania prywatnego interfejsu API, a nawet podsłuchiwania ruchu wysyłanego z innych aplikacji lub witryn. Działa to niestety tylko dla połączeń http / https.

Wszystko to można zrobić tylko na Wi-Fi (jedno z ograniczeń Weblocka). Główną zaletą jest to, że możesz łatwo skonfigurować wszystko z urządzenia z systemem iOS i nie ma potrzeby mieszania się z konfiguracją serwera DNS / proxy.

Oto przykład:

1. Skonfigurowałem Weblocka w następujący sposób: http://i.stack.imgur.com/c5SUh.png
2. Otworzył Safari i wpisał www.google.com jako adres URL
3. Oto wyjście w terminalu na moim Macu nasłuchującym połączenia na porcie 1234:

    macbook-pro-tk: ~ kpr $ nc -l -v -v 1234
    POBIERZ http://www.google.com/ HTTP / 1.1
    Host: www.google.com
    Zaakceptuj: tekst / html, aplikacja / xhtml + xml, aplikacja / xml; q = 0,9, * / *; q = 0,8
    Proxy-Connection: Keep-Alive
    PREF = ID = 7722bc3c844a7c26: TM = 1402073839: LM = 1402073839: S = 5bSJJsM2p0HgUP7L
    User-Agent: Mozilla / 5.0 (iPhone; CPU iPhone OS 7_1_1 jak Mac OS X) AppleWebKit / 537.51.2 (KHTML, jak Gecko) Wersja / 7.0 Mobile / 11D201 Safari / 9537.53
    Accept-Language: en-us
    Zaakceptuj-kodowanie: gzip, deflate
    Połączenie: utrzymuj przy życiu

Weblock jest również dobry do selektywnego przekierowywania niektórych adresów URL za pomocą wyrażeń regularnych. Możesz przekierowywać zapytania tylko do określonego punktu końcowego, podczas gdy wszystkie inne zapytania trafiają do adresu IP zwróconego z DNS. To faktycznie pozwala na jeszcze bardziej dopasowaną konfigurację niż / etc / hosts.

Przykład: Jeśli utworzę regułę przekierowania adresu URL dla htt *: //somedomain.com/api/login* i jakiegoś adresu IP i portu, zobaczę tylko ruch z tego adresu URL na tym IP i porcie, podczas gdy cały inny ruch do jakiejś domeny. com przejdzie bezpośrednio do adresu IP zwróconego przez DNS. Zauważ, że będzie działać zarówno dla / api / login, jak i / api / login? Someparam = somevalue dzięki znakowi wieloznacznemu * na końcu reguły.

Zrobiłem to za pomocą squidmana na Macu. Jest łatwy w konfiguracji i obsłudze.
Skonfigurowałem to w 5 minut, postępując zgodnie z tym artykułem .

Aktualizacja

Inną rzeczą jest to, że jeśli chcesz połączyć się ze stronami działającymi na serwerze proxy, w moim przypadku jest to mój Mac, musisz skomentować tę linię w squidman-> Preferencje-> Szablon

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

Możesz skonfigurować wewnętrzny serwer DNS w swojej sieci (jeśli jeszcze nie istnieje) i ustawić rekord A. Następnie upewnij się, że serwer DHCP jest ustawiony na zwracanie wspomnianego serwera DNS

Możesz również użyć http://xip.io/, korzystając z instrukcji na tej stronie, możesz wprowadzić adres IP, który przekieruje Cię do odpowiedniego lokalnego adresu IP.

Jeśli masz działającą witrynę internetową, możesz do tego użyć:

Możesz dodać rekord A do swojej konfiguracji DNS: coś.twojadomena.com, który wskazuje na Twój lokalny adres IP, a następnie dodać wpis dla czegoś.twojadomena.com do pliku hostów wirtualnych. Uruchom ponownie Apache, podłącz urządzenie z systemem iOS do tej samej sieci i gotowe.

Tutaj nie ma metody konfiguracji do testowania między urządzeniem / komputerem hosta wirtualnego Mamp Pro. Jedynym ograniczeniem jest to, że możesz testować tylko jedną domenę naraz, ale dla mnie jest to w porządku, gdy tworzę. Jednak zmiana wirtualnych hostów bezpośrednio w mampie jest naprawdę prosta.

Jestem Running Mamp Pro 2, Mountain Lion. Folder Moje witryny zawiera poszczególne foldery domeny.

Znalazłem, jeśli wybierzesz określony adres IP komputera lokalnego pod wirtualnym hostem „ip / port” i zrestartujesz, a ta domena stanie się domeną domyślną podczas przeglądania adresu IP komputera lokalnego hosta lub nazwy komputera w sieci.

Do celów testowych działa to świetnie na wszystkich urządzeniach w sieci, w tym na iPadzie. Jeśli chcesz przetestować innego wirtualnego hosta, możesz po prostu przywrócić konfigurację IP / port na „*”, a następnie ponownie przypisać inną domenę do adresu IP komputera i ponownie uruchomić.

Zaletą tego prostego podejścia jest to, że możesz zapewnić klientom dostęp bezpośrednio do witryn programistycznych, gdy jesteś w tej samej sieci, bez konieczności przeprowadzania jakiejkolwiek konfiguracji na ich komputerze.

Mam nadzieję, że pomoże to każdemu, kto szuka prostego rozwiązania.

Wewnętrzny serwer DNS jest jedną z opcji, ale jego implementacja była zbyt kłopotliwa. Próbowaliśmy zainstalować squid jako serwer proxy, ale to również nie działało, ponieważ przekierowywał adres URL na nowy serwer, a to przekierowanie było również widoczne w adresie URL przeglądarki.

Ostatecznie udało nam się zainstalować Fiddlera na jednym z serwerów i użyć tego serwera jako serwera proxy na iPadzie. Fiddler ma również funkcję mapowania subdomen na adres IP, czyli coś podobnego do / etc / hosts.

Niezły poradnik, jak to zrobić: http://egalo.com/2012/05/29/testing-mac-web-site-using-local-hostname-on-mobile-device/

Innym sposobem jest połączenie iPada przez lokalny hotspot z moim MAC OS X i ustanowienie przekierowania portów do rozwijającej się maszyny wirtualnej. Aby to osiągnąć, wykonałem następujące kroki:

• w systemie Mac OS X utwórz łącze WLAN-Hotspot, jak to zrobić
• podłącz iPAD do Hotspot-WLAN (na iPAD >> Ustawienia >> WLAN)
• Dodaj ServerAlias ​​do lokalnej maszyny wirtualnej deweloperskiej (szczegóły poniżej)
• ustanowić ssh-portforwarding
  ssh -NL <IP-of-hotspot-host>:<source-port>:<url-to-local-vm>:80 <user-to-vm>
• w przeglądarce iPADów otwórz stronę z adresem IP
  <IP-of-hotspot-host>:<source-port>

Skąd wziąć „IP-of-hotspot-host”:

Po utworzeniu hotspotu w
ustawieniach systemu MAC OS X >> Network >> WLAN znajduje się punkt WLAN

Dodawanie ServerAlias:

Na mojej wirtualnej maszynie deweloperskiej (Apache2) w /etc/apache2/sites-available/dkr.dev.local musiałem dodać:

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

Jeśli badałeś to i kilka linków zewnętrznych, prawdopodobnie znajdziesz tę odpowiedź:

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

Chodzi o lekki serwer DNS o nazwie dnsmasq. Super prosty, bardzo wydajny i może być używany w połączeniu z wewnętrznymi lub zewnętrznymi serwerami DNS.

Znacznie łatwiejsze niż instalacja squid, majstrowanie przy Apache i innych technikach, które byłyby czasochłonne i ryzykowałyby „integralność” konfiguracji, środowisk programistycznych, środowisk testowych itp.

Warto to rozważyć.

Przyjąłem to jako zwykłe narzędzie do programowania i normalnej sieci.

Użycie niestandardowego serwera DNS na komputerze może rozwiązać ten problem. Używam i działam doskonale.

Sprawdź https://technitium.com/dns/, aby pobrać niestandardowy serwer DNS. Który jest zbudowany przy użyciu technologii .Net. Po skonfigurowaniu tego narzędzia musisz zmienić ustawienie DNS na niestandardowe i ustawić adres IP komputera. Aby uniknąć zmiany adresu IP za każdym razem, gdy ponownie uruchamiasz komputer, użyj statycznego adresu IP na komputerze.

Chciałbym wypróbować serwer Relay (część Afaria), który może przekierować ruch mobilny na podstawie profili.

Aktualizacja: odpowiedź tremoloqui wydaje się mniej kłopotliwa i znacznie tańsza.

Odpowiedzi tutaj są prawidłowe. Trochę więcej wiedzy: nie będą działać z przypinaniem certyfikatów. Możesz albo (1) użyć certyfikatu wieloznacznego domeny do obsługi testów regionu dev / test / qa. I / lub (2) użyj odwrotnego serwera proxy, takiego jak Apache, w którym zmieniasz miejsce, do którego Apache kieruje żądania w Twojej sieci. Teraz, kiedy przejdziesz do testowania przypinania SSL, jesteś martwy w wodzie z urządzeniami fizycznymi i możesz zweryfikować tylko za pomocą symulatora (iOS) i emulatora (Android).