Puncte:0

ARP Proxy al doilea IP al VPS pentru a-l ruta prin Wireguard

drapel cn

Am configurat un proxy ARP pe VPS-ul meu. Cu această configurare, pot direcționa traficul de intrare pe al doilea IP al VPS-ului meu prin WireGuard. Acest lucru ar trebui să permită Raspberry Pi-ul meu acasă să utilizeze al doilea IP public.

Am un astfel de lucru. Pingurile primite sunt redirecționate prin tunelul WireGuard către Pi. Dar Pi încearcă apoi să răspundă la Ping prin eth0. Există vreo modalitate de a remedia acest lucru, astfel încât să trimită pachetele de răspuns și prin interfața WireGuard?

Pentru a arăta această problemă (ambele pe Raspberry Pi)

Interfață WireGuard:

    # tcpdump -i wg_pub
    tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
    ascultare pe wg_pub, tip link RAW (IP brut), dimensiunea capturii 262144 octeți
    01:35:02.796522 IP <IP public al PC-ului ping> > <Al doilea IP VPS>: Solicitare ecou ICMP, id 14, secv 1, lungime 64
    01:35:03.795359 IP <IP public al PC-ului ping> > <Al doilea IP VPS>: Solicitare ecou ICMP, id 14, seq 2, lungime 64
    01:35:04.810613 IP <IP public al PC-ului ping> > <Al doilea IP VPS>: Solicitare ecou ICMP, id 14, seq 3, lungime 64

Interfață Ethernet:

    # tcpdump -i eth0 icmp
    tcpdump: ieșirea verbosă a fost suprimată, utilizați -v sau -vv pentru decodarea completă a protocolului
    ascultare pe eth0, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
    01:37:11.477589 IP <Al doilea IP VPS> > <IP public al PC-ului ping>: răspuns ecou ICMP, id 14, seq 128, lungime 64
    01:37:12.491045 IP <Al doilea IP VPS> > <IP public al PC-ului ping>: răspuns ecou ICMP, id 14, seq 129, lungime 64
    01:37:13.505965 IP <Al doilea IP VPS> > <IP public al PC-ului ping>: răspuns ecou ICMP, id 14, seq 130, lungime 64

Aș dori să împiedic utilizarea unei subrețele private în tunelul WireGuard.

O modalitate prin care am făcut acest lucru să funcționeze a fost să adaug o rută statică

ip route add <Primul IP VPS>/32 dev eth0

și apoi suprascriind ruta implicită

ip route add 0.0.0.0/0 dev wg_pub

Dar acest lucru are dezavantajul de a direcționa întregul trafic de internet prin VPS atunci.

Puncte:0
drapel cn

Cred că ar trebui să poți face asta cu rutarea politicilor. Configurați ruta implicită pentru un nou tabel de rutare (123 de exemplu) pentru a utiliza interfața WireGuard (wg_pub):

ip route add default dev wg_pub tabelul 123

Și apoi adăugați o regulă de politică pentru a utiliza acel nou tabel pentru toate pachetele a căror sursă este al doilea IP VPS (să spunem că este 192.0.2.2 de exemplu):

regulă ip adăugați din 192.0.2.2 tabelul 123 prioritate 456

Prioritate (456) poate fi orice, contează doar dacă aveți mai multe reguli de potrivire (lista prin lista de reguli ip).

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.