înregistrare Logare
Puncte:0
avatar Server

Unele pachete nu sunt direcționate prin rețeaua locală când se utilizează nordvpn

drapel vn
Gabriele Cirulli

Rețeaua mea locală are două subrețele relevante: 192.168.1.0/24 și 192.168.72.0/24. Acestea sunt definite prin routerul meu.

Există un server local care rulează la 192.168.1.10. Serverul rulează un Home Assistant Supervisor (care este rulat prin Docker).

Serverul local trebuie să se poată conecta la diverse gazde de pe 192.168.72.0/24 subrețea.

Acest lucru funcționează corect în condiții normale, dar se defectează când introduc nordvpn utilitate, care filtrează tot traficul prin NordVPN.

Când nordvpn rulează și este conectat, serverul local nu poate trimite sau primi de la gazde de pe subrețea 192.168.72.0/24.

Am încercat să alerg lista albă nordvpn adăugați subrețea 192.168.72.0/24 (sau aceeași comandă cu 192.168.0.0/16) dar nu pare să ajute.

De exemplu, trimiterea unui ping la o adresă cunoscută de pe acea subrețea:

serv@serv:~$ ping 192.168.72.48
PING 192.168.72.48 (192.168.72.48) 56(84) octeți de date.
Din 10.8.0.1 icmp_seq=1 Gazdă destinație inaccesabilă

Dacă fug adresa IP, mi se arată următoarele:

serv@serv:~$ adresa IP
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:23:24:a6:68:56 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
       valid_lft 82326sec preferred_lft 82326sec
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP grup implicit
    link/ether 02:42:2b:ff:27:b8 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
4: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP grup implicit
    link/ether 02:42:7d:ba:7c:5b brd ff:ff:ff:ff:ff:ff
    inet 172.35.32.1/23 brd 172.35.33.255 scope global hassio
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
6: veth0fc757e@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether 16:00:e7:0d:c1:37 brd ff:ff:ff:ff:ff:ff link-netnsid 0
9: vetha95aaa0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 stare UP grup implicit
    link/ether 62:38:5f:f9:c3:f5 brd ff:ff:ff:ff:ff:ff link-netnsid 1
11: vethcf2e4fa@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether 8e:4b:83:34:3a:d6 brd ff:ff:ff:ff:ff:ff link-netnsid 1
13: veth6df409c@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether 8a:79:2e:f8:dd:8f brd ff:ff:ff:ff:ff:ff link-netnsid 2
15: veth82e25ea@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether ae:eb:57:d3:d0:e0 brd ff:ff:ff:ff:ff:ff link-netnsid 3
17: veth29b3afc@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether 66:4c:55:ca:b4:62 brd ff:ff:ff:ff:ff:ff link-netnsid 4
19: veth3377d0e@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether e2:3d:8f:67:d9:57 brd ff:ff:ff:ff:ff:ff link-netnsid 5
21: veth2c850be@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP grup implicit
    link/ether 92:2b:6e:06:51:6d brd ff:ff:ff:ff:ff:ff link-netnsid 6
23: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN grup implicit qlen 500
    link/niciuna
    inet 10.8.0.4/24 scope global tun0
       valid_lft pentru totdeauna preferred_lft pentru totdeauna

eu cred ca tun0 interfața este furnizată de nordvpn. Subrețeaua sa se potrivește cu IP-ul pe care îl văd în încercarea mea de ping eșuată.

Înțelegerea mea despre rețele este foarte limitată, așa că nu pot să-mi înțeleg de ce pachetele mele ajung în 10.8.0.1 în loc să fie trimis la router la 192.168.1.1.

Dacă este de ajutor, aceasta este rezultatul ruta ip:

serv@serv:~$ rută ip
0.0.0.0/1 prin 10.8.0.4 dev tun0
implicit prin 192.168.1.1 dev eno1 proto dhcp metric 100
1.0.0.1 prin 192.168.1.1 dev eno1
1.1.1.1 prin 192.168.1.1 dev eno1
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.4
128.0.0.0/1 prin 10.8.0.4 dev tun0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.35.32.0/23 dev hassio proto kernel scope link src 172.35.32.1
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.10 metric 100
213.232.87.204 prin 192.168.1.1 dev eno1

și iptables -S:

serv@serv:~$ sudo iptables -S
-P ACCEPT INTRARE
-P PĂDURA ÎNTÂMPRE
-P ACCEPT IEȘIRE
-N DOCKER
-N DOCKER-IZOLARE-ETAPA-1
-N DOCKER-ETAPA DE IZOLARE-2
-N DOCKER-UTILIZATOR
-A INTRARE -s 1.1.1.1/32 -i eno1 -j ACCEPT
-A INPUT -s 192.168.0.0/16 -i eno1 -j ACCEPT
-A INTRARE -s 172.35.0.0/16 -i eno1 -j ACCEPT
-A INTRARE -s 1.0.0.1/32 -i eno1 -j ACCEPT
-A INTRARE -s 213.232.87.204/32 -i eno1 -j ACCEPT
-A INTRARE -i eno1 -j DROP
-UN FORWARD -j DOCKER-UTILIZATOR
-A ÎNAINTE -j DOCKER-ETAPA DE IZOLARE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A ÎNTÂMPRE -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o hassio -m conntrack --ctstate RELATED,STABLISHED -j ACCEPT
-A FORWARD -o hassio -j DOCKER
-UN ÎNTÂNTĂR -i hassio ! -o hassio -j ACCEPT
-A FORWARD -i hassio -o hassio -j ACCEPT
-A IEȘIRE -d 1.1.1.1/32 -o eno1 -j ACCEPT
-A IEȘIRE -d 192.168.0.0/16 -o eno1 -j ACCEPT
-A IEȘIRE -d 172.35.0.0/16 -o eno1 -j ACCEPT
-A IEȘIRE -d 1.0.0.1/32 -o eno1 -j ACCEPT
-A IEȘIRE -d 213.232.87.204/32 -o eno1 -j ACCEPT
-A IEȘIRE -o eno1 -j DROP
-A DOCKER -d 172.35.32.6/32 ! -i hassio -o hassio -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 8884 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 8883 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 1884 -j ACCEPT
-A DOCKER -d 172.35.33.0/32 ! -i hassio -o hassio -p tcp -m tcp --dport 1883 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i hassio ! -o hassio -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-IZOLARE-ETAPA-1 -j RETURNARE
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-IZOLARE-STAGIA-2 -o hassio -j DROP
-A DOCKER-IZOLARE-ETAPA-2 -j RETURNARE
-UN DOCKER-USER -j RETURN

Cum pot să mă asigur că pachetele sunt direcționate către 192.168.72.0/24 cum era de așteptat?

148
0 + 0
drapel vn
Gabriele Cirulli
Am rulat `sudo ip route add 192.168.0.0/16 via 192.168.1.1` și se pare că a ajutat.Mă pot conecta acum la dispozitivele de pe subrețeaua `192.168.72.0/24` pentru că, din câte îmi dau seama, acele pachete sunt acum trimise prin router. Este aceasta abordarea corectă, totuși? Nu știu multe despre rețele, așa că nu sunt sigur dacă aceasta este o modalitate adecvată de a o rezolva.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.