Praktični primeri – Modul 15 – WAN, VPN i pristup internetu

Ovaj dokument sadrži pet detaljno rešenih praktičnih primera i jedan integrativan poslovni scenario.

Primer 1 – PPP sa CHAP autentifikacijom na serijskoj WAN vezi

Situacija: R1 i R2 su povezani serijskom vezom koja predstavlja iznajmljeni vod (leased line) između dve poslovnice. Potrebno je zameniti podrazumevanu HDLC enkapsulaciju sa PPP-om i uključiti CHAP autentifikaciju.

Konfiguracija na R1:

R1(config)#username R2 password Deljena-Lozinka123
R1(config)#interface serial 0/0/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp authentication chap

Konfiguracija na R2:

R2(config)#username R1 password Deljena-Lozinka123
R2(config)#interface serial 0/0/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp authentication chap

Provera:

R1#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up
  ...
  Encapsulation PPP, LCP Open

Objašnjenje: username <ime-drugog-rutera> password <lozinka> mora biti identičan na oba rutera (Tema 4) — CHAP proverava da obe strane poznaju istu deljenu lozinku, bez da je ikada pošalje preko linka u čitljivom obliku. Ime u username komandi odgovara hostname-u rutera sa druge strane veze, jer CHAP koristi hostname kao identifikator tokom razmene izazova.

Primer 2 – Modem, ruter i javna IP adresa u kućnom/malom poslovnom okruženju

Situacija: Mala firma dobija od ISP-a optički modem (ONT) i zasebno kupuje sopstveni enterprise ruter, umesto da koristi kombinovani ISP uređaj.

Topologija (konceptualno):

Internet (ISP) --- ONT (modem, Layer 1) --- Ruter firme (Layer 3, NAT, DHCP)

Provera na ruteru firme:

R1#show ip interface brief
Interface              IP-Address      OK? Method Status
GigabitEthernet0/0      203.0.113.45    YES DHCP    up
GigabitEthernet0/1      192.168.1.1     YES manual  up

Objašnjenje: GigabitEthernet0/0 (WAN strana, ka ONT-u/ISP-u) dobija javnu IP adresu (203.0.113.45) putem DHCP-a od ISP-a — ovo je adresa koju čitav internet vidi kao „adresu firme". GigabitEthernet0/1 (LAN strana) ima privatnu adresu (192.168.1.1) koju ruter koristi za sopstveni DHCP server i NAT (Modul 13) ka internim uređajima. ONT sam po sebi nema nikakvu IP adresu relevantnu za ovu topologiju — on samo prevodi optički signal u Ethernet (Tema 3), bez ikakvog rutiranja.

Primer 3 – Site-to-site naspram remote-access odluka

Situacija: Firma ima dve stalne poslovnice koje treba trajno povezati, i 15 zaposlenih koji povremeno rade od kuće i treba da pristupe internoj mreži.

Rešenje:

• Dve poslovnice: site-to-site VPN između graničnih rutera obe lokacije — tunel je stalan, transparentan za sve zaposlene u obe zgrade.
• 15 zaposlenih koji rade od kuće: remote-access VPN — svaki instalira VPN klijent na sopstvenom laptopu i autentifikuje se pojedinačno kada mu je potreban pristup.

Objašnjenje: Ključna razlika (Teme 10-11) je u tome ko se povezuje i koliko često. Poslovnice su stalne, poznate lokacije sa mnogo korisnika koji svi treba da imaju pristup — jedan tunel između graničnih uređaja pokriva sve njih odjednom, bez potrebe za klijentskim softverom na svakom pojedinačnom računaru. Zaposleni koji rade od kuće su pojedinačni, mobilni korisnici sa promenljivom lokacijom (kućna mreža, kafić, hotel) — remote-access VPN klijent na njihovom uređaju je jedini praktičan način da se pojedinačno autentifikuju i povežu, bez obzira odakle se povezuju.

Primer 4 – IPsec tunnel naspram transport moda

Situacija: Potrebno je odlučiti koji IPsec mod koristiti u dva različita scenarija: (a) zaštita site-to-site VPN-a između dve poslovnice sa privatnim mrežama, (b) zaštita direktne komunikacije između dva servera koja imaju javne adrese.

Rešenje:

