Я не думаю, что существует решение для крайнего случая как Ваш. Однако хорошие новости - то, что было бы довольно легко записать сценарий Python, который заменит, вставляют правило, которое Вы хотите выше старого и затем удаляете старый.
orchidea 10.0.0.1 /etc/exim % iptables -L -n --line-numbers
Chain RH-Firewall-1-INPUT (2 references)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
Просто вывод синтаксического анализа выше для цепочки и числа правила, говорят 4, сделайте iptables-I цепочка 4 newrule, и затем iptables-D цепочка 5.
Записи в вашем журнале показывают, что файл извлекается после относительно длительного периода времени (951 секунда / 947 секунд), но имеет разную длину (679695 против 2247441 байт), несмотря на идентичный URI , что указывало бы на проблему. Передача может быть прервана через ~ 950 секунд и прервана - возможно, принудительно вышестоящим прокси.
Проверьте, можете ли вы успешно получить файл в разумное время, когда не , используя Squid:
export http_proxy="http://upstream_proxy.internal.domain.tld:8080"
wget http://ftp.fr.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
и работайте оттуда изолируя проблему. tcpdump
передачи между вашим экземпляром прокси-сервера Squid и удаленным прокси-сервером может помочь разоблачить проблемы. Кроме того, если возможно, узнайте возможные причины проблем у администраторов / сотрудников службы технической поддержки используемого вами прокси.