Tag Archives: Mikrotik

Mikrotik senzor temperature

Na određenim RouterBoard pločama imamo senzor temperature, pa ga možemo iskoristiti za automatsko slanje mejla ukoliko uređaj pređe zadatu temperaturu. Ovo može biti vrlo korisno u manje opremljenim serverskim sobama koje nemaju redudantno hlađenje, a ni sopstveni uređaj za monitoring, ali se tu nalazi neki od modela Mikrotik rutera sa pomenutim senzorom.

Podesićemo skript koji će proveravati temperaturu i slati mejl ukoliko nije u dozvoljenim granicama, dok će u suprotnom ispisivati log, pa ukoliko koristite neki od alata za udaljeno nadgledanje logova bićete u mogućnosti da vidite temperaturu. Prvo je potrebno da podesimo e-mail alat da bi uopšte mogli da šaljemo poruke:

MikrotikTemp01

/tool e-mail
set address=192.168.0.252 from=Mikrotik@Rajco.test

Nakon toga možemo podesiti skript. U zavisnosti od željene temperature možete promeniti vaše vrednosti:

MikrotikTemp02

add name=TempMonitor policy=\
    ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
    source="/system health\r\
    \n:if ([get temperature]>32) do={/tool e-mail send to=\"admin@rajco.me\" su\
    bject=\"Temperatura serverske sobe\" body=(\"Temperatura serverske sobe je\
    \_veca od dozvoljene! Trenutna temperatura iznosi : \".[/system health get\
    \_temperature] )} else {:log info (\"Temperatura je u dozvoljenim vrednost\
    ima. T=\".[/system health get temperature])}"

Sada je još potrebno da stavimo scheduler koji će pokretati skript u određenom razmaku. Lično mislim da je pet minta sasvim prihvatljiv vremenski interval:

MikrotikTemp03

add interval=5m name=TempMonitor on-event="/system script run TempMonitor" \
    policy=\
    ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
    start-date=sep/21/2012 start-time=09:46:31

Uz male izmene možemo postavljati automatska obaveštenja za sve događaje na routerOS-u, a ne samo za temperaturu.

Mikrotik QoS: kontrola protoka i prioritetizacija saobraćaja

Ovo je jedno od najčešćih pitanja korisnika RouterOS-a, ali je jedno od težih za podešavanje ukoliko želimo ozbiljniju kontrolu i prioritetizaciju. Za osnovnu kontrolu protoka mogu se koristiti Simple Queues ali zbog jednostavnog podešavanja i postojanja dosta uputstava oni neće biti tema teksta. Takođe ako koristimo prioritete zasebno za svakog klijenta imaćemo problem sa uređajem koji će moći procesorski da obradi sva pravila u slučaju velikog broja istih (da bi došao do poslednjeg pravila mora da proveri sve prethodne).

Da bi mogli bilo šta da radimo u vezi sa QoS i prioretitazijom saobraćaja od esencijalne važnosti je poznavanje Packet Flow Diagram-a. Tu ćemo videti koja se radnja kada obavlja i znati gde možemo da markiramo saobraćaj, a zatim i gde da ga ograničimo. Nije neophodno a ni praktično znati napamet dijagram jer je komplikovan a sa novim verzjima RouterOS se može promeniti. Koristićemo dve slike dijagrama, jedna za Bridging (Layer 2, MAC) gde je deo o rutiranju uprošćen i jednu za Routing (Layer 3, IP), gde je deo o bridgingu uprošćen.

700px-Bridge_final

700px-IP_final

  • Input Interface – početna tačka za pakete koji idu kroz ruter (nije bitno da li je paket primljen na fizički ili virtuelni interfejs, on uvek počinje ovde).
  • Output Interface – poslednja tačka u toku paketa kroz ruter, trenutak pre nego što se paket pošalje van.

Sledeći dijagram ćemo koristiti za QoS:

QoS_Packet_Flow

Na ovom dijagramu vidimo da saobraćaj možemo markirati na pet mesta (Mangle Prerouting, Mangle Input, Mangle Forward, Mangle Output, Mangle Postrouting), dok ograničenje možemo vršiti na tri mesta (Global-in/Global-Total, Global-Out/Global-Total i Out-Interface/HTB (za svaki interfejs na ruteru)). Postavlja se pitanje da li ograničavati saobraćaj na Global-Out ili na HTB interfejsu? U slučaju SRC-NAT odnosno masquerade Global-Out će biti svestan privatnih IP adresa klijenata, dok HTB interfejs neće jer iz toka paketa vidimo da je HTB posle SRC-NAT.

