nfqws QUIC ipfrag2 about zapret

[bol-van]

ipfrag вообще большая боль. фактически он работает только для конкретных целей типа wireguard на своей VPSке, если по пути не порежут. для общего обхода не годится, поскольку сеть враждебна к ip фрагментам. не любит она их.

еще есть проблема с атакой ipfrag на проходящий пакет (forward) , когда используется masquerade.
по идее надо делать так. хватаемся с очень низким приоритетом (predefrag) на output, чтобы до conntrack пометить генеренные в nfqws пакеты как notrack. тогда их conntrack трогать не будет.
НО поскольку генеренный пакет - первый в сеансе, то в conntrack таблице еще нет информации о сеансе.
окей, сгенеренный пакет уходит. в ответ что-то приходит. и создается запись conntrack на основании вошедшего пакета. получается ломается NAT
этой проблемы нет, когда NAT не задействуется. например, в случае исходящего трафика с самой системы

в последней версии добавил переменную POSTNAT_ALL. если ее установить в 1, например в config, то схема nftables переключается на вариант обработки после nat, но в этом случае могут ломаться проходящие атаки на udp
зато нет проблем с bind_fix

[bol-van]

ipfrag не будет работать при POSTNAT_ALL=0, потому что NAT не сможет заменить source address на инетовский

[bol-van]

Фрагменты имеется в виду что ? ipfrag или split ?

[bol-van]

Скрипты zapret хватают пакеты еще до srcnat

 chain postrouting {
                type filter hook postrouting priority srcnat - 1; policy accept;
......
}

nfqws получает пакеты с локальным IP и отправляет их так же. это нормально.
masquerade работает уже после , как с пропущенными через очередь оригиналами, так и с отправленными nfqws пакетами через raw socket

если адрес после masquerade сохранился, значит пакеты не были обработаны, возможно по какой-то причине свалились в состояние conntrack INVALID. но правила fw4 такое должны отсекать и не пропускать

по поводу ipfrag там вообще отдельная песня. скрипты zapret не поддерживают его использование. только ручками

[AlexeiGHub]

ipfrag

ipfrag2

[AlexeiGHub]

если адрес после masquerade сохранился, значит пакеты не были обработаны, возможно по какой-то причине свалились в состояние conntrack INVALID. но правила fw4 такое должны отсекать и не пропускать

Так и есть, я отключил прибивание conntrack INVALID, иначе rawsend: sendto: Operation not permitted

Как найти причины #свалиливания в состояние conntrack INVALID?

[AlexeiGHub]

И в коде
`
if (!ip_frag(pkt_orig, pkt_orig_len, ipfrag_pos, ident, pkt1, &pkt1_len, pkt2, &pkt2_len))
return res;

				DLOG("sending 1st ip fragment 0-%zu len=%zu : ", ipfrag_pos-1, ipfrag_pos)
				hexdump_limited_dlog(pkt1,pkt1_len,IP_MAXDUMP); DLOG("\n")
				if (!rawsend((struct sockaddr *)&dst, desync_fwmark, ifout , pkt2, pkt2_len))
					return res;

				DLOG("sending 2nd ip fragment %zu-%zu len=%zu : ", ipfrag_pos, len_transport-1, len_transport-ipfrag_pos)
				hexdump_limited_dlog(pkt2,pkt2_len,IP_MAXDUMP); DLOG("\n")
				if (!rawsend((struct sockaddr *)&dst, desync_fwmark, ifout , pkt1, pkt1_len))

`

порядок отправки перепутан специально?

[AlexeiGHub]

Проверьте корректность работы при POSTNAT_ALL=0