În cazul meu, a fost necesar să se conecteze mai multe ramuri la distanță cu rețelele lor locale la biroul central și, de asemenea, să se asigure munca unor angajați de acasă.
Aspectul rețelei ar trebui să arate astfel:
În acest caz, IP alb este disponibil numai la biroul central. Ca toate serverele proxy, sunt folosite computerele cu OpenSuSE Linux - din cauza ușurinței de configurare, toate acțiunile nu durează mai mult de o jumătate de oră (pentru servere).
Mai întâi trebuie să instalați pachetele OpenVPN pe toate serverele și pe fiecare client care se va conecta direct la serverul principal.
În primul rând, pregătim certificate pentru clienți și servere:
copiați scripturile easyrca la unul dintre directoarele utilizatorului,
completați datele din fișierul vars cu valorile corespunzătoare (lungimile și datele de expirare ale certificatelor, numele companiei, locurile etc.)
executați sursa ./vars pentru a seta variabilele noastre,
apoi ștergeți tastele care pot fi din setările anterioare: ./clean-all
și formați certificatul rădăcină: ./build-ca
Acum puteți continua să generați cheile:
pentru server: ./build-key-server <имя сервера/сертификата>
pentru clienți: ./build-key <имя клиента/сертификата>
ca numele certificatului de server este indicat să se precizeze «serverul», cât și pentru client - numele unității la care certificatul se referă la (de exemplu, client_msk_timirjazevskaya, client_msk_marjina_rosha, client_spb_gorkovskaya etc.)
Apoi, vom configura parametrii de criptare Diffie-Hellman Protocol: ./build-dh
Acum, în dosarul cu chei sunt toate fișierele necesare care trebuie plasate în directorul / etc / openvpn de pe server și clienții după cum urmează:
- ca.crt - certificat rădăcină, pe server și pe client
- ca.key - cheia pentru semnarea certificatelor, lăsați-le în dosar cu cheile și nu le dați nimănui :)
- dh1024.pem - parametrii de criptare, pe server
- server.crt - certificat server, server
- server.key - cheia privată a certificatului de server, pe server, cheia este secretă
- client _ * .crt - certificate de clienti, pe masinile corespunzatoare ale clientilor
- client _ *. cheie - cheia privată a certificatelor client, pe mașinile corespunzătoare clienților, cheile sunt secrete
copiați acum fișierul de configurare a serverului din dosarul de eșantionare în dosarul cu setări openvpn:
cp /usr/share/doc/packages/openvpn/sample-config-files/server.conf / etc / openvpn /
În acest fișier nu suntem mulțumiți de anumiți parametri:
împingeți "ruta 192.168.0.0 255.255.240.0" # traseu către rețeaua internă pentru clienți
client-config-dir ccd # dosare de configurare pentru clienți (pentru atribuirea IP-ului static) (creați în / etc / openvpn)
client-client # rutare între clienți
up "serviciu SuSEfirewall2_setup restart" # reporniți paravanul de protecție atunci când începe serviciul
down "serviciul SuSEfirewall2_setup restart" # și când este oprit. Datorită faptului că dispozitivele,
# a creat openvpn virtual și există numai în timp ce rulează
traseu 192.168.1.0 255.255.255.0 10.8.0.2 # traseu către rețeaua de sucursale 1
traseu 192.168.2.0 255.255.255.0 10.8.0.3 # traseu spre rețeaua de sucursale 2 (a se vedea diagrama)
# și rute în rețeaua altor sectoare.
Acum trebuie să configurați firewall-ul de pe server și client, pentru ca acesta trece cererea de la VPN în rețeaua internă (clienții fără rețele interne și nu publică nicio resursă nu este necesar) (presupus de asemenea că firewall-ul este deja configurat ca o poarta de acces la Internet pentru rețeaua internă) :
apoi toate acțiunile sunt efectuate în / network / Firewall / SuSEfirewall2 /
FW_DEV_INT adăugați un spațiu după numele interfeței openvpn (tap0) - adăugați-o în zona interioară
FW_ALLOW_CLASS_ROUTING int - permite rutarea între interfețele interne ale zonei interioare
FW_REJECT_INT nu - nu respingeți pachetele din zona interioară - nu neapărat
FW_FORWARD_ALLOW_BRIDGING da - permite punțile de rețea, chiar dacă nu există o interfață de tip pod
toate, acum puteți salva toate setările și rula openvpn (pe servere și pe clienți):
serviciul openvpn start
ar trebui returnat făcut, dispozitivul tap0 ar trebui să apară în lista dispozitivelor de rețea
ifconfig
tap0 Legătură encap: Ethernet HWaddr 00: FF: A0: B4: 72: BF
inet addr: 10.8.0.1 Bcast: 10.8.0.255 Mască: 255.255.255.0
UP MULTICAST MTU: 1500 Metric: 1
RX pachete: 611222 erori: 0 abandonate: 0 depășiri: 0 cadru: 0
Pachete TX: 539849 erori: 0 abandonate: 0 depășiri: 0 operator: 0
coliziuni: 0 txqueuelen: 100
bytes RX: 108883515 (103,8 Mb) octeți TX: 490 615 141 (134.9 Mb) tap0 Link Encap: Ethernet HWaddr 00: FF: A0: B4: 72: BF
inet addr: 10.8.0.1 Bcast: 10.8.0.255 Mască: 255.255.255.0
UP MULTICAST MTU: 1500 Metric: 1
RX pachete: 611222 erori: 0 abandonate: 0 depășiri: 0 cadru: 0
Pachete TX: 539849 erori: 0 abandonate: 0 depășiri: 0 operator: 0
coliziuni: 0 txqueuelen: 100
RX octeți: 108883515 (103,8 Mb) TX octeți: 141490615 (134,9 Mb)
în rute puteți înregistra automat:
ip
192.168.2.0/24 via 10.8.0.3 dev tap0
192.168.1.0/24 via 10.8.0.2 dev tap0
10.8.0.0/24 dev tap0 proto kernel domeniu legătură src 10.8.0.1
192.168.0.0/24 dev eth0 proto kernel domeniu legătură src 192.168.0.100
Totul, instalarea este terminată, acum la prima ocazie, clienții se vor conecta la server și vor compila o rețea locală virtuală ca în diagrama de la începutul articolului, în care puteți publica în siguranță servere și resurse. Internetul va funcționa așa cum a făcut-o, această schemă funcționează pe lângă conexiunile VPN deja existente etc. În cazul în care clienții care sunt conectați direct la server utilizează networkmanager - este necesar un pachet networkmanager-openvpn, pentru ferestre configurația este aproximativ aceeași.
de ce trebuie să arunci L2, adică dev tap? Decât dev dev subnet de topologie nu a fost potrivit?
incorect specificate exclud masca și, în general, exclud subneturile pentru clienții vpn
Care este eroarea, după cum credeți că ar trebui să fie?
în distribuții comune în cursul iptables.
Aici toată lumea decide pentru sine. 19 oameni, aparent, a fost util, dar nu văd un minus de la tine :)
proto tcp este mai rezistent, deși mai puțin economic.
când este conectat prin 3g la rdp peste acest VPN - diferența este vizibilă pentru ochi și nu este în favoarea opțiunii cu tcp. Și fiabilitatea este asigurată de faptul că același tcp merge deja în interiorul tunelului.
Da, și orice port poate fi atribuit.
cu subnet de topologie la fel. Numai date inutile sunt mai puține.
Incorect specificate exclud masca și, în general, subrețele excluse pentru vpn-clienți Care este eroarea, după cum credeți că ar trebui să fie?
Restricție: rețeaua de clienți interni nu trebuie să se suprapună cu următoarele rețele:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
UPD doar la rețeaua clientului 192.168.0.0/28 cea mai mare parte a economiei va funcționa. Conform regulii de selectare a traseului pentru masca mai mare.
când este conectat prin 3g la rdp peste acest vpn - diferența este vizibilă pentru ochi și nu este în favoarea opțiunii cu tcp
Folosesc în mod constant tableta, nu văd nici o diferență, totul este destul de confortabil. dev tun, subnet de topologie, proto tcp, tun-mtu 1024.
În plus, atunci când un dump 3G, de exemplu, pe drum, reconectarea are loc 10-12 secunde mai târziu, față de 20-30 cu UDP. costurile ping 10
Este posibil să se scrie încă că poate fi utilizat 10.8.0.0 la furnizorul din interior, iar apoi (într-o anumită situație) sunt posibile grinzi
Doar aici sunt puține, deoarece client, această rețea nu este necesară. Și măștile sunt diferite. Furnizorii folosesc rar / 24 pe segmente gri, de obicei mai puțin.
Cu toate acestea, dacă preferați să mergeți acasă la angajați să reconfigurați routerele - bine ai venit. Dar - după ore și gratuit.
Și în ceea ce privește iptables - în nici un fel nicks howto nu veți găsi instrucțiuni pentru a utiliza shell-uri suplimentare. Totul pe iptables -A. Pentru că aceasta este o echipă universală, spre deosebire de ea.
Dar asta, îmi pare rău, a clipit.