Puncte:0

Server

Funcționează multi gateway cu HAProxy și VPN?

user1352470

07.07.2023, 04:07

Avem o situație în care vom avea în rețea două gateway-uri fizice de router, fiecare conectat la propriul ISP. Din cauza cerințelor de afaceri, nu putem îmbina cele două WAN-uri pe un singur router, prin urmare trebuie să existe două routere.

Dorim ca utilizatorii noștri de la distanță să poată accesa VPN, fie prin WAN/Router, și să poată accesa serverul web intern. Cu diagrama de mai jos, știu că utilizatorul de la distanță va trebui să aibă două configurații separate de aplicație/profil/cont VPN, una pentru WAN/Router și asta nu este o problemă.

Diagrama de mai jos ar face ceea ce caut? Ideea generală de mai jos este să configurați un HAProxy, să setați gateway-ul implicit al tuturor dispozitivelor să indice către HAProxy și ca HAProxy să se ocupe de conexiunile la routere. Din păcate, sunt destul de nou în această chestiune cu proxy și nu sunt sigur dacă HAProxy ar face ceea ce caut.

Configurare propusă:

Ca informație, mai jos arată ce avem în prezent, toate gateway-urile dispozitivelor indică către Router Gateway 1. Problema este că atunci când utilizatorii de la distanță VPN prin WAN-XYZ, în Router Gateway 2, nu par să acceseze serverul web intern. . După înțelegerea mea, această problemă se datorează faptului că gateway-ul implicit de pe serverul web intern este setat la Router Gateway 1.

Configurare curentă:

Note suplimentare Routerul 2 va fi un router pfSense.

98

0 + 0

pfsens

Tom Yan

07.07.2023, 05:34

Nu sunt familiarizat cu echilibrarea haproxy / încărcare, dar primul meu gând despre scenariul dvs. este că ceea ce aveți nevoie pare să fie ceva precum setarea marcajului de conntrack pe baza adresei sursei L2 și setarea fwmark (care va fi potrivită de o regulă ip) pentru corespondență. traficurile de răspuns și ar trebui să fie configurate direct pe gazda serverului. Nu am implementat niciodată o astfel de configurație de „rutare divizată”, dar cred că este posibil cu nftables pe Linux (deci nu am idee dacă serverul tău web are Windows sau BSD).

0

Răspunde

Zac67

07.07.2023, 06:37

Nu sunt sigur despre un router pfSense, dar cu un router decent ar trebui să mutați routerele ISP din rețeaua „plată” și să puneți routerul între ele și LAN. Un router decent ar trebui să poată returna traficul înapoi la ISP-ul de unde a provenit (pentru conexiunile de intrare) și să ofere o anumită formă de echilibrare a sarcinii (pentru conexiunile de ieșire). De asemenea, rutarea bazată pe politici bazată pe protocol sau pe adresa IP sursă ar putea funcționa bine. Toate acestea ar trebui să funcționeze fără un proxy (ceea ce ar putea fi o durere majoră).

0

Răspunde

Tom Yan

07.07.2023, 11:06

Btw, cu excepția cazului în care puteți face routerele dvs. ISP să execute *sursă* NAT pentru traficul de pe *Internet*, nu cred că un proxy are sens/contează, deoarece în cele din urmă va trebui să „împartă traseul” *răspunsurilor* pe baza adresa *MAC* sursă a traficurilor *originale*. Proxy-ul poate redirecționa răspunsurile către routerele corespunzătoare numai dacă adresa *IP-ul de destinație* a răspunsurilor poate *indica* ruterul la care ar trebui să meargă, ceea ce se întâmplă numai dacă ruterele ISP pot fi configurate pentru a efectua acest tip de sursă ciudată. NAT. (În plus, nu este scalabil/realist să te mascați pentru Internet.)

0

Răspunde

Puncte:0

Server

Tom Yan

07.07.2023, 09:48

Tocmai v-am simulat scenariul/nevoia cu trei VM-uri și două punți (independente) pe o gazdă VM și am formulat/testat o soluție (ceea ce am menționat în comentariul meu) pentru aceasta.

Gazda VM acţionează ca server web, iar două dintre VM acţionează ca routere, unul dintre VM acţionează ca un client web de pe „Internet”:

Configurații pe gazda VM (server web):

$ ip a show dev bridge1
4: bridge1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3a:f6:7b:90:aa:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.254.3/24 scope global bridge1
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
    inet6 fe80::38f6:7bff:fe90:aabd/64 scope link 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

$ ip a show dev bridge2
5: bridge2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1a:6f:58:86:72:55 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::186f:58ff:fe86:7255/64 scope link 
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

(pod1 este folosit pentru simularea rețelei LAN și pod2 este folosit pentru simularea „Internetului”, astfel că acestuia din urmă nu i se atribuie o adresă IPv4.)

regula $ ip
0: din toate căutările locale
32765: din toate fwmark 0xb iif se caută 11
32766: din toate căutările principale
32767: din toate căutările implicite

