Puncte:0

Redirecționarea pachetelor folosind mai multe servere

drapel in

Am un bloc IP de la RIR.

Folosesc doi furnizori pentru a face anycast către „unele” IP-uri. Voi numi asta A și B.

Vreau să trimit către alt furnizor atunci când acel IP nu este în acea locație. Folosesc două servere Ubuntu pentru a anunța și redirecționa pachetele BGP și o mașină pfSense între furnizorul A și punctul final unicast.

IP-ul anycasted funcționează excelent. Cu toate acestea, dacă clientul este aproape de furnizorul B, acel pachet nu ajunge la punctul final.

Iată cum a fost configurat:

Client --> Furnizor B -(GRE, Rută statică)-> Furnizor A - (GRE, Rută statică)-> pfSense --> Punct final
                                                                             ^ Aici este problema

Problema exactă este că pachetul nu este transmis de la furnizorul A către pfSense. Pot vedea pachetele ICMP la Provider A Server tcpdump, dar nu la pfSense tcpdump. Am permis firewall și nu pot vedea niciun jurnal blocat. Tot traficul de la punctul final care trece prin tunelul GRE care este situat între pfSense și furnizorul A.

Dacă fac ping folosind Provider B Server, nici asta nu funcționează. Cu toate acestea, dacă fac ping cu IP-ul de interfață GRE între furnizorul A, funcționează chiar dacă nu există NAT.

Desigur, pot trimite ping către Endpoint când fac ping lângă furnizorul A.

Ce funcționează (în sine înseamnă server la furnizor):

Client (sau însuși) --> Furnizor A sau B - (GRE, rută statică) -> pfSense - (GRE, rută statică) -> IP Anycast
Client (sau însuși) --> Furnizor A - (GRE, Rută statică) -> pfSense - (GRE, Rută statică) -> IP Unicast la furnizorul A
Furnizor B -(GRE, Rută statică, IP GRE sau aceeași IP de subrețea, excluzând Anycasted)-> pfSense -(GRE, Rută statică)-> IP Unicast la furnizorul A
IP unicast la furnizorul A --> pfSense -(GRE, rută statică)-> Furnizorul A
Furnizorul B --> Server lângă furnizorul B

Ce nu funcționează:

Client (sau însuși) --> Furnizor B -(GRE, Rută statică)-> Furnizor A - (GRE, Rută statică, Trafic se oprește aici)-> pfSense -(GRE, Rută statică)-> IP Unicast la Furnizorul A
IP Unicast la Furnizorul A --> pfSense -(GRE, Rută Statică)-> Furnizorul B --> Server lângă Furnizorul B --> Furnizorul B --> Furnizorul A -(Traficul se oprește aici)-> pfSense --> Punct final

Aici este sysctl -p rezultate:

Furnizorul A
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
Furnizorul B
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

Dacă aveți nevoie de mai multe informații, vă rog să-mi spuneți. Mulțumiri.

Puncte:0
drapel in

Acum S-a rezolvat. După ce am dezactivat rp_filter pe acele gateway-uri, pachetele au fost procesate corect.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.