• (a) Site-to-site VPN između poslovnica: Tunnel mod — ceo originalni paket (uključujući privatne izvorišnu/odredišnu adresu) mora biti sakriven unutar novog paketa sa javnim adresama rutera, jer se privatne adrese ne mogu direktno rutirati preko interneta (Modul 4).
• (b) Direktna komunikacija dva servera sa javnim adresama: Transport mod — nije potrebno sakriti IP zaglavlje (oba servera već imaju rutabilne, javne adrese), samo je potrebno zaštititi sadržaj (payload) same komunikacije.

Objašnjenje: Izbor moda (Tema 12) direktno zavisi od toga da li originalne IP adrese učesnika u komunikaciji mogu bezbedno da putuju preko javne mreže u nepromenjenom obliku. Kada ne mogu (privatne adrese, kao u site-to-site VPN scenariju), tunnel mod je obavezan. Kada mogu (već javne, rutabilne adrese), transport mod je efikasniji izbor jer dodaje manje dodatnog zaglavlja (overhead-a).

Primer 5 – Konfiguracija GRE tunela između dve poslovnice

Situacija: R1 (poslovnica A, javna adresa 203.0.113.1) i R2 (poslovnica B, javna adresa 198.51.100.1) povezani su preko simuliranog interneta. Potrebno je uspostaviti GRE tunel koji povezuje njihove privatne LAN mreže (192.168.1.0/24 i 192.168.2.0/24).

Konfiguracija na R1:

R1(config)#interface tunnel 0
R1(config-if)#ip address 10.10.10.1 255.255.255.252
R1(config-if)#tunnel source 203.0.113.1
R1(config-if)#tunnel destination 198.51.100.1
R1(config-if)#exit
R1(config)#ip route 192.168.2.0 255.255.255.0 tunnel 0

Konfiguracija na R2:

R2(config)#interface tunnel 0
R2(config-if)#ip address 10.10.10.2 255.255.255.252
R2(config-if)#tunnel source 198.51.100.1
R2(config-if)#tunnel destination 203.0.113.1
R2(config-if)#exit
R2(config)#ip route 192.168.1.0 255.255.255.0 tunnel 0

Provera:

R1#show interfaces tunnel 0
Tunnel0 is up, line protocol is up
  Tunnel source 203.0.113.1, destination 198.51.100.1
  Tunnel protocol/transport GRE/IP

R1#ping 10.10.10.2

Objašnjenje: tunnel source/tunnel destination koriste javne, rutabilne adrese (Tema 14) preko kojih R1 i R2 stvarno mogu da se dosegnu preko simuliranog interneta — to su fizičke WAN adrese, potpuno odvojene od adrese samog tunela (10.10.10.0/30). Statička ruta ka udaljenoj privatnoj mreži koristi tunnel 0 kao exit interface (princip iz Modula 11, Tema 3), tretirajući tunel identično kao bilo koji drugi point-to-point interfejs. Ovaj GRE tunel sam po sebi ne enkriptuje saobraćaj (Tema 14) — laboratorijska vežba ovog modula dodaje IPsec preko ovog istog tunela.

Poslovni scenario – Izbor WAN i VPN strategije za firmu sa tri lokacije

Kontekst: Firma „Solvex Group" ima centralu i dve poslovnice, plus 20 zaposlenih koji rade hibridno (delimično od kuće). Rukovodstvo traži preporuku za povezivanje svih lokacija i udaljenih zaposlenih, uz razuman budžet.

Zahtevi:

• Sve tri lokacije moraju međusobno komunicirati kao jedna mreža.
• Osetljiv saobraćaj (interni VoIP sistem) mora imati predvidljiv kvalitet.
• Udaljeni zaposleni moraju bezbedno pristupati internim resursima, uključujući sa hotelskih/javnih mreža koje ponekad blokiraju neuobičajen saobraćaj.
• Budžet ne dozvoljava punu MPLS uslugu za sve tri lokacije.

Projektovano rešenje:

Zašto ovakav dizajn: Kombinacija GRE over IPsec za site-to-site povezanost i SSL VPN za pojedinačne udaljene korisnike rešava oba scenarija (Teme 10-11) najekonomičnijim putem koji zadovoljava bezbednosne zahteve, dok QoS obezbeđuje da deljena internet propusnost i dalje pruži prihvatljiv kvalitet za osetljiv VoIP saobraćaj, bez potrebe za skupljom MPLS ili leased line infrastrukturom u ovoj fazi rasta firme.