$ ip r arată tabelul principal dev bridge1
10.10.10.0/24 prin 192.168.254.1 
192.168.254.0/24 proto kernel scope link src 192.168.254.3 

$ ip r arată tabelul 11
10.10.10.0/24 prin 192.168.254.2 dev bridge1

(Aici 192.168.254.1 se presupune că este gateway-ul implicit „primar”. dacă iată este o rafinare care face ca regula să fie aplicată numai asupra traficurilor care provin de la gazdă în sine, cu alte cuvinte, probabil că este inutilă, cu excepția cazului în care gazda serverului web acționează și ca un fel de router.)

$ sudo nft listă set de reguli
table ip mangle {
    intrare în lanț {
        tip filtru cârlig intrare prioritate mangle; acceptarea politicii;
        eter saddr 52:54:00:bb:bb:bb ip saddr != 192.168.254.2 ct mark set 0x0000000b
    }

    ieșire în lanț {
        tip route hook output priority mangle; acceptarea politicii;
        marcaj ct 0x0000000b marcaj meta set marcaj ct
    }
}

(Aparent tip trebuie sa fie traseu în ieșire cârlig lanț pentru ca aceasta să funcționeze. De asemenea, traficurile provenite de la routere, spre deosebire de traficurile provenite din „Internet”, pot fi diferențiate în funcție de adresele lor IP sursă, deci ip saddr != 192.168.254.2 este specificat pentru a indica faptul; în realitate este probabil un rafinament inutil.)

Iată tcpdump captura pe gazda VM / serverul web a celor doi răsuci rulați finalizat pe VM-ul client web:

$ sudo tcpdump -eni bridge1 tcp port 80
tcpdump: ieșire verbosă suprimată, utilizați -v[v]... pentru decodarea completă a protocolului
ascultare pe bridge1, tip link EN10MB (Ethernet), lungime instantanee 262144 octeți
16:54:43.602105 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 74: 10.10.10.3.33132 > 198.25.43:16 Steaguri [S], seq 2320058647, win 64240, opțiuni [mss 1460,sackOK,TS val 3412464375 ecr 0,nop,wscale 7], lungime 0
16:54:43.602185 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), lungime 74: 192.168.254.3.80 > 10.3:13.3. Steaguri [S.], seq 3987984937, ack 2320058648, win 65160, opțiuni [mss 1460,sackOK,TS val 3768307023 ecr 3412464375,nop,wscale 7]
16:54:43.603460 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.33132 > 198.25.43:16 Steaguri [.], confirmare 1, câștig 502, opțiuni [nop,nop,TS val 3412464377 ecr 3768307023], lungime 0
16:54:43.604003 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 140: 10.10.10.3.33132 > 198.20:41. Steaguri [P.], seq 1:75, ack 1, win 502, opțiuni [nop,nop,TS val 3412464377 ecr 3768307023], lungime 74: HTTP: GET / HTTP/1.1
16:54:43.604054 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), lungime 66: 192.168.254.3.80 > 10.3:13.3. Steaguri [.], confirmare 75, câștig 509, opțiuni [nop,nop,TS val 3768307025 ecr 3412464377], lungime 0
16:54:43.604238 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), lungime 329: 192.168.254.3.80 > 103.3.103.10.3. Indicatori [P.], secv. 1:264, confirmare 75, câștig 509, opțiuni [nop,nop,TS val 3768307025 ecr 3412464377], lungime 263: HTTP: HTTP/1.1 200 OK
16:54:43.604636 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.33132 > 198.25.43:16 Steaguri [.], ack 264, win 501, opțiuni [nop,nop,TS val 3412464378 ecr 3768307025], lungime 0
16:54:43.605112 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.33132 > 198.25.43:16 Steaguri [F.], secv 75, ack 264, win 501, opțiuni [nop,nop,TS val 3412464379 ecr 3768307025], lungime 0
16:54:43.605133 3a:f6:7b:90:aa:bd > 52:54:00:aa:aa:aa, ethertype IPv4 (0x0800), lungime 66: 192.168.254.3.80 > 10.3:13.3. Steaguri [F.], secv 264, ack 76, win 509, opțiuni [nop,nop,TS val 3768307026 ecr 3412464379], lungime 0
16:54:43.605270 52:54:00:aa:aa:aa > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.33132 > 198.25.43:16 Steaguri [.], ack 265, win 501, opțiuni [nop,nop,TS val 3412464379 ecr 3768307026], lungime 0

