rutarea unui IP specific către tunelul ppp0 (Administrarea sistemului, Router, Iptables, Rutare)

gompertz a intrebat.

Simt că m-am luptat destul de mult cu asta și am nevoie de ajutor.

Am un tunel pptp și încerc să rutez traficul de destinație de la 208.85.40.20 către tunelul pptp (ppp0). (Observatorii atenți pot recunoaște ip-ul ca fiind cel al pandora.com). Fac toată această configurație pe un router… și știu că nu funcționează cu succes, deoarece traceroute nu produce decât asteriscuri.

Am lipit mai jos ieșirile relevante: (cu unele modificări de „securitate” ale adreselor)

[email protected]:~# ifconfig

br0       Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24936 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4894242 (4.6 MiB)  TX bytes:5941902 (5.6 MiB)

eth0      Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:51829 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56824 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11490288 (10.9 MiB)  TX bytes:11857913 (11.3 MiB)
          Interrupt:4

eth2      Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:15426
          TX packets:9529 errors:21 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:423 (423.0 B)  TX bytes:596036 (582.0 KiB)
          Interrupt:2 Base address:0x2000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:30 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2300 (2.2 KiB)  TX bytes:2300 (2.2 KiB)

ppp0      Link encap:Point-Point Protocol
          inet addr:68.68.39.250  P-t-P:172.16.20.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:165 errors:2 dropped:0 overruns:0 frame:0
          TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:7006 (6.8 KiB)  TX bytes:3462 (3.3 KiB)

vlan0     Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:28182 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33813 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5006544 (4.7 MiB)  TX bytes:6609774 (6.3 MiB)

vlan1     Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          inet addr:173.183.111.3  Bcast:173.183.111.255  Mask:255.255.224.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:23653 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23012 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5522012 (5.2 MiB)  TX bytes:4982944 (4.7 MiB)

wds0.4915 Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wds0.4915 Link encap:Ethernet  HWaddr 00:1A:92:BC:XX:XX
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[email protected]:~# cat /etc/ppp/ip-up

iptables -A FORWARD -t filter -i br0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -t filter -i ppp0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.1/24 -d 0/0 -j MASQUERADE

iptables -A forwarding_rule -o ppp0 -j ACCEPT
iptables -A forwarding_rule -i ppp0 -j ACCEPT
iptables -t nat -A postrouting_rule -o ppp0 -j MASQUERADE

[email protected]:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.20.1     *               255.255.255.255 UH    0      0        0 ppp0
208.85.40.20    *               255.255.255.255 UH    0      0        0 ppp0
192.168.1.0     *               255.255.255.0   U     0      0        0 br0
173.183.192.0   *               255.255.224.0   U     0      0        0 vlan1
default         d173-183-192-1. 0.0.0.0         UG    0      0        0 vlan1
default         192.168.1.1     0.0.0.0         UG    0      0        0 br0

Orice sfat este foarte apreciat, nu mă pricep prea bine la rețele, dar sunt destul de iscusit în a învăța 😉

2 răspunsuri
Eddy

ai putea face ceva de genul ăsta pentru scriptul tău ip-up:

echo "route add 208.85.40.20 dev $IFNAME" >> /etc/ppp/ip-up.local
chmod 755 /etc/ppp/ip-up.local

EDITARE

Văd că folosești openwrt; nu cred că $IFNAME se va rezolva la ppp0,ppp1 etc. Wiki-ul openwrt face aluzie la $INTERFACE în scriptul ip-up:

echo "route add 208.85.40.20 dev $INTERFACE" >> /etc/ppp/ip-up

EDIT2

Ați încercat să adăugați manual ruta?

route add 208.85.40.20 dev ppp0
route add 208.85.40.50 dev ppp0

Dacă da, apare în tabelul de rutare?Dacă da, (presupun că da), atunci bănuiesc că problema este fie în firewall-ul dvs., fie de cealaltă parte a legăturii ppp. Puteți verifica cu tcpdump – dacă vedeți că traficul părăsește interfața ppp0, dar nu se întoarce, atunci probabil că este vorba de omologul ppp. Dacă nu vedeți niciun trafic, atunci verificați setările iptables.