Mangle opcija firewal-a nam dozvoljava da dodajemo neke oznake paketima, a kasnije da pomoću drugih opcija RouterOS-a vršimo rutiranje ili kontrolu protoka markiranih paketa. Obeleženi paketi su namenjeni samo tom ruteru i nije ih moguće prosleđivati drugim ruterima, dakle ako obeležimo paket u prerouting-u on će takav i biti do postrouting-a, odnosno dok ne napusti ruter. Postoje tri vrste “obeležavanja” paketa: Connection mark, Routing mark, Packet mark.

mikrotik-mangle-mark

Za potrebe kontrole protoka koristićemo Packet mark. Takođe sa mangle opcijom možemo menjati neka polja IP zaglavlja kao što su TTL (Time to Live, sprečava petlje u mreži, odnosno kruženje paketa u nedogled) ili ToS (Type of Services, ToS čini osam bita čija se funkcija tokom vremena menjala, ali u principu dozvoljava hostu da ukaže mreži koju vrstu servisa želi i poslednjom revizijom RFC dokumenata definisano je da prvih šest bitova služi za određivanje različitih nivoa kvaliteta servisa, dok se druga dva bita odnose na zagušenje saobraćaja).

HTB predstavlja Hierarchical Token Bucket i na njemu se zasniva sva kontrola protoka u RouterOS-u. On nam omogućava da se kreira struktura redosleda ograničenja i odredi odnos između samih redova. Postoje tri virtuelna HTB-a: Global-In, Global-Out i Global Total i još jedan pre svakog izlaznog interfejsa. Kada paket putuje kroz ruter on prolazi sva četiri HTB-a. Ukoliko paket ide ka ruteru prolazi samo global-in i global-total i u poslednjem slučaju kada paket ide od rutera prolazi kroz global-out, global-total i interfejs HTB što možemo i videti na poslednjem toku paketa (QoS packet flow). Neke karakteristike HTB su:

  • Kada queue ima barem jedan child queue on automatski postaje parent queue
  • Svi child queues su na istom HTB nivou
  • Child queues će prvo dobiti limit-at (ako je on podešen)  a zatim će ostatak saobraćaja da se distribuira preko parents
  • HTB ima dva limita, limit-at i max-limit, HTB će prvo pokušati da namiri svaki child limit-at, a tek zatim da pokuša dostizanje max-limit ako ima resursa
  • HTB prioriteti rade samo za child queues, parents nemaju prioritete
  • 8 je najniži prioritet, 1 je najveći
  • Queue sa većim prioritetom će prvi da ostvari max-limit
  • Prioritetizacija će raditi isključivo ako su ograničenja postavljena (ako nema limita nema razloga ni da se paketi odbacuju, a samim tim ni prioritetizacija neće raditi, jer ona ne preuređuje niz paketa već neke propušta dok druge odbacuje)
  • Prioritetizacija nema uticaja na limit-at saobraćaj

Maksimalna brzina roditeljskog reda bi trebala da bude veća ili jednaka zbiru limit-at brzina svih potomaka i maksimalna brzina bilo kog potomka bi trebala da bude manja ili jednaka maksimalnoj brzini roditeljskog reda.

Mnogi se žale da im QoS ne radi jer su stavili jedno ograničenje a na interfejsu vide veću količinu saobraćaja. To se dešava zato što je global-in posle input interfejsa i ne može ograničiti koliko će saobraćaja stići na sam interfejs (ako klijent pošalje saobraćaj on mora stići negde, ne može jednostavno nestati). Jedini način da se vidi QoS na delu je praćenje TX interfejsa “sa druge strane”. Još jedna bitna stavka je da sam QoS ne zna koliki mu je propusni opseg dostupan zato što su svi HTB pre izlaznog interfejsa koji prvi može (u većini slučajeva neće) znati koliki je propusni opseg, tj. može znati maksimalni propusni opseg ali ako je stvarni limit manji jedini način da obezbedimo QoS je da taj limit sami postavimo.

