Замкнутая экосистема для перехода на страницу оплаты PayPal.

Полагаю, ты добавил http://www.paypal.com в свою "застенчивую зону". Но сайт PayPal загружает все картинки с http://www.paypalobjects.com, например. Так что тебе тоже нужно это добавить в твою "застенчивую зону". То же самое касается и CSS-файлов. С наилучшими пожеланиями, Christian Meis.

Так у тебя PayPal работает с закрытым hotspot на Mikrotik??? Не поделишься своей настройкой?

Итак, теперь PayPal доступен через закрытую экосистему, но как вы позволяете платежам подтверждать использование интернета?

Я использую freeRadius и веб-сервер для аутентификации пользователей, управления, оплаты и регистрации. Добавил наши серверы в walled garden, проблем не возникло.

Попробовал, но IP не позволяет указывать HTTPS.

У меня та же проблема: не могу заставить работать HTTP-запросы через "застенчивый сад". Для одних клиентов работает, для других - нет. Даже если добавляю IP-адреса, не выходит.

Не против, если поделишься своим обходным решением? И я согласен, там точно есть проблемы… ещё и воспроизвести это сложно.

Итак, после долгих мучений, пытаясь решить эту проблему, я выяснил, в чём дело. Возможно, это объясняет и другие проблемы, с которыми сталкиваются люди. Я несколько раз убедился, что проблема возникает только в версии 2.9, так как 2.8.28 никогда не вызывала такого поведения и работала отлично на этой сети. Моя упрощённая схема (ascii visio?): { Интернет } --- [ https www сервер ]
    |
    |
    |
 172.16.2.4/30
    |
[ DSL-роутер (только маршрутизация, без NAT) ]
    |
 10.0.0.1/29
    |
[MT ROS 2.9 (NAT, с точкой доступа) ]
    |
 192.168.1.1/24
    |
    |
{ клиенты, проводные и беспроводные - в режиме моста } Для этого примера и объяснения необходимо упомянуть следующие IP-адреса: 192.168.1.100 - беспроводной клиент с проблемами 192.168.1.1 - шлюз клиента, IP ether2/точки доступа (с NAT) 10.0.0.2 - WAN на MT (ether1) 10.0.0.1 - LAN на DSL-роутере, шлюз MT. Опять же, проблема заключалась в том, что некоторые люди, включая меня, не могли получить доступ к определённым частям https www сервера, даже после ввода данных в "walled garden", по доменному имени, IP-адресу, портам и протоколам и т.д. - каждой возможной комбинации, включая также добавление этих данных в цепочки пре-точки доступа (которые оказались не такими полезными, как мы надеялись) как в nat, так и в цепочки forward/input. Тем не менее, ничего. Прослушивание пакетов в различных точках только показывает повторные передачи, но ничего больше. Так сегодня я добавил правила логирования между большинством динамических правил точки доступа и обнаружил что-то странное. Когда сессия прекращала работать или начинала с ошибкой, я видел записи в логе. Она начала выдавать отбрасываемые пакеты с адресом источника 10.0.0.1 и адресом назначения 192.168.1.100. Адрес источника - это адрес DSL-роутера. Когда сессия начинается, DSL-роутер не отображается как часть соединения (и не должен). Но в какой-то момент это выходит из строя, и пакеты, кажется, исходят от DSL-роутера, а не от веб-сервера. Как такое возможно? Итак, решение оказалось простым: я добавил IP-адрес DSL-роутера в "walled garden". Теперь всё работает нормально. Это один из BritePort 4200 роутеров, которые использует Covad, с которым у нас никогда не было проблем. Мы протестировали точку доступа 2.8.28 с эквивалентной конфигурацией и не столкнулись с этой проблемой. Мы экспериментировали со всем внутри и снаружи, пытаясь это выяснить, включая настройки conn-track (которые кажутся слишком жёсткими для настроек по умолчанию). Вызвана ли это возможной ошибкой в отслеживании соединения? Есть ли какое-то другое объяснение? Я не смог воспроизвести это дома, где есть DSL-роутер Actiontech (с NAT) с моим тестовым шлюзом внутри. Если кто-нибудь сможет пролить свет на это, это было бы очень признательно… хотя у нас всё работает, мне бы действительно хотелось знать, почему следующий хоп роутер должен быть указан в "walled garden" только для функциональности https "walled garden". В любом случае, я надеюсь, это может помочь другим людям с похожими проблемами.