Действительно, ответа на QUIC initial нет. Проверено на cloudflare-quic.com и ipv4.google.com
Но на vk.com QUIC не заблокирован
Лечится вот так :
iptables -t mangle -I POSTROUTING -p udp --dport 443 -m mark ! --mark 0x40000000/0x40000000 -m connbytes --connbytes-dir=original --connbytes-mode=packets --connbytes 1:3 -j NFQUEUE --queue-num 205 --queue-bypass
nfqws --qnum=205 ---dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d4
Заодно и проверил работу nfqws на десинхронизацию UDP. Вполне успешно справилось
Как и ожидалось, фильтр не способен вычленить из QUIC имя хоста, поскольку ему пришлось бы применять сложный алгоритм расшифровки. Потому QUIC банится. Вероятно по white list
Так же ожидаемо DPI отстает от потока UDP , если 1-й пакет ему не показался похожим на QUIC. Либо ищется только QUIC initial. Не проверял
UPDATE. Как оказалось, движок QUIC от chromium ловит не только UDP, но и ICMP ttl expired in transit, связанные со своими UDPшками. Они приходят от фейк-пакетов с низким TTL. Как только броузер славливает такой ICMP, сеанс считает порванным, дальше ничего не проходит. Mozilla этим НЕ страдает.
Лечение : либо резать ttl expired in transit (нехорошо, поломаете трейсилки), либо отказаться от ttl fooling и заменить на любой другой, который сработает. Например, badsum.
А можно вообще убрать fooling. В этом случае фейки будут доходить до сервера, но поскольку там трэш, они будут отбрасываться процессом веб сервера.
Но если вы вдруг используете badsum и что-то на пути будет дропать пакеты с badsum (роутеры mediatek, заводские прошивки с linux), то обход не сработает
Проще и надежнее убрать fooling