Da bi uspešno koristili queues moramo još znati i koji tip queue izabrati. Mi ćemo koristiti PCQ (Per Connection Queue) koji je unapređen od verzije 5.0RC4 (dodata je podrška za IPv6, povećane su performase i što je vrlo bitno dodat je burst). PCQ je uveden da bi se oslobodili glomaznih rešenja za QoS gde je većina queue bila ista samo za različite sub-stream-ove. Sa dva PCQ-a možemo zameniti praktično neograničen broj simple queues, kažem dva jer nam jedan treba za upload, a drugi za download saobraćaj. PCQ podržava četiri classifier-a i to po odredišnom i izvornom portu kao i po odredišnoj i izvornoj IP adresi.

mikrotik-pcq

Kada smo se upoznali sa osnovnim stvarima koje je neophodno znati da bi podesili QoS možemo preći na praktične zadatke i pitanja koja će vas najviše interesovati. U primeru koji sledi videćemo da je QoS neophodan kako za firme tako i za “obične” korisnike. Evo i kućne mreže koju ćemo obraditi:

QoS_01_blog

Koristićemo ADSL modem koji je u modu bridge i Mikrotik koji poziva pppoe konekciju, a sa  NAT / Masquarade opcijom ćemo obezbediti internet svim klijentima(ovo je i najčešći način ostvarivanja konekcije kod nas prilikom korišćenja MT). Deo uređaja nije prikazan, kao i drugi WiFi koji služi za goste a u cilju pojednostavljenog prikaza (ukoliko uspešno odradite ovaj deo apsolutno ne bi trebalo da bude problema u poboljšanju rešenja za vaše potrebe). Uređaji koji se koriste i potencijalni servisi su:

  1. desktop računar (surf, Counter-Strike, skidanje podataka, youtube…)
  2. telefon/tablet koji je preko AP konektovan na istu mrežu (skajp, e-mail, čitanje rss feed-ova)
  3. dreambox satelitski risiver (CS, youtube, surf, torrent)
  4. laptop (telnet, ssh, ftp, remote desktop…)

Kao što vidimo postoji dosta različitih servisa na samo četiri prikazana uređaja koji koriste sasvim drugačije internet protok. Ovde već vidimo da jednostavno deljenje ravnopravno protoka nema smisla, jer ako i rezervišemo određeni saobraćaj za npr Dreambox a ne podelimo ga po prioritetu, najvažniji servis, odnosno CS neće raditi u trenutku kada se skida neki torrent jer je p2p saobraćaj dosta agresivniji pa iako za CS treba par Kb/s slika na televizoru će seckati. Ovakvih “problema” možemo imati na svakom klijentu i tu na scenu stupa QoS.

Prvo pitanje koje mi klijenti i korisnici postavljaju da li se torenti mogu blokirati, a zatim sledi razočarenje kada dobiju odgovor da to nije moguće (MT uspešno poznaje p2p saobraćaj do trenutka kada on počne da se kriptuje). Većina pokušava da blokira p2p saobraćaj što nije dobar pristup već je potrebno imati drugi način razmišljanja. Prvo ćemo obeležiti sav koristan saobraćaj a zatim ga prioritetizovati i odvojiti željenu količinu protoka a sve što nam ne treba ćemo staviti na najniži prioritet ili eventualno blokirati. Postoji više načina za markiranje željenog saobraćaja, pa ćemo krenuti redom kojim bi to trebali i da radite. Prvo ćemo markiranje vršiti po portovima i IP adresama a tek nakon toga treba obeležavanje saobraćaja treba raditi po L7 pravilima (ona su procesorski najzahtevnija pa ih treba ostaviti za kraj da bi što manje saobraćaja prolazilo kroz njih, inače će svaki od trenutno dostupnih routerboard uređaja će “zakucavati” pri malo većem protoku, testirano i na RB1000, RB1100…). Ovde se nećemo baviti dodavanjem svih pravila, L7 regxp, markiranja jer bi to oduzelo dosta prostora a svodi se na jednostavne akcije ako se zna princip koji pokazujemo. Prvo ćemo markirati icmp i dns pomoću source i destination porta.

