Squid traffic über spezielles WAN Interface schicken

[Fallaxia]

Hi Leute,

ich suche nach einer Möglichkeit den Squid Traffic über ein spezielles WAN Interface zu leiten.

Dazu habe ich die Squid config entsprechend mit tcp_outgoing_address versehen und die ACLs eingetragen.

Mein Problem: Mit dem Routing komme ich nicht ganz klar. Ich habe:

default via 51.x.y.z dev ens3
51.x.y.z dev ens3 scope link

Das interface ens3:1 soll nun den ausgehenden Squid traffic bekommen. Es hat eine eigene WAN IP

ens3:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

inet 151.x.y.z  netmask 255.255.255.255  broadcast 151.x.y.z

Wie mache ich das am besten?

 

[snaxilian]

Ist auf dem Interface ens3:1 denn ein anderes VLAN oder Subnet als auf ens3:0? Falls da ein anderes Netz ist, kannst doch einfach für das Interface bzw die Adresse eine Route anlegen. Falls 3:0 und 3:1 im selben Netz sind musst du wohl oder übel mit Policy Based Routing arbeiten.
Damit kannst du dann basierend auf dem genutzten Zielport deine Pakete routen.

Ansonsten ist deine "Informationspreisegabe" mehr als dürftig und so kann man nicht wirklich helfen.
Also zeige bitte genaue/bessere Info über das System wo der Squid läuft mit allen Interfaces, wie die konfiguriert sind und welche Router zur Verfügung stehen sowie den Routingtabellen der beteiligten Geräten. Nur so kann man überhaupt deine Situation und Problem nachvollziehen und ggf. eine Lösung finden.

 

[Sun_set_1]

Bin absolut kein Netzwerker. Aber letztens dazu noch was gelesen. War / ist es nicht so, dass Broadcast immer an alle empfängt und sendet? von 0.0.0.0. nach 255.2555.255 und somit theoretisch keine routbare adresse mit gibt.

Ergo müsste der broadcast erstmal an einen dhcp forwarded werden, der den dann nur in seinem sub verteilt, oder sehe ich das anders?

Laut Rob Graham erfolgt keine Verifizierung der Eingangs-IP. Daher wie von @snaxilian geschrieben die policies.

6/ DHCP clients could verify source IP address before parsing packets, but they don't. DHCP has a quirk whereby local routers could be configured to forward local broadcasts to a remote DHCP servers, so responses can come from anywhere.

Oder Du nimmst das dritte Packet und exploitest DHCP, wenn ich Grahams Idee richtig verstehe..

https://twitter.com/ErrataRob/status/1082790132317605888

FYI, my Windows system on my portable Linux based MiFi does this differently... The DHCP ACK is broadcast to the entire subnet, not directed specifically to the IP address just assigned... Which makes more sense if you think about it.

https://twitter.com/mtoecker/status/1083073452314112005

 

[snaxilian]

Was hat das eine denn mit dem anderen zu tun? Squid ist ein Webproxy, wo soll da DHCP und/oder Broadcasts ins Spiel kommen?

 

[Fallaxia]

@snaxilian

Die beiden Interfaces haben unterschiedliche Subnetze, beide mit je einter WAN IP Adresse.
Eines der beiden Interfaces ist ein virtuelles, also ens3:0
Ziel soll sein, dass jedes Interface seinen eigenen Gateway besitzt und Squid beide IPs als "outgoing source address "nutzen kann.

Welche Daten genau interessieren dich?

ifconfig von ens3:

ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 51.x.y.148  netmask 255.255.255.255  broadcast 51.x.y.148
inet6 fe80::f816:3eff:fedb:1e11  prefixlen 64  scopeid 0x20<link>
inet6 2000:db8:302:2000::2fc6  prefixlen 64  scopeid 0x0<global>

und von ens3:0

ens3:0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 151.x.y.235  netmask 255.255.255.255  broadcast 151.x.y.235

ip route:

default via 51.x.y.1 dev ens3
51.x.y.1 dev ens3 scope link
192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.122

 

[mensch183]

Zentral wäre zu wissen, wie der Squid überhaupt arbeiten soll: Als A) Cache für Zugriffe deiner lokalen Clients aufs Internet (d.h. als "proxy") oder B) zum Cachen von Zugriffen aus dem Internet auf lokale Server (d.h. als "reverse proxy")?

Ich hoffe A.

Am nötigen Routing hast du dich (abgesehen von den squid-ACLs, um die Quelladressen zu setzen) ja noch gar nicht probiert. "source-based routing" als eine Spielart des "policy based routing" ist das Stichwort. Du willst abhängig von der Quelladresse der Pakete die Routing-Enscheidung treffen.

Funktioniert denn der squid (abgesehen davon, dass traffic teilweise übers falsche Interface rausgeht) nach Eintragung der tcp_outgoing_address-ACLs ordentlich? Hintergrund: Nennen wir deine beiden WAN-Partner mal ISP1 und ISP2. __OHNE__ irgendwelches "spezialrouting" gehe erstmal alles über ISP1 als default. Du sendest durch die squid-acls aber auch Pakete mit einer Absender-IP aus dem Bereich von ISP2 über ISP1 raus. Wenn ISP1 keine Scharchnase ist, verwirft er diese Pakete. Wenn doch, dürfte dein reinkommender squid-traffic bereits über die jeweils richtigen Interfaces REINkommen und du musst dich nur noch um den RAUSgehenden Teil kümmern.

 

[Raijin]

Squid ist ein Webproxy, wo soll da DHCP und/oder Broadcasts ins Spiel kommen?

Ich vermute mal da hat jemand, der "kein Netzwerker ist" im ersten Beitrag einfach nur die Worte "Routing" sowie im Quote "Broadcast" gelesen und sich daraus selbst ein Thema konstruiert

Wie auch immer, PBR heißt das Zauberwort wie schon angesprochen wurde. Routing erfolgt nun mal stets auf Basis der Ziel-Adresse unabhängig davon woher der Traffic kommt. Will man aber gerade diese Herkunft in das Routing einbeziehen, kommt Policy Based Routing ins Spiel.