iptables reject-with tcp-reset без флага ACK
Я сталкивался с этим несколько раз на картах micro SD, работающих на различных Raspberry pi - исправление было fsck /dev/sdx -a, где sdx - ваш раздел.
Чтобы отбросить входящие пакеты RST,
iptables -I INPUT -p tcp --tcp-flags ALL RST,ACK --dport 10000 -j DROP
Чтобы отбросить исходящие пакеты RST,
iptables -I OUTPUT -p tcp --tcp-flags ALL RST,ACK --dport 10000 -j DROP
БЮР:
RST/ACK не является подтверждением RST, так же как SYN/ACK не является в точности подтверждением SYN. Установление TCP на самом деле представляет собой четырехсторонний процесс -. :Инициирующий хост отправляет SYN хосту-получателю, который отправляет ACK для этого SYN. Хост-получатель отправляет SYN хосту-инициатору, который отправляет обратно ACK. Это устанавливает связь с отслеживанием состояния.
SYN -->
<-- ACK
<-- SYN
ACK -->
Чтобы сделать это более эффективным, хост-получатель может подтвердить SYN и отправить свой собственный SYN в том же пакете, создавая трехсторонний -процесс, к которому мы привыкли.
SYN -->
<-- SYN/ACK
ACK -->
В случае RST/ACK устройство подтверждает любые данные, отправленные в предыдущем пакете (s )в последовательности, с помощью ACK, а затем уведомляет отправителя о закрытии соединения с помощью RST.. Устройство просто объединяет два пакета в один, как SYN/ACK. RST/ACK обычно не является нормальным ответом при закрытии сеанса TCP, но это также не обязательно указывает на проблему.
Я в Китае, прежде чем сделать "копать +tcp twiter.com @1.1.1.1", Мне нужно сделать 2 строки:
sudo iptables -A INPUT -p tcp -s 1.1.1.1/32 --tcp-flags ALL RST,ACK -j DROP
sudo iptables -A INPUT -p tcp -s 1.1.1.1/32 --tcp-flags ALL RST -j DROP
Тогда я получу правильный ответ:
;; ANSWER SECTION:
twitter.com. 204 IN A 104.244.42.65
Если я выполню только 1-ю команду iptable, моя копка завершится ошибкой:
";; communications error to 1.1.1.1#53: connection reset"
GFW Китая странный.