/ip firewall mangle
add action=mark-packet chain=prerouting comment="DNS - Domain Name System " \
in-interface=pppoe-out1 new-packet-mark=DNS_in passthrough=no protocol=udp src-port=53
add action=mark-packet chain=postrouting dst-port=53 new-packet-mark=dns_out \
out-interface=pppoe-out1 passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment="Ping Internet Control Message Protocol" \
in-interface=pppoe-out1 new-packet-mark=icmp_in passthrough=no protocol=icmp
add action=mark-packet chain=postrouting new-packet-mark=icmp_out \
out-interface=pppoe-out1 passthrough=no protocol=icmp

Treba obratiti pažnju na protokole koji koriste i TCP i UDP kao što je slučaj sa DNS-om pa bi ovde trebalo dodati još jedno pravilo sa TCP protokolom (većina protoka će biti po UDP-u jer DNS zbog brzine primarno njega koristi, ali bez obzira treba podesiti što preciznije markiranje). Kao što vidite na dva mesta u toku paketa vršimo markiranje, jer ukoliko budemo samo koristiti prerouting onda nećemo biti u mogućnosti da kasnije u queue tree koristimo global-out interfejs. Sa prerouting markom možemo ograničiti saobraćaj na global-in i fizičkom interfejsu. Ukoliko imamo saobraćaj koji nije moguće uhvatiti pomoću porta ili L7 izraza a znamo IP odredišnu adresu možemo nju koristiti (za ovaj primer sam uzeo internet radio, a pošto sam hteo više stanica da markiram i prioritetizujem koristio sam address list opciju unutar zaštitnog zida MT-a, koja nam omogućava jedno pravilo i kasniji lakši menadžmet IP adresa).

/ip firewall address-list
add address=193.243.169.34 list=radio
add address=217.26.211.136 list=radio
add address=195.252.107.194 list=radio
add address=77.105.38.192 list=radio

A zatim i markiranje po listi odredišnih IP adresa:

/ip firewall mangle
add action=mark-packet chain=prerouting comment=Radio in-interface=pppoe-out1 \
new-packet-mark=Radio_In passthrough=no protocol=tcp src-address-list=radio
add action=mark-packet chain=postrouting dst-address-list=radio \
new-packet-mark=Radio_Out out-interface=pppoe-out1 passthrough=no protocol=tcp

Ostalo je da markiramo saobraćaj po L7 izrazima a koji nije moguće uraditi na drugi način, u ovom slučaju ćemo prikazati Skype i MSN. Prvo dodamo L7 RegEx (kompletnu listu možete naći ovde):

/ip firewall layer7-protocol
add name=msnmessenger regexp="ver [0-9]+ msnp[1-9][0-9]\? [\t-\r -~]*cvr0\r\
    \n\$|usr 1 [!-~]+ [0-9. ]+\r\
    \n\$|ans 1 [!-~]+ [0-9. ]+\r\
    \n\$"
add name=skypetoskype regexp="^..\02............."

Treba primetiti da za Skype i MSN imamo po još jedno pravilo ukoliko hoćemo da obeležimo pozive na telefon i file transfer respektivno. Sada možemo i izvršiti markiranje sa naprednom opcijom L7:

/ip firewall mangle
add action=mark-packet chain=prerouting \
comment="Skype to Skype - UDP voice call " in-interface=pppoe-out1 \
layer7-protocol=skypetoskype new-packet-mark=skype2skype_in \
passthrough=no protocol=udp
add action=mark-packet chain=postrouting layer7-protocol=skypetoskype \
new-packet-mark=skype2skype_out out-interface=pppoe-out1 \
passthrough=no protocol=udp
add action=mark-packet chain=prerouting comment="MSN Messenger " \
in-interface=pppoe-out1 \
layer7-protocol=msnmessenger new-packet-mark=msn_in passthrough=no
add action=mark-packet chain=postrouting layer7-protocol=msnmessenger \
new-packet-mark=msn_out out-interface=pppoe-out1 passthrough=no

Kada smo obeležili nama sav interesantan saobraćaj potrebno je postaviti pravila koja će markirati preostali deo protoka, naravno ona moraju biti na poslednjem mestu:

/ip firewall mangle
add action=mark-packet chain=prerouting comment=Other-Traffic-In \
in-interface=pppoe-out1 new-packet-mark=Other-Traffic-In passthrough=no
add action=mark-packet chain=postrouting comment=Other-Traffic-Out \
new-packet-mark=Other-Traffic-Out out-interface=pppoe-out1 passthrough=no