tcpdump -n ip host 208.85.40.20

insecure iptables pentru depanare:

iptables -t nat -I PREROUTING -d 208.85.40.20 -j ACCEPT
iptables -t nat -I PREROUTING -s 208.85.40.20 -j ACCEPT
iptables -I FORWARD -s 208.85.40.20 -j ACCEPT
iptables -I FORWARD -d 208.85.40.20 -j ACCEPT
iptables -t nat -I POSTROUTING -s 208.85.40.20 -j ACCEPT
iptables -t nat -I POSTROUTING -d 208.85.40.20 -j MASQUERADE

Comentarii

  • Ceea ce ai făcut tu produce ceea ce aveam în tabela de rute pentru început. traceroute’ing 208.85.40.20 după aceea nu returnează nimic. = –  > Por gompertz.
  • Eddy, mulțumesc pentru ajutorul acordat până în acest punct! tcpdump -n ip host 208.85.40.20 -i eth0 captează solicitările/replicile ping înainte de a atinge tabela de rute. Apoi, după ce am făcut „route add 208.85.40.20 dev ppp0” și am rulat din nou tcpdump cu „tcpdump -n ip host 208.85.40.20 -i ppp0”, acesta captează solicitări ping, dar niciun răspuns înapoi. Am încercat acest lucru cu iptables flush, firewall oprit, regulile dvs. etc. Toate cu același rezultat. Presupun că dacă tcpdump arată că părăsește interfața, înseamnă că trece cu succes de firewall? Poate că aceasta este o problemă a serverului ppp, dar este de la strongvpn, care este de încredere. –  > Por gompertz.
  • Schimbat serverul, aceleași rezultate. Cu toate acestea, o nouă descoperire:: Inițializarea tunelului cu „pppd call strongvpn debug dump nodetach”, apoi deschiderea unui nou terminal și efectuarea de ping/tracing pe 208.85.40.20 nu arată nimic trimis de pppd… Aș presupune că daimonul ar trebui să arunce un fel de gârlă. –  > Por gompertz.
  • Alte câteva date: Pot face ping la 68.68.36.250 (acest lucru are sens, deoarece este IP-ul lui ppp0, dar este doar o afirmație). Nu pot face ping la 172.16.20.1 (pentru mine, acest lucru nu are sens, deoarece am 172.16.20.1 în tabelul de rute și, deși este adresa serverului ppp, cred că ar trebui să fie accesibilă pentru ca tunelul să fie într-adevăr un tunel….). –  > Por gompertz.
  • presupun că traficul dvs. ajunge la celălalt capăt al tunelului ppp; dar adresa dvs. de ip ppp0 nu primește traducerea nat pe partea cealaltă, astfel încât serverul 172.16.20.1 se întoarce la dvs. prin intermediul gateway-ului implicit și se pierde. –  > Por Eddy.

Am făcut o configurație similară, dar folosind două routere și funcționează foarte bine. Am configurat primul router ca fiind 192.168.199.1 și am configurat routerul strongVPN ca fiind 192.168.199.2. Routerul strongVPN are o adresă WAN statică care indică 192.168.199.1 ca gateway. Routerul principal are rute adăugate pentru adresele pe care dorește să iasă prin tunel. De exemplu, 208.85.40.20, subnet 255.255.255.255.0, gateway 192.168.199.2. Folosesc subrețeaua /24 deoarece mă gândesc că acea companie ar putea avea un bloc de adrese pentru diverse servere. Funcționează foarte bine și oferă viteză maximă pentru cea mai mare parte a traficului de rețea și viteză tunelizată pentru serviciile pe care doriți să le direcționați prin serverele țării gazdă. Știu că acest lucru nu a răspuns în mod specific la întrebarea dvs. inițială, dar este o altă modalitate de a ajunge acolo care știu că funcționează.