16:54:47.528893 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 74: 10.10.10.3.49270 > 192.16.3825:168.82 Steaguri [S], seq 1866708541, win 64240, opțiuni [mss 1460,sackOK,TS val 1196345946 ecr 0,nop,wscale 7], lungime 0
16:54:47.528977 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), lungime 74: 192.168.254.3.80 > 10.10.4920.3:492. Steaguri [S.], seq 1756841838, ack 1866708542, win 65160, opțiuni [mss 1460,sackOK,TS val 3768310949 ecr 1196345946,nop,wscale 7]
16:54:47.530210 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.49270 > 192.16.3.825:168.82 Steaguri [.], confirmare 1, câștig 502, opțiuni [nop,nop,TS val 1196345947 ecr 3768310949], lungime 0
16:54:47.530535 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 140: 10.10.10.3.49270 > 192.4.16.38. Steaguri [P.], seq 1:75, ack 1, win 502, opțiuni [nop,nop,TS val 1196345948 ecr 3768310949], lungime 74: HTTP: GET / HTTP/1.1
16:54:47.530588 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), lungime 66: 192.168.254.3.80 > 10.10.4920.3:492. Steaguri [.], ack 75, win 509, opțiuni [nop,nop,TS val 3768310951 ecr 1196345948], lungime 0
16:54:47.530744 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), lungime 329: 192.168.254.3.80 > 10.3:10.492 Steaguri [P.], secv 1:264, ack 75, win 509, opțiuni [nop,nop,TS val 3768310951 ecr 1196345948], lungime 263: HTTP: HTTP/1.1 200 OK
16:54:47.531434 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.49270 > 192.16.380. Steaguri [.], ack 264, win 501, opțiuni [nop,nop,TS val 1196345949 ecr 3768310951], lungime 0
16:54:47.532994 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.49270 > 192.16.3825:168.82 Steaguri [F.], secv 75, ack 264, win 501, opțiuni [nop,nop,TS val 1196345951 ecr 3768310951], lungime 0
16:54:47.533092 3a:f6:7b:90:aa:bd > 52:54:00:bb:bb:bb, ethertype IPv4 (0x0800), lungime 66: 192.168.254.3.80 > 10.10.4920.3:492. Steaguri [F.], secv 264, ack 76, win 509, opțiuni [nop,nop,TS val 3768310954 ecr 1196345951], lungime 0
16:54:47.533925 52:54:00:bb:bb:bb > 3a:f6:7b:90:aa:bd, ethertype IPv4 (0x0800), lungime 66: 10.10.10.3.49270 > 192.16.3.825:. Steaguri [.], ack 265, win 501, opțiuni [nop,nop,TS val 1196345951 ecr 3768310954], lungime 0
^C
20 de pachete capturate
20 de pachete primite prin filtru
0 pachete aruncate de kernel

După cum puteți vedea, adresele MAC de destinație ale răspunsurilor se potrivesc cu adresele MAC sursă ale traficurilor originale corespunzătoare, ceea ce înseamnă că acestea erau trimise către routerul de la care proveneau traficurile originale respective, chiar și atunci când adresele IP sunt identice. (De asemenea, așa cum se arată în captura de ecran, ambele rulează cu succes au preluat pagina web țintă.)

Rațiunea setului de reguli nftable

The marca ct setare în intrare cârlig lanțul va face ca marcajul să fie setat pentru toate traficurile aceleiași „conexiuni”. (Nu sunt/nu pot intra în profunzime în asta, dar dacă doriți să aflați mai multe despre asta, cercetați despre „conntrack”.) Prin urmare, în ieșire cârlig lanț puteți „selecta” răspunsurile corespunzătoare cu marca ct potrivire, și executați meta mark set ct mark asupra lor, ceea ce înseamnă a seta a meta marca pe răspunsurile de aceeași valoare ca și marca ct (adică 0xb, care este o valoare arbitrară de altfel). (În schimb, îl puteți seta la o altă valoare.)

meta marca corespunde fwmark în regula ip și, prin urmare, un tabel de rute suplimentar (11 în exemplu, care este, de asemenea, o valoare arbitrară) va fi căutată pentru traficul cu meta marca care este egal cu fwmark in regula, inainte de (din cauza valorii de prioritate mai scăzută) tabelul de rute principal este privit în sus.

Din moment ce în tabelul de rute 11 există un traseu pentru 10.10.10.0/24 cu un nexthop diferit (de ex. prin intermediul) din cel din tabelul de rute principal, răspunsurile selectate vor fi trimise către routerul „corect”. (Nu se efectuează nicio căutare ulterioară când există o rută care „acoperă” adresa de destinație.)

Cu toate că 10.10.10.0/24 este folosit în loc de Mod implicit a.k.a. 0.0.0.0/0 iar "routerele" sunt conectate la aceeași punte de-a lungul gazdei clientului web pentru a simula internetul real, nu ar trebui să împiedice exercițiul să funcționeze în situația reală.

0 + 0

Tom Yan

07.07.2023, 10:38

Un exercițiu similar poate fi probabil implementat cu o gazdă de router intermediară, caz în care regulile de setare a marcajului ct și meta ar trebui folosite cu un lanț de „hook prerouting”, cred. Dar apoi routerul intermediar ar putea fi necesar să fie folosit ca nexthop / gateway pentru subrețeaua LAN pe ambele routere ISP, ceea ce ar putea fi fie un lucru dificil / imposibil de făcut. (Ei bine, sau poate puteți face DNAT / redirecționare de porturi multi-strat, dar și asta ar putea fi urât și problematic... dacă este chiar fezabil)

0

Răspunde