Posle toga pristupamo ograničavanju i davanju priotitata određenom tipu saobraćaja. Već smo rekli da ćemo koristiti PCQ queue type:

/queue type
add kind=pcq name=PCQ_download pcq-classifier=dst-address \
pcq-limit=150 pcq-total-limit=5000
add kind=pcq name=PCQ_upload pcq-classifier=src-address \
pcq-limit=150 pcq-total-limit=500

Dodali smo jedan za upload i jedan za download bez podešavanja burst opcije koja može biti vrlo korisna, naručito za ubrzanje klasičnog http “surfa”. Ostalo je još da podesimo queue tree za upload i download:

/queue tree
add limit-at=6M max-limit=6M name=total_adsl_down parent=global-in
add limit-at=650k max-limit=650k name=total_adsl_up parent=global-out
add limit-at=256k max-limit=3M name=skype2skype_down \
packet-mark=skype2skype_in parent=total_adsl_down priority=2 queue=PCQ_download
add limit-at=128k max-limit=512k name=skype2skype_up packet-mark=skype2skype_out \
parent=total_adsl_up priority=2 queue=PCQ_upload
add limit-at=16k max-limit=32k name=icmp_down packet-mark=icmp_in \
parent=total_adsl_down priority=1 queue=PCQ_download
add limit-at=16k max-limit=32k name=icmp_up packet-mark=icmp_out \
parent=total_adsl_up priority=1 queue=PCQ_upload
add limit-at=32k max-limit=5M name=other_down packet-mark=Other-Traffic-In \
parent=total_adsl_down queue=PCQ_download
add limit-at=16k max-limit=512k name=other_up packet-mark=Other-Traffic-Out \
parent=total_adsl_up queue=PCQ_upload

A evo kako bi to izgledalo sa malo više pravila:

IP_FireWall_QoS

Treba obratiti pažnju da je ruter tek restartovan pa zato nema obeleženog saobraćaja u svim pravilima. Sledeća slika je data kao primer, ali pošto je uzeta prilikom testiranja prioriteti i ograničenja možda nisu onakvi kakvi vama odgovaraju pa ih je potrebno promeniti u skladu sa zahtevima.

QueueTree_FireWall_QoS

Ovaj tekst bi trebalo da vam služi samo kao uvod u QoS i mogućnosti Mikrotika a kao što sam rekao, varijanti da se ovaj zadatak reši postoji dosta. Više detalja možete saznati ako poslušate neko od Janisovih predavanja vezanih za QoS.

Mikrotik VPN IPsec

U prethodnom tekstu smo obradili dva vpn tunela na drugom osi nivou koji nemaju enkripciju, sada ćemo se pozabaviti IPsec-om koji radi na trećem nivou i naravno podrazumeva enkripciju svakog paketa. IPsec možemo koristiti bez obzira na način implementacije fizičkog sloja mreže. U ovom članku ćemo obraditi IPsec site to site na dva Mikrotik rutera, sasvim normalno radi MT – Cisco, ali o tome neki drugi put.

Šema mreže na koju će se odnositi konfiguracija je na slici 1.0. Potrebno je postići IP povezanost na računarima PC1 i PC2 preko IPsec tunela koji se završava na R1 (rajco.me Čačak 1) i R2 (rajco.me Čačak 2) ruterima.

IPsec_blog

Pre većine podešavanja na Mikrotiku poželjno je uključiti logovanje koje nam dosta može pomoći pri eventualnom rešavanju problema. Sva podešavanja će biti data prvo preko Winbox-a a zatim i preko komandne linije.

image8

/system logging
add action=memory disabled=no prefix="" topics=ipsec

Kada smo podesili logovanje određene teme na oba mikrotika prelazimo na samo podešavanje IPsec-a. Prvo ćemo dodatai novu IPsec policy na kome imamo dve kartice, General i Action:

image26
 
/ip ipsec policy
add action=encrypt disabled=no dst-address=10.10.11.0/24 dst-port=any \
    ipsec-protocols=esp level=require priority=0 proposal=default \
    protocol=all sa-dst-address=1.1.1.2 sa-src-address=1.1.1.1 \
    src-address=10.10.10.0/24 src-port=any tunnel=yes

