Redirect nastane, ak sa uzivatel pripoji na HOST AP, a napise v prehliadaci "google.com", automaticky sa presmetuje na 127.0.0.1:80
Tohle nemá řešení. Teda jedno řešení by to mělo – uživatel by musel použít čerstvě nainstalovaný prohlížeč, jiný než od Google.
Když uživatel zadá do prohlížeče google.com, prohlížeč ví, že tento web má navštěvovat jen přes HTTPS. Takže se vždy bude připojovat protokolem HTTPS na port 443. Vy to spojení sice můžete unést a přesměrovat na libovolný port, ale prohlížeč pořád bude komunikovat protokolem HTTPS, takže i server musí komunikovat přes HTTPS. A první, co takový server musí udělat, je poslat certifikát, který platí pro doménu google.com, a prohlížeč mu bude důvěřovat – a takový certifikát neseženete.
Jediná možnost je použít to, co standardně používají captive portály – když se uživatel (třeba s Androidem) připojí WiFi, systém zkusí oťukat pár adres, které má zadrátované. Zkouší navázat spojení HTTP, a pokud mu tohle spojení přesměrujete správným způsobem, pozná, že jde o captive portál, a zobrazí standardní hlášku, že tato WiFi potřebuje zadat přihlašovací údaje a zda má zobrazit přihlašovací stránku.
Pokud nezafunguje tenhle standardní mechanismus a závisí to na tom, že uživatel musí otevřít nějakou stránku v prohlížeči, musí uživatel zadat adresu, u které si jeho browser určitě nepamatuje, že je dostupná přes HTTPS. Hodí se pro to
http://neverssl.com/, ale tu asi uživatelé běžně znát nebudou.
K tomu přesměrování potřebujete zfalšovat DNS odpověď aby směřovala na váš webový server (předpokládám, že to bude s tou detekcí captive portálů fungovat). Pak nepotřebujete žádný NAT. Takže když se uživatel přihlásí k AP, přes DHCP dostane IP adresu a adresu DNS serveru – a DNS server bude ten váš, který pošle tu zfalšovanou odpověď. Akorát uživatele nepřesměrovávejte na 127.0.0.1, ale na IP adresu, kde běží ten váš webserver.