iptables/cherrypy redirection change request mid-processing

Question

Извините за неопределенное название, но моя проблема немного сложна для объяснения.

Я написал «портативный портал» для точки доступа WLAN в cherrypy, который является просто сервером, который блокирует MAC-адреса от доступа к Интернету до того, как они зарегистрировались на определенной странице. Для этого я написал некоторые Iptables правила, которые перенаправляют весь HTTP трафик мне

sudo iptables -t mangle -N internet 
sudo iptables -t mangle -A PREROUTING -i $DEV_IN -p tcp -m tcp --dport 80 -j internet 
sudo iptables -t mangle -A internet -j MARK --set-mark 99 
sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -m mark --mark 99 -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1 

(специфика этой установки не очень важно для моего вопроса, просто отметим, что «Интернет» цепь создается которая перенаправляет HTTP к порту 80 в точке доступа)

В порту 80 на AP сервер Cherrypy обслуживает статическую целевую страницу с кнопкой «register», которая выдает запрос POST на http://10.0.0.1/agree. Для того, чтобы обработать этот запрос, я создал метод, как это:

@cherrypy.expose 
def agree(self, **kwargs): 

    #retrieve MAC address of client by checking ARP table 
    ip = cherrypy.request.remote.ip 
    mac = str(os.popen("arp -a " + str(ip) + " | awk '{ print $4 }' ").read()) 
    mac = mac.rstrip('\r\n') 

    #add an iptables rule to whitelist the client, rmtrack to remove previous connection information 
    os.popen("sudo iptables -I internet 1 -t mangle -m mac --mac-source %s -j RETURN" %mac) 
    os.popen("sudo rmtrack %s" %ip) 

    return open('welcome.html') 

Так что этот метод получает MAC-адрес клиента из таблицы агр, а затем добавляет IPtables исключения, чтобы удалить этот конкретный MAC от «Интернета» цепи, перенаправляет трафик на портал.

Теперь, когда я тестирую эту установку, происходит что-то интересное. Добавление исключения в iptables работает - то есть клиент теперь может обращаться к веб-страницам, не перенаправляясь ко мне. Проблема в том, что начальный запрос не попадает на мой сервер, то есть страница welcome.html никогда не открывается - вместо этого, сразу после вызова iptables и rmtrack клиент пытается открыть путь «согласен» на которые они запрашивали до перенаправления на мой портал.

Например, если они попали в «google.com» в адресной строке, затем отправили на мой портал и согласились, теперь они попытаются открыть http://google.com/agree. В результате через некоторое время они получают ошибку. Похоже, что iptables или вызов rmtrack меняют запрос на отправку исходного адресата , а он все еще обрабатывается на моем сервере, что для меня не имеет никакого смысла. Следовательно, не имеет значения, какая статическая страница я возвращаю или какие перенаправления я создаю после того, как эти команды терминала были выпущены - возвращаемое значение моей функции не используется клиентом.

Как я могу исправить эту проблему? Каждый кусок полезной информации ценится.

Answer 1

Сегодня мне удалось решить мою проблему, поэтому я собираюсь принять решение здесь, хотя я сомневаюсь, что в эту проблему много людей.

В принципе, все, что было необходимо, было перенаправлением абсолютного пути где-то во время обработки запроса на невольном сервере портала. Например, в моем случае форма на странице индекса, на которой вы согласились с моим T & C, вызывала действие /agree. Это означало, что клиенту оставалось полагать, что он обращается к этим путям на своем исходном целевом сервере (например, google.com/agree). Используя абсолютную форму 10.0.0.1/agree, клиент будет следовать правильному перенаправлению после вызова iptables.