Pod karticom General potrebno je dodati source i destination IP opseg koji se koristi u lokalu. Podešavanja će biti ista na oba rutera osim što će podaci za source i destination biti zamenjeni. Na kartici Action je potrebno čekirati opciju Tunnel i postaviti jave IP adrese od oba rutera. Evo kako izgleda podešena polisa na prvom ruteru:

image27

Kada smo završili sa podešavanjem IPsec polisy prelazimo na dodavanje Peers:

image33

/ip ipsec peer
add address=1.1.1.2/32 auth-method=pre-shared-key dh-group=modp1024 \
    disabled=no dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=\
    3des exchange-mode=main generate-policy=no hash-algorithm=md5 \
    lifebytes=0 lifetime=1d my-id-user-fqdn="" nat-traversal=no port=\
    500 proposal-check=obey secret=blog send-initial-contact=yes

U polje Address upisujemo javnu IP adresu drugog rutera (R2, rajco.me Čačak 2), a u polje Secret šifru koja će nam biti ista i na drugom ruteru. Ovde možemo birati metod enkripcije, hash algoritam koji štiti integritet podataka i garantuje autentičnost poruke, kao i Diffie-Hellman grupu koja određuje jačinu ključa koji se koristi u procesu izmene ključeva. Što je veći broj grupe duži je ključ, bezbednost je povećana, ali kao i vreme koje je potrebno da se ključ izračuna i upari.

Nakon ovoga je ostalo da podesimo i R2 sa istim parametrima, samo izmenjenim source i destination IP adresama.

image41

image44

/ip ipsec policy
add dst-address=10.10.10.0/24 sa-dst-address=1.1.1.1 sa-src-address=\
1.1.1.2 src-address=10.10.11.0/24 tunnel=yes

Napomena: Ukoliko primećujete razliku između komande za dodavanje polise na drugom ruteru u odnosu na prvi razlika je u tome što je korišćena compact komanda kod eksporta konfiguracije. Na Mikrotiku je dostupna od verzije 5.12 i omogućava dosta pregledniju konfiguraciju, odnosno daje samo promenjene parametre a ne sve kao što je slučaj bio do sada.

Ostalo je još da dodamo Peers na R2 i time bi osnovno podešavanje IPsec-a site to site na RouterOS-u bilo završeno.

image48

/ip ipsec peer
add address=1.1.1.1/32 secret=blog

Kao što možete videti na sledećoj slici iako je konfiguracija završena još uvek nema informacija o ključevima pod karticom Installed SAs, što znači da nema ni tunela. To se dešava jer još uvek ne postoji interesting traffic odnosno tunel se neće uspostavljati dok ne bude potrebe. Da bi simulirali saobraćaj možemo pingovati IP adresu na drugoj strani VPN-a preko interfejsa ether2.

image57

Prva dva paketa su odbačena dok se tunel nije uspostavio, a zatim ostali idu uspešno i na prvom ruteru možemo videti da je tunel uspostavljen. Ako uključimo log videćemo da je sve u redu na oba rutera:

image61

Takođe da je postojao neki problem mogli bi da vidimo u logovima o čemu se radi, jer smo na početku uključili logovanje IPsec-a.

Ukoliko bi na nekoj od strana imali više subneta jedino što je potrebno uraditi je dodati novu polisu za IPsec sa odgovarajućim lokalnim adresama, dok sve ostalo ostaje isto.

Mikrotik VPN (PPTP i L2TP)

Sve veća je potreba za VPN-om, odnosno Virtuelnim privatnim mrežama. VPN podrazumeva privatnu komunikacionu mrežu koja se koristi za komunikaciju u okviru javne mreže. Tunelovanje je najvažnija komponenta VPN-a i to je metod kojim se koristi infrastruktura jednog protokola za prenos podataka drugog protokola. Odlike VPN-a koje su bitne korisnicima su niska cena, laka implementacija i sigurnost a sve nam to omogućava Mikrotik, odnosno RouterOS.

