1

У меня была проблема с настройкой проводного к беспроводному мосту на моем Raspberry Pi - но это теперь исправлено - Проводной к беспроводному мосту в Linux - но следствием этого, похоже, является то, что прокси-сервер squid, работавший на коробке, теперь выходит из строя - например, многие вещи истекают как TCP_MISS. (См. Ниже: похоже, это проблема маршрутизации пакетов вне моей сети - соединения внутри моей сети работают нормально)

Как я могу настроить сервер squid снова на работу?

У eth0 нет адреса ip4, у wlan0 нет адреса ip4, у br0 - нет. Но все они имеют IP6-адреса - хотя я не использую IP6.

Я могу использовать ssh для входа в RasPi и из него, и запросы Squid достигают его ...

Обновление: очевидно, у меня есть некоторые проблемы с маршрутизацией. Просто пропинговал внешний адрес из коробки RasPi и пять пингов заняли 80244мс! Пакеты не отброшены, хотя. Моя таблица маршрутизации выглядит совершенно нормально ...

pi@raspberrypi ~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.62.1    0.0.0.0         UG    0      0        0 br0
192.168.62.0    0.0.0.0         255.255.255.0   U     0      0        0 br0

Дальнейшее обновление: у меня нет проблем с маршрутизацией пакетов внутри моей сети, но есть явная большая проблема с пакетами с этой машины, идущими извне.

1 ответ1

0

Вы действительно собираетесь для расширенной настройки здесь. Я предполагаю, что если вы пингуете свой шлюз, 192.168.62.1 вы получаете что-то меньше 20 мс? И пинг 8.8.8.8 (Google) дает вам 80 сек.

Запустить traceroute 8.8.8.8

Ваш первый прыжок должен быть быстрым до 192.168.62.1, второй должен быть к шлюзу вашего провайдера. Traceroute выполняется дольше, чем обычный пинг, так что пусть вас это не беспокоит.

Если ваши первые 2 прыжка отличаются, это может быть сетевой цикл или даже проблема QoS.

Что касается Squid, вы используете прямой или обратный прокси? Обратный прокси-сервер обрабатывает запросы, поступающие на сервер / сеть, перенаправляя их и т.д. Прямой прокси, вероятно, кеширует внешние запросы и регистрирует их и т.д.

Вероятно, нет никаких причин, по которым вы не можете запустить прокси на мосту, но я не думаю, что это когда-либо делалось на практике, потому что мост предназначен для пропускания трафика вслепую, в то время как прокси делает противоположное.

На данный момент IPv6 - это то, что вам не нужно или не нужно. В зависимости от настроек вашего интернет-провайдера и маршрутизатора, он может обеспечивать в основном прямой (без NATAT) доступ к устройствам в вашей сети. Я не думаю, что это вызывает вашу проблему, но если вы ее отключите, это устранит проблему и угрозу безопасности.

На вашем компьютере с Debian echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/disableipv6.conf

Я вижу небольшую проблему с вашей таблицей маршрутизации. У вас могут быть противоречивые показатели. Обычно я думаю, что ваша метрика шлюза должна быть 0, но она также равна 0, я думаю, она должна быть 1 или больше.

Я бы попробовал изменить это. ip route del 192.168.62.0/24 dev br0 proto kernel scope link src 192.168.62.[your ip] metric 0 затем ip route add 192.168.62.0/24 dev br0 proto kernel scope link src 192.168.62.[your ip] metric 2

Затем попробуйте пинг и трассировки снова.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .