Рейтинг:0

Пересылка пакетов с использованием нескольких серверов

флаг in

У меня есть блокировка IP от RIR.

Я использую двух провайдеров для создания Anycast на «некоторые» IP-адреса. Я буду называть это как A и B.

Я хочу переадресовать другому провайдеру, когда этот IP не находится в этом месте. Я использую два сервера Ubuntu для объявления и пересылки пакетов BGP, а также машину pfSense между провайдером A и конечной точкой одноадресной рассылки.

Anycasted IP отлично работает. Однако, если клиент находится рядом с поставщиком B, этот пакет не достигает конечной точки.

Вот как это настроено:

Клиент --> Провайдер B --(GRE, статический маршрут)-> Провайдер A --(GRE, статический маршрут)-> pfSense --> Конечная точка
                                                                             ^ Вот проблема

Точная проблема заключается в том, что пакет не пересылается от провайдера А к pfSense. Я вижу ICMP-пакеты на сервере Provider A tcpdump, но не на pfSense tcpdump. Я разрешил брандмауэр и не вижу заблокированных журналов. Весь трафик конечной точки, проходящий через туннель GRE, расположенный между pfSense и провайдером A.

Если я выполняю ping с использованием сервера Provider B, это тоже не работает. Однако, если я делаю ping с IP-адресом интерфейса GRE между провайдером A, это работает, даже если нет NAT.

Конечно, я могу пропинговать конечную точку, когда я пропингую рядом с провайдером А.

Что работает (сам значит сервер у провайдера):

Клиент (или сам) --> Провайдер A или B --(GRE, статический маршрут) --> pfSense --(GRE, статический маршрут) --> Anycast IP
Клиент (или сам) --> Provider A --(GRE, статический маршрут) --> pfSense --(GRE, статический маршрут) --> Unicast IP рядом с провайдером A
Провайдер B - (GRE, статический маршрут, IP-адрес GRE или тот же IP-адрес подсети, за исключением Anycasted) -> pfSense - (GRE, статический маршрут) -> IP-адрес Unicast рядом с провайдером A
Одноадресный IP-адрес рядом с провайдером A -> pfSense - (GRE, статический маршрут) -> Provider A
Провайдер Б --> Сервер рядом с Провайдером Б

Что не работает:

Клиент (или сам) --> Провайдер B -- (GRE, статический маршрут) --> Провайдер A -- (GRE, статический маршрут, здесь останавливается трафик) --> pfSense -- (GRE, статический маршрут) --> Одноадресный IP-адрес рядом с провайдером A
Одноадресный IP-адрес рядом с провайдером A --> pfSense --(GRE, статический маршрут)-> Provider B --> Сервер рядом с провайдером B --> Provider B --> Provider A --(Здесь останавливается трафик)-> pfSense --> Конечная точка

Вот sysctl -p Результаты:

Провайдер А
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_ra = 2
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
Провайдер Б
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 1
net.ipv6.conf.all.accept_source_route = 1

Если требуется дополнительная информация, пожалуйста, дайте мне знать. Спасибо.

Рейтинг:0
флаг in

Теперь это разрешено. После того, как я отключил rp_filter на этих шлюзах, пакеты обрабатывались правильно.

Ответить или комментировать

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