U zavisnosti od potreba izabraćemo neki od sledećih načina za ostvarivanje VPN-a:

  • PPTP (Point-to-Point Tunel Protocol, dosta korišćen za povezivanje klijentskih uređaja, skoro svi operativni sistemi ga podržavaju, MS od Windows 95 verzije)
  • L2TP (Layer 2 Tunneling Protocol, sam po sebi ne obezbeđuje bezbednost već se oslanja na protokole za eknripciju)
  • IPsec (Može korisiti šifru ili certifikat za pojačanu bezbednost. Ide sam ili u kombinaciji sa nekim drugim tunelom)
  • IPIP (IP over IP, jednostavan protokol koji enkapsulira IP paket u IP, obično se koristi u kombinaciji sa IPsec-om)

Prva dva tunela se ostvaruju na drugom nivou OSI modela, dok je IPsec na trećem (Network Layer).

Podrazumevana podešavanja PPTP servera su:

/interface pptp-server server

set authentication=mschap1,mschap2 default-profile=default-encryption

enabled=no keepalive-timeout=30 max-mru=1460 max-mtu=1460 mrru=disabled

Da bi nam pptp radio potrebno je da ga uključimo sa komandom:

/interface pptp-server> server set enabled=yes 

Isto možemo uraditi i preko Winbox-a:

pptp01

Korisnike možete dodavati iz Winbox-a preko kartice Secrets ili komandom:

ppp_secrets

ppp secret add caller-id="" disabled=no limit-bytes-in=0 limit-bytes-out=0 \local-address=10.10.10.10 name=rajco password=blog profile=default-encryption \remote-address=10.10.10.20 routes="" service=pptp

Gde je name ime korinisnika kojeg kreirate, password  je šifra korisnika, profile služi da ne bi menjali ručno parametre za svaku grupu korisnika, local-address  je ip adresa na strani rutera i može biti ista za više korisnika, dok je remote-address  ip adresa koja će biti dodeljena korisniku. Ukoliko koristmo isti opseg za remote-address i adrese u lokalnoj mreži bitna napomena je da moramo uključiti proxy-arp na lokalnom interfejsu (ako je to interfejs ether2 komanda će izgledati):
 
interface ethernet set arp=proxy-arp ether2
proxy-arp
Za remote-address možemo koristi i IP pool i time smanjiti posao:
 
/ip pool
add name=dhcp_pool1 ranges=192.168.1.2-192.168.1.254
pptp_pool
Sa jednim korisničkim imenom podrazumevano može da se “kači” jedan korisnik, to možemo izmeniti:
 
ppp profile set default only-one=no

ppp-profile

Ukoliko imamo veći broj korisnika najbolje je njima upravljati sa RADIUS serverom (u nekom od narednih tekstova ću napisati uputstvo kako to uraditi sa domen kontrolerom na Windows Serveru 2008R2).
 
Slično ide i za L2TP, potrebno je uklučiti server:
 

interface l2tp-server server set enabled=yes

l2tp-server

Nakon toga kreiramo korisnika:

/ppp secret
add caller-id="" disabled=no limit-bytes-in=0 limit-bytes-out=0 \
local-address=10.20.30.1 name=rajco password=blog profile=default \
remote-address=10.20.30.2 routes="" service=l2tp

l2tp-user

Ukoliko koristimo na drugoj strani internet sa statičkom adresom onda je poželjno tu adresu upisati u polje Caller ID i time povećati stepen bezbednosti.

Evo podešavanja rutera na klijentskoj strani:

/interface l2tp-client
add add-default-route=no allow=pap,chap,mschap1,mschap2 connect-to=1.1.1.1 \
dial-on-demand=no disabled=no max-mru=1460 max-mtu=1460 mrru=disabled name=\
l2tp-out1 password=blog profile=default-encryption user=rajco

l2tp-client

Nakon toga je potrebno dodati statičku rutu koja kaže da sve što krene lokalnom opsegu drugog rutera ide na interface l2tp-rajco, odnosno na ip adresu 10.20.30.2 jer nekada može doći do problema ukoliko u padajućem meniju izaberete interface umesto da ukucate ip adresu. Podrazumeva se da isto ovo uradite na klijentskom ruteru samo što će ip adresa biti 10.20.30.1

/ip route
add disabled=no distance=1 dst-address=192.168.2.0/24 gateway=10.20.30.2 \
scope=30 target-scope=10

ip-route

Nakon toga će vam raditi VPN i računari će biti vidljivi između sebe. Ovo je jedan od najjednostavnijih načina da povežete dve lokacije a kasnije ga možete unapređivati.