День добрый!

Давно стоит Сквид в режиме форвардера и все работает но тут появилась задача коннектиться к нему по HTTPS из локалки. При этом использовать самоподписанный сертификат с установкой на машины клиентов. Взял официальное вики https://wiki.squid-cache.org/ConfigExamples и начал настраивать.

Прекрасно работает следующее правило:
https_port 8.8.8.8:64000 tls-cert=/etc/letsencrypt/.../fullchain.pem tls-key=/etc/letsencrypt/.../privkey.pem

А вот это не работает c ошибкой PROXY_CERTIFICATE_INVALID:
https_port 10.10.10.10:64002 tls-cert=/etc/squid/squidCA.pem

В первом случае как вы понимаете letsencrypt а во втором самоподписанный сертификат для работы по IP. Сертификат делал через openssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -extensions v3_ca -keyout myCA.pem -out myCA.pem потом перекинул в .der и установил как корневой на клиенте. В сертификате на всякий случай ЗАПОЛНЕНЫ ВСЕ ПОЛЯ, в т.ч. DN.

Все то же самое но как прозрачный прокси через intercept ssl-bump прекрасно работает, так же все работает если поднимать http_port вместо https_port с теми же настройками но я хочу шифровать как уже говорил и до прокси тоже.

Полный конфиг: https://pastebin.com/Bfwb1a2K Squid 4.6 собранный с SSL на Debian 11.

Что я делаю не так?

День добрый!

Сутки не получается понять что я делаю не так, перечитано все что можно в т.ч. на лоре.

Конфигурация сети следующая:
GW Mikrotik на самой свежей прошивке
WAN: 8.8.8.8, статика, Gpon от МГТС
LAN: 10.10.30.0/24, SNAT локалки
L2TP Server: 10.10.255.1, без шифрования, MTU/MRU 1450

Dedicated на Debian 11 в другой стране
WAN: 9.9.9.9, само собой статика
L2TP Client: 10.10.255.10, без шифрования, MTU/MRU 1450

Задача сделать так чтобы весь траффик (кроме сервисного) хоста 10.10.30.15 полностью шел через удаленный сервер, для этого реализована схема как с двумя WAN провайдерами:

1. На GW метится траффик с хоста:
chain=prerouting action=mark-routing new-routing-mark=redir_route passthrough=no src-address=10.10.30.15 dst-address=!10.10.0.0/16

2. Хост снатится:
chain=srcnat action=src-nat to-addresses=10.10.255.1 src-address=10.10.30.15 out-interface=L2TP

3. Создается маршрут с меткой (привожу всю таблицу маршрутизации):
0 A S 0.0.0.0/0 10.10.255.1 10.10.255.10 1 routing-mark=redir_route
1 ADS 0.0.0.0/0 192.168.1.1 1
4 ADC 10.10.30.0/24 10.10.30.1 Bridge LAN 0
7 ADC 10.10.255.10/32 10.10.255.1 L2TP 0
8 ADC 192.168.1.0/29 192.168.1.2 Eth1 WAN 0

4. На удаленном сервере все это снова снатится:
-A POSTROUTING -s 10.10.255.1 -j SNAT --to-source 9.9.9.9

5. С вот такими маршрутами:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 9.9.9.1 0.0.0.0 UG 0 0 0 eth0
10.10.0.0 10.10.255.1 255.255.0.0 UG 0 0 0 ppp0
10.10.255.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
9.9.9.9 0.0.0.0 255.255.255.192 U 0 0 0 eth0

Результат: крайне долгий коннект с этого особого хоста во внешний мир, скорость закачки с репозитория Debian в районе 20 кбит/с.

Что я проверял и пробовал и вообще: -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu присутствует а так же --set-mss 600/1200 и т.д. тоже пробовал. Все пингуется и трассируется во всех возможных вариантах. Скачивание/закачка по FTP через L2TP туннель отличные. Файрволлы отключались, правила и маршруты проверялись и перепроверялись.

Большие пакеты ходят, без фрагментации вот такие максимум: PING 194.71.11.137 (194.71.11.137) 1422(1450) bytes of data. 1430 bytes from 194.71.11.137: icmp_seq=1 ttl=46 time=84.5 ms С фрагментацией ходят любые.

MTU/MRU туннеля снижал и увеличивал на обеих концах.

Ну и конечно сотня разных перенастроек всего подряд которые даже не вспомню уже, прошу помощи ну или ткнуть носом в очевидный косяк или незнание!