То і я запитаю... Про VPN masquerading etc..
Доброго всім вечора. Щось я трохи заплутався. Help, please. Є роутер з одним зовнішнім ІР (наприклад, 1.1.1.1), який всі запити на 1.1.1.1:443 форвардить на внутрішній Apache2 reverse proxy server (192.168.X1.Y1) , котрий у свою чергу далі розкидає їх по віртуальних серверах (які являють собою CNAME на 1.1.1.1 але крутяться на "фізичних" інстансах 192.168.0.0/16 з докерами-вебсерверами 172.16.0.0/12). Одним із цих докерів є VPN openconnect server, що роздає своїм VPN-клієнтам ІР-адреси 192.168.X3.0/24. Задача - сховати ДЕЯКІ із віртуальних серверів від Інтернета. Тобто, щоби доступ до них був можливим лише з 192.168.0.0/16 та 172.16.0.0/12 Проблема в тому, що, ясний пень, на віртуальні сервери завжди приходить https-запит із src-address proxy-сервера 192.168.X1.Y1 незалежно від того чи запит був ізсередини офісної сітки, чи з Інтернета. Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля). Одним словом, як правильно вирішується дана задача? Куди копати? Наперед дякую. -- Regards, /oleh hrynchuk
Варианты - вешать все acl на самом 192.168.X1.Y1 - на 192.168.X1.Y1 делать ssl offload, дальше передавать plain http (с X-Forwarded-For, X-Forwarded-Proto) Но, не совсем понятно, как работает apache. У него есть https сертификаты всех сайтов? Если да, то дальше и по https можно передать X-Forwarded-For На конечных вебсерверах использовать remoteip_module (apache), mod-rpaf (nginx) и т п
Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля). Так и трафик не в туннеле, если что. По хорошему, нужно еще один честный IP для туннеля. Но, можно сделать свой внутренний DNS для впн-клиентов, который будет для нужных зон отдавать 192.168.X1.Y1 вместо 1.1.1.1.
вт, 12 нояб. 2019 г. в 22:38, Oleh Hrynchuk
Доброго всім вечора.
Щось я трохи заплутався. Help, please.
Є роутер з одним зовнішнім ІР (наприклад, 1.1.1.1), який всі запити на 1.1.1.1:443 форвардить на внутрішній Apache2 reverse proxy server (192.168.X1.Y1) , котрий у свою чергу далі розкидає їх по віртуальних серверах (які являють собою CNAME на 1.1.1.1 але крутяться на "фізичних" інстансах 192.168.0.0/16 з докерами-вебсерверами 172.16.0.0/12).
Одним із цих докерів є VPN openconnect server, що роздає своїм VPN-клієнтам ІР-адреси 192.168.X3.0/24.
Задача - сховати ДЕЯКІ із віртуальних серверів від Інтернета. Тобто, щоби доступ до них був можливим лише з 192.168.0.0/16 та 172.16.0.0/12
Проблема в тому, що, ясний пень, на віртуальні сервери завжди приходить https-запит із src-address proxy-сервера 192.168.X1.Y1 незалежно від того чи запит був ізсередини офісної сітки, чи з Інтернета.
Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля).
Одним словом, як правильно вирішується дана задача? Куди копати?
Наперед дякую.
-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
вт, 12 нояб. 2019 г. в 23:08, Serge Negodyuck
Варианты
- вешать все acl на самом 192.168.X1.Y1 - на 192.168.X1.Y1 делать ssl offload, дальше передавать plain http (с X-Forwarded-For, X-Forwarded-Proto) Но, не совсем понятно, как работает apache. У него есть https сертификаты всех сайтов? Если да, то дальше и по https можно передать X-Forwarded-For На конечных вебсерверах использовать remoteip_module (apache), mod-rpaf (nginx) и т п
точнее, ngx_http_realip_module (nginx).
Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля). Так и трафик не в туннеле, если что. По хорошему, нужно еще один честный IP для туннеля.
Да хоть виртуалку для vpn сервера где-то взять, самую дешевую, с честным ip. Ну и ее связать с основной сеткой. Но, можно сделать свой внутренний DNS для впн-клиентов, который будет для
нужных зон отдавать 192.168.X1.Y1 вместо 1.1.1.1.
вт, 12 нояб. 2019 г. в 22:38, Oleh Hrynchuk
: Доброго всім вечора.
Щось я трохи заплутався. Help, please.
Є роутер з одним зовнішнім ІР (наприклад, 1.1.1.1), який всі запити на 1.1.1.1:443 форвардить на внутрішній Apache2 reverse proxy server (192.168.X1.Y1) , котрий у свою чергу далі розкидає їх по віртуальних серверах (які являють собою CNAME на 1.1.1.1 але крутяться на "фізичних" інстансах 192.168.0.0/16 з докерами-вебсерверами 172.16.0.0/12).
Одним із цих докерів є VPN openconnect server, що роздає своїм VPN-клієнтам ІР-адреси 192.168.X3.0/24.
Задача - сховати ДЕЯКІ із віртуальних серверів від Інтернета. Тобто, щоби доступ до них був можливим лише з 192.168.0.0/16 та 172.16.0.0/12
Проблема в тому, що, ясний пень, на віртуальні сервери завжди приходить https-запит із src-address proxy-сервера 192.168.X1.Y1 незалежно від того чи запит був ізсередини офісної сітки, чи з Інтернета.
Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля).
Одним словом, як правильно вирішується дана задача? Куди копати?
Наперед дякую.
-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
Дякую, Сергію.
Приблизно якось так і думалось.
Особливо з внутр. ДНС.
Стосовно веб-серверів - на деяких стоять чесні сертифікати від Comodo. На
інших - як Бог на душу положить.. а інші - взагалі не підтримують SSL
(форвард на них по http).
вт, 12 лист. 2019 о 23:09 Serge Negodyuck
Варианты
- вешать все acl на самом 192.168.X1.Y1 - на 192.168.X1.Y1 делать ssl offload, дальше передавать plain http (с X-Forwarded-For, X-Forwarded-Proto) Но, не совсем понятно, как работает apache. У него есть https сертификаты всех сайтов? Если да, то дальше и по https можно передать X-Forwarded-For На конечных вебсерверах использовать remoteip_module (apache), mod-rpaf (nginx) и т п
Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля). Так и трафик не в туннеле, если что. По хорошему, нужно еще один честный IP для туннеля. Но, можно сделать свой внутренний DNS для впн-клиентов, который будет для нужных зон отдавать 192.168.X1.Y1 вместо 1.1.1.1.
вт, 12 нояб. 2019 г. в 22:38, Oleh Hrynchuk
: Доброго всім вечора.
Щось я трохи заплутався. Help, please.
Є роутер з одним зовнішнім ІР (наприклад, 1.1.1.1), який всі запити на 1.1.1.1:443 форвардить на внутрішній Apache2 reverse proxy server (192.168.X1.Y1) , котрий у свою чергу далі розкидає їх по віртуальних серверах (які являють собою CNAME на 1.1.1.1 але крутяться на "фізичних" інстансах 192.168.0.0/16 з докерами-вебсерверами 172.16.0.0/12).
Одним із цих докерів є VPN openconnect server, що роздає своїм VPN-клієнтам ІР-адреси 192.168.X3.0/24.
Задача - сховати ДЕЯКІ із віртуальних серверів від Інтернета. Тобто, щоби доступ до них був можливим лише з 192.168.0.0/16 та 172.16.0.0/12
Проблема в тому, що, ясний пень, на віртуальні сервери завжди приходить https-запит із src-address proxy-сервера 192.168.X1.Y1 незалежно від того чи запит був ізсередини офісної сітки, чи з Інтернета.
Окрім всього маскарадинг VPN-клієнтів в їхніх https-запитах не працює, і на Apache proxy завжди прилітає реальний (чесний) src-address VPN-клієнта (в принципі зрозуміло чому - в тунель неможливо засунути маршрут на реальну ІР-адресу дальнього кінця тунеля).
Одним словом, як правильно вирішується дана задача? Куди копати?
Наперед дякую.
-- Regards, /oleh hrynchuk _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-- Regards, /oleh hrynchuk
participants (2)
-
Oleh Hrynchuk
-
Serge Negodyuck