Puncte:0

Dirijați traficul de la tun0 la eth0 pe anumite porturi

drapel us

Mă doare destul de cap în privința asta. Mergea înainte, dar mi-am dat seama că nu mai funcționează. Posibil pentru că după câteva actualizare.

Am OpenVPN care rulează cu această configurație:

client
dev tun
proto udp
telecomanda 45.152.181.35 1194
rezoluție-reîncercare infinit
la distanţă-aleatorie
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
cheie-persiste
persist-tun
ping 15
ping-repornire 0
ping-timer-rem
reneg-sec 0
comp-lzo nr

script-securitate 2
sus /etc/openvpn/update-resolv-conf
repornire
jos /etc/openvpn/update-resolv-conf
jos-pre

dhcp-option DNSSEC permit-downgrade

server remote-cert-tls
dhcp-opțiune DNS 10.0.0.50
dhcp-opțiune DNS 10.0.0.51
ruta 10.0.0.50 255.255.255.255 net_gateway
ruta 10.0.0.51 255.255.255.255 net_gateway

verbul 3
Trage
rapid-io
cifrul AES-256-CBC
auth SHA512
...

Îl am în funcțiune pe tun0. Implicit, tot traficul meu este redirecționat către această interfață, nicio problemă.

Vreau ca unele porturi, în special 80 și 443, să fie redirecționate către eth0 pentru a utiliza IP-ul meu public obișnuit.

Obișnuiam să-l termin rulând acest script:

regulă ip adăugați sport 80 tabelul 128
regulă ip adăugați sport 443 tabelul 128

ip route add table 128 la 10.0.0.0/24 dev eth0
ip route add table 128 default prin 10.0.0.1

Așa că înainte funcționa ca un farmec, dar acum, din anumite motive, nu mai funcționează.

ifconfig arata asa:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet 10.0.0.50 netmask 255.255.255.0 difuzare 10.0.0.255
        inet6 fe80::dea6:32ff:feec:aff6 prefixlen 64 scopeid 0x20<link>
        inet6 fe80::eb4d:9953:dab1:619f prefixlen 64 scopeid 0x20<link>
        ether dc:a6:32:ec:af:f6 txqueuelen 1000 (Ethernet)
        Pachete RX 50096 octeți 34011045 (34,0 MB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 49083 octeți 24696341 (24,6 MB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10<gazdă>
        loop txqueuelen 1000 (Loopback local)
        Pachete RX 7445 octeți 1912768 (1,9 MB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 7445 octeți 1912768 (1,9 MB)
        Erori TX 0 a scăzut 0 depășiri 0 purtător 0 coliziuni 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
        inet 10.8.1.9 netmask 255.255.255.0 destinație 10.8.1.9
        inet6 fe80::bddd:593b:241f:491f prefixlen 64 scopeid 0x20<link>
        nespecificat 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
        Pachete RX 32682 octeți 25077475 (25,0 MB)
        Erori RX 0 a scăzut 0 depășiri 0 cadru 0
        Pachete TX 26904 octeți 4130127 (4,1 MB)

Ca să fie clar, o comandă de genul curl -s https://checkip.amazonaws.com folosit pentru a scoate IP-ul meu public real, acum iese IP-ul meu public VPN.

Devin amețit căutând pe Google asta, am încercat o mulțime de lucruri fără succes, dar așa cum mergea înainte, bănuiesc ceva stupid pe care trebuie să-mi lipsesc.

Orice sugestie ar fi foarte apreciată.

A.B avatar
drapel cl
A.B
Care ar fi rezultatele lui `sysctl -ar \.rp_filter`?

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.