Să aducem puțină claritate:
Pentru a începe, să actualizăm (doar în caz) modul de legare a conexiunii ppp la interfața ppp cu un anumit număr. Pentru a face acest lucru, aveți nevoie de fișierul corespunzător din "/ etc / ppp / peers&quto; adăugați o linie:
Apoi adăugați încă un parametru în același fișier: marca de conectare:
În plus, această interfață nu ar trebui să atingă ruta implicită la ridicare. Acest lucru se realizează aproximativ în felul următor:
Acest lucru va fi util mai târziu. Acum trebuie să descriem două tabele suplimentare de rutare (câte unul pentru fiecare furnizor). Pentru aceasta, adăugați următoarele rânduri la fișierul "/ etc / iproute2 / rt_tables":
Acum trebuie să specificăm explicit interfața prin care tabelul de rutare să căutați rute. Pentru a face acest lucru, trebuie să executați aceste comenzi (și, în același timp, adăugați "/etc/rc.local" pentru a executa la boot):
Desigur, este necesar ca în tabelele din dreapta au fost dorit rute (cel puțin ruta default). Pentru spate este realizată, prin crearea unui script „/etc/ppp/ip-up.d/tbt“ cu privire la acest conținut:
Pentru eth0, este încă mai ușor: deschideți fișierul "/ etc / network / interfaces" și aruncați configurația eth0 la acest tip:
Acum, trebuie să reporniți serverul și după aceea serverul va merge în mod implicit la Internet prin eth0, dar în același timp va fi accesibil atât din exterior, prin ambele canale. Acum creați scriptul "/usr/local/scripts/check_internet.sh" după cum urmează:
Acest script ar trebui să fie executat în fiecare minut. Pentru aceasta, adăugați o linie în "/ etc / crontab":
Apoi trebuie să activați redirecționarea și ridicarea NAT pentru rețeaua locală pe ambele interfețe. Exemplele pot fi găsite, de exemplu, aici și aici.
Asta e tot. Muncă plăcută!
Am încercat încă o dată să înțeleg problema și am realizat că nu a înțeles. ce vrei să ajungi în cele din urmă?
schimbarea setului de reguli în zbor este ușor. în caz extrem, atunci când comutați, puteți șterge toate regulile și lucrurile din nou.
totuși nu este clar ce anume doriți să primiți și, prin urmare, este dificil să oferiți sfaturi. Care este lanțul TRY-SNAT?
Am încercat încă o dată să înțeleg problema și am realizat că nu a înțeles. ce vrei să ajungi în cele din urmă?
schimbarea setului de reguli în zbor este ușor. în caz extrem, atunci când comutați, puteți șterge toate regulile și lucrurile din nou.
totuși nu este clar ce anume doriți să primiți și, prin urmare, este dificil să oferiți sfaturi. Care este lanțul TRY-SNAT?
Sunt de acord, ștergeți regulile, acesta este primul lucru care vine în minte!
TRY-SNAT este un lanț personalizat!
Provocarea, în ceea ce privește înțelegerea, destul de simplu: dacă doriți să modificați ruta default schimbat -A TRY-SNAT -j SNAT --to-source 192.168.0.1 pe -A TRY-SNAT -j SNAT --to-source 192.168.20.1
Problema, deși nu este foarte mare, dar spune-mi unde să caut să înțeleg motivul.
Totul se face exact ca aici, cu excepția interfeței ppp
Am et0 main eth1 backup eth2 localhost
comutarea este un mare succes!
Dar cand functioneaza pe maina intregul fascicul functioneaza in special! Pings! merge
dar când treceți la un site de rezervă, se pare că funcționează, dar ping-urile nu merg. A încercat să se aplice pe iptables noi cu compensarea tabelelor. nu ajută.
Câteodată am observat că mergeți după ce treceți cu o întârziere de aproximativ un minut.
În ceea ce poate fi o problemă promptă.
Problema, deși nu este foarte mare, dar spune-mi unde să caut să înțeleg motivul.
Totul se face exact ca aici, cu excepția interfeței ppp
Am et0 main eth1 backup eth2 localhost
comutarea este un mare succes!
Dar cand functioneaza pe maina intregul fascicul functioneaza in special! Pings! merge
dar când treceți la un site de rezervă, se pare că funcționează, dar ping-urile nu merg. A încercat să se aplice pe iptables noi cu compensarea tabelelor. nu ajută.
Câteodată am observat că mergeți după ce treceți cu o întârziere de aproximativ un minut.
În ceea ce poate fi o problemă promptă.
Și înainte de a merge ping pagini deschise? Imediat, conexiunea este verificată o dată pe minut. Ie Dacă canalul principal este oprit, atunci trecerea la rezerva va avea loc într-un minut. În acest moment, Internetul nu va fi.
Bună ziua!
Explicați situația
Există două canale Internet cu IPoE
domru principal
în regim de așteptare
sudo cat / etc / iproute2 / rt_tables
Cod: [Evidențiați]
#
# valori rezervate
#
255 locale
254 principal
253 implicit
195 beeline
190 domru
0 nespec
#
# local
#
# 1 inr.ruhep
sudo cat /etc/rc.local
Cod: [Evidențiați]
sudo cat / etc / rețea / interfețe
# Interfața de rețea cu loopback
auto lo
dacă lo lo inet loopback
auto eth0
dacă este et0et inet static
adresa IP1
masca de masă 255.255.255,0
gateway GW1
mertic 100
dns-nameservers 127.0.0.1
post-up / sbin / ip route adaugă implicit prin tabelul GW1 domru
post-up / sbin / ip traseu implicit prin GW2 dev eth2 metric 100
post-up / sbin / ip route adaugă implicit prin GW1 dev eth0 metric 100
# Interfața primară a rețelei
auto eth1
iface eth1 inet static
adresa 192.168.0.250
masca de masă 255.255.255,0
dns-nameservers 127.0.0.1
dns-căutare domen.ru
auto eth2
iface eth2 inet static
adresa IP2
masca de masă 255.255.255.252
#gateway GW2
dns-nameservers 127.0.0.1
post-up / sbin / ip route adaugă implicit prin tabelul GW2 beeline
Cu aceste setări, gateway-ul este disponibil pe ambele canale
implicit prin GW1 dev eth0 metric 100
10.10.40.0/24 prin 10.10.40.2 dev tun0
10.10.40.2 dev tun0 proto kernel scope legătură src 10.10.40.1
NETWORK_IP2 / 30 dev eth2 proto kernel domeniu conexiune src IP2
NETWORK_IP1 / 24 dev eth0 proto kernel domeniu conexiune src IP1
192.168.0.0/24 dev eth1 proto kernel domeniu legătură src 192.168.0.250
Folosesc scriptul de comutare la canalul de backup
Când canalul principal cade, se comută remarcabil.
Dar spatele nu se aprinde, nu înțeleg de ce?
Întrebarea a doua, dar la fel!
sudo ifconfig eth0 jos
comunicarea se pierde pe canalul principal. Astept ca scenariul sa se termine
Înțeleg
sudo ip r
Cod: [Evidențiați]
prestabilit prin GW2 dev eth2 metric 100
10.10.40.0/24 prin 10.10.40.2 dev tun0
10.10.40.2 dev tun0 proto kernel scope legătură src 10.10.40.1
NETWORK_IP2 / 30 dev eth2 proto kernel domeniu conexiune src IP2
192.168.0.0/24 dev eth1 proto kernel domeniu legătură src 192.168.0.250
face sudo ifconfig eth0 sus
Înțeleg
prestabilit prin GW2 dev eth2 metric 100
10.10.40.0/24 prin 10.10.40.2 dev tun0
10.10.40.2 dev tun0 proto kernel scope legătură src 10.10.40.1
NETWORK_IP2 / 30 dev eth2 proto kernel domeniu conexiune src IP2
NETWORK_IP1 / 24 dev eth0 proto kernel domeniu conexiune src IP1
192.168.0.0/24 dev eth1 proto kernel domeniu legătură src 192.168.0.250
Internetul se află pe canalul de rezervă, dar poarta de acces de pe canalul principal nu este disponibilă. numai pe rezervă.
Dacă vreau
Cod: [Evidențiați]
sudo ip r del implicit prin GW2 dev eth2 metric 100 sudo ip r adăugați implicit prin GW1 dev eth0 metric 100
Internetul respectiv trece prin canalul principal, iar gateway-ul este disponibil pe ambele canale.
De ce este așa, de ce nu este accesibilă canalul principal în cazul căderii și creșterii ulterioare a lui eth0?
De exemplu, eliminăm accesibilitatea, schimbarea are loc. apoi activați disponibilitatea și apoi bummer. nu funcționează!