Linux ca o poartă între rețelele locale și Internet
3. Afirmația problemei.
Este necesar să se permită părților mașinilor din prima rețea să ofere acces la Internet și la cea de-a doua rețea. A doua rețea de acces la Internet și prima rețea nu are. Ambele rețele trebuie să aibă acces la rețeaua reală (în care sunt serverele Web, FTP și mail ale organizației). De pe Internet ar trebui să fie accesul la rețeaua reală către Web și serverele smtp.
6. Traseul.
Rutarea este ceea ce routerele fac cu pachetul atunci când călătoresc acest pachet prin rețea. Cu alte cuvinte, acesta este procesul de alegere a căii de trimitere a pachetului către receptor și trimiterea acestuia pe această cale. Acesta este un subiect separat, mai ales dacă luăm în considerare rutarea în interiorul sistemelor autonome, dar nu ne interesează acum. Trebuie doar să știm că există un router care știe totul în afara rețelei noastre. De obicei, acesta este ruterul furnizorului și se numește de obicei gateway-ul implicit. La gateway-ul nostru, trebuie să-l specificați, altfel acesta va fi unul dintre motivele pentru care nu vom ajunge pe Internet.
server web al organizației - 193.193.1.2
mail a organizației - 193.193.1.3
Serverul FTP al organizației - 193.193.1.4
Folosind comanda
verificăm capacitatea nucleului gateway-ului de a direcționa traficul între rețele. Dacă rezultatul comenzii este "1", atunci totul este bine. Dacă "0", atunci este necesar să comandați un astfel de lucru:
# echo 1> / proc / sys / net / ipv4 / ip_forward
și verificați din nou folosind comanda anterioară. Dacă totul este „0“, atunci kernel-ul actual nu are suport pentru transmiterea de pachete între interfețe (ceea ce este necesar pentru rutare), și trebuie să fie reconstruiască. Poate că distribuția dumneavoastră are deja un nucleu precompilata cu suport pentru rutare (acest lucru poate fi găsit în documentația pentru distribuția) - atunci are sens să instaleze și să-l pornească.
Acum comanda
În cazul în care producția pentru a satisface o frază ca „Perhabs iptables sau kernel-ul trebuie să fie modernizate“, acest lucru înseamnă că kernel-ul este compilat fără suport pentru NAT și filtru de pachete. Consiliul este aceeași ca și în cazul precedent - fie kernel-ul este în distribuție, sau sunt disponibile trebuie să reconstruiască.
Apoi, creați un fișier care va conține comenzile pentru configurarea NAT și a filtrului. Puteți să o numiți așa cum doriți, să fie iptables.conf. Vom introduce următoarele rânduri:
# de fiecare dată când ștergem toate lanțurile de reguli din tabelele utilizate
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -t nat -F POSTROUTING
# setați politica implicită
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
# permitem tuturor accesul la serverul web
iptables -A FORWARD -d 193.193.1.2 -p tcp -dport 80 -j ACCEPT
# Dați tot ce altceva la serverul web, cu excepția icmp (ping-uri, traceroute și toate acestea)
iptables -A FORWARD -d 193.193.1.2 -p. icmp -j DROP
# permitem tuturor accesul la poștă prin smtp
iptables -A FORWARD -d 193.193.1.3 -p tcp -dport 25 -j ACCEPT
# permitem locațiilor să primească e-mailuri pe POP3
iptables -A FORWARD -s 192.168.1.0/24 -d 193.193.1.3 -p tcp -dport 110 -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -d 193.193.1.3 -p tcp --dport 110 -j ACCEPT
# Respingeți orice altceva la e-mail, cu excepția icmp (ping-uri, traceroute și toate acestea)
iptables -A FORWARD -d 193.193.1.3 -p. icmp -j DROP
# permitem accesul locațiilor la serverul FTP al organizației
iptables -A FORWARD -s 192.168.1.0/24 -d 193.193.1.4 -p tcp -dport 20 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -d 193.193.1.4 -p tcp -dport 21 -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -d 193.193.1.4 -p tcp -dport 20 -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -d 193.193.1.4 -p tcp -dport 21 -j ACCEPT
# Neagă totul altceva decât FTP (ping, traceroute și toate acestea)
iptables -A FORWARD -d 193.193.1.4 -p. icmp -j DROP
# aceste mașini pot merge la Internet
# dar nu avem nevoie de faptul că au mascat și când au intrat în rețeaua noastră reală
iptables -t nat -A POSTROUTING -s 192.168.1.1 -d. 1.1.1.0/192 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.2 -d. 1.1.1.0/192 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.1.3 -d. 1.1.1.0/192 -j MASQUERADE
Descriere iptables este disponibil aici -
Ei bine, pe toate mașinile organizației, această poartă trebuie specificată ca gateway implicit. Dacă același gateway va avea propriul server DNS, va trebui, de asemenea, să fie specificat. Dacă intenționați să colaborați cu serverul DNS al ISP, va trebui să îl înregistrați, nu pe gateway-ul nostru.
Apoi trebuie să oferim acestui script dreptul de al executa și de a-l desemna undeva care l-ar lansa la fiecare pornire.
10. IMPORTANT.
Nu utilizați acest exemplu în activitatea reală. ÎN NICI UN CAZ. Acesta este doar un exemplu ilustrativ. Acesta poate fi luat ca bază, dar este foarte recomandat să se modifice. Acest exemplu presupune că gateway-ul nu se execută nici un fel de servicii de rețea, și anume de ieșire a comenzii netstat -antpu gol. Acest lucru este bun și acest lucru ar trebui să depună eforturi pentru, dar nu este întotdeauna posibil (din diverse motive). Acesta conține, de asemenea, siruri de caractere pentru politica implicită a ACCEPT, care nu este întotdeauna bine (în acest caz, permite oricui, nu numai noduri de încredere de la lokalki, utilizați această poartă ca gateway-ul implicit), deși simplifică semnificativ configurația. În bună politică ar trebui să fie pus în picătură și să prescrie reguli distincte pentru primirea și traficul ICMP DNS (cel puțin). Ei bine, cu siguranță, există încă ceva ce tocmai am trecut cu vederea.
12. Observații.
Urmând exemplul - ezhikov.
Toate articolele din secțiunea "Rețea"