Articolul din articolul Opennet - organizarea accesului utilizatorilor la distanță prin vpn la serverul netbsd (vpn netbsd

software-ul

  • miez
  • Mediul pentru utilizatori

    Acces de la distanță prin VPN

  • fundal
  • Considerații privind siguranța
  • Soluții posibile

    Acces la utilizatorul de la distanță prin intermediul IPsec

  • 1 faza de autentificare IPsec
  • xauth
  • Hibrid auth
  • Configurarea modului ISAKMP
  • NAT Traversal
  • Fragmentarea IKE și ESP
  • Detectarea Dead Peer

    Configurarea gateway-ului VPN

  • Configurarea kernelului
  • Rutarea pachetelor
  • Crearea de certificate
  • Configurarea racoonului (8)
  • Probleme de fragmentare
  • Interacționează cu sistemele de protecție a rețelei
  • VPN și gateway-ul RADIUS

    Clienții VPN

  • Client Cisco VPN
  • racoon (8) ca client: exemplu de configurare
  • Creați și rupeți o conexiune VPN
  • Salvarea parolei Xauth
  • software-ul

    Mediul pentru utilizatori

    Acces de la distanță prin VPN

    Având în vedere dezvoltarea rapidă a conexiunilor DSL, valoarea conexiunii la modem scade, dar rămâne necesitatea unor conexiuni sigure. Aici suntem ajutați de o rețea VPN.

    În acest articol, vom considera accesul numai prin login / password.

    Considerații privind siguranța

    Pentru a crea o conexiune VPN, utilizatorul și serverul trebuie să-și confirme autenticitatea pentru a exclude un atac de tip "man-in-the-middle".

    Sarcina noastră este să asigurăm fiabilitatea gateway-ului VPN. În cazul unei chei predefinite, compromisul său va permite unui atacator să simuleze o poartă de acces, ceea ce va avea consecințe dezastruoase. Pentru a confirma autenticitatea gateway-ului, vom folosi certificate x509. În acest caz. nu vom instala certificate pe partea clientului.

    Soluții posibile

    Acces la utilizatorul de la distanță prin intermediul IPsec

    1 faza de autentificare IPsec

    Prima fază a IPSec este IPsec Key Exchange (IKE) (schimb de chei) și este executată de către daemon IKE; în NetBSD este mai bine cunoscută ca racoon (8). Această fază este proiectată pentru a confirma autenticitatea capetelor de la distanță a conexiunii și pentru a instala cheile utilizate în faza a doua. A doua fază este utilizată la schimbarea cheilor care criptează traficul și poate apărea de mai multe ori pe sesiune. Prima etapă poate fi organizată în două moduri - chei și certificate pre-distribuite. Acest lucru nu ne este potrivit pentru următoarele motive:
    • Cheile predefinite nu sunt legate de numele de utilizator și nu avem instrumentele necesare pentru a le gestiona. Singurul lucru pe care îl putem gestiona este parola de grup.
    • Prima fază este simetrică, ceea ce înseamnă că aveți aceleași chei sau certificate pe ambele părți ale conexiunii. Aceasta nu este metoda noastră.

    Xauth este o extensie IKE și adaugă autentificarea prin login / password după prima fază. Această abilitate elimină jumătate din problemele noastre. Deoarece autentificarea are loc după prima fază, datele transmise sunt deja criptate. Necesitatea unei chei comune sau a unui certificat există, dar cheile sunt nesigure și certificatul va cauza probleme cu utilizatorii, ceea ce nu este absolut necesar.

    Hibrid auth

    Nivelul de protecție al autentificării IPsec + Xauth + Hybrid corespunde utilizării SSH cu autentificare cu parolă.

    Configurarea modului ISAKMP

    NAT Traversal

    Deoarece utilizatorul de la distanță poate fi ascuns în spatele Translator de adrese (NAT), apare problema aplicării IPsec. Când criptează traficul, IPsec utilizează protocolul pe 4 nivele cunoscut sub numele de Encapsulated Security Payload (ESP). Spre deosebire de TCP sau UDP, ESP nu are un număr de port și nu poate trece corect prin NAT.

    RFC 3947 și 3948 descriu metoda încapsulării ESP în extensii UDP și IKE pentru administrarea NAT între punctele finale IPSec. Encapsularea și extensiile sunt mai des cunoscute sub numele de NAT Traversal (NAT-T).

    Fragmentarea IKE și ESP

    Cei mai mulți utilizatori la distanță se vor conecta în cele din urmă prin intermediul modemurilor xDSL. Astfel de modemuri deseori descompun conexiunea sub sarcină mare de pachetele UDP, deoarece producătorii cred că UDP este utilizat doar pentru interogările DNS și elimină interogări mari sau fragmentate. Și cum ne amintim, ESP peste UDP folosește doar pachete UDP mari. Pentru a rezolva această problemă, vom folosi fragmentarea IKE, o altă extensie IKE, care ne permite să fragmentăm pachetele mari. Problema pachetelor mari este rezolvată prin fragmentarea IP înainte de încapsulare în ESP, adică în loc de frag (IP / UDP / ESP / IP), se obține IP / UDP / ESP / frag (IP).

    Detectarea Dead Peer

    Ultima problemă: conexiunea la distanță nu poate fi permanentă, din când în când terminând. Mecanismul IPsec încorporat ar trebui să cheme din când în când a doua fază a IKE pentru a retransmite cheile și, dacă încercarea eșuează, încheiați sesiunea. Acest mecanism nu este foarte convenabil. Pentru testarea regulată a conexiunilor, se folosește o extensie IKE numită Detectarea Peer-Peer (DPP). DPD poate verifica disponibilitatea punctelor extreme cu o multiplicitate de câteva secunde.

    Configurarea gateway-ului VPN

    Configurarea kernelului

    Rutarea pachetelor

    Trebuie să activați redirecționarea pachetelor IPv4:
    Pentru a seta această opțiune în perioada de încărcare, adăugați o oprire în /etc/sysctl.conf:

    Crearea de certificate

    Configurarea racoonului (8)

    Iată un exemplu de fișier de configurare /etc/racoon/racoon.conf:

    Probleme de fragmentare

    Folosind fragmentarea, ESP poate fi schimbat prin tunelul IP cu pachete de orice dimensiune. Dar, există o specificitate atunci când lucrați cu TCP, deoarece pot apărea probleme cu unitatea maximă de transmisie a căii (PMTU). Soluția este de a stabili dimensiunea maximă a segmentului (MSS). Puteți face acest lucru introducând următoarea linie în /etc/ipnat.conf:
    Încărcați configurația:
    Pentru a activa regula în timpul perioadei de încărcare, vom adăuga următoarele în /etc/rc.conf:
    Rețineți că sistemul nu va porni din ipfilter = YES dacă fișierul /etc/ipf.conf nu este prezent. Puteți crea un fișier gol dacă nu aveți nevoie de reguli de filtrare.

    Interacționează cu sistemele de protecție a rețelei

    În soluția descrisă de noi, clientul trebuie să trimită pachetele UDP la portul 500 și să primească un gateway de la portul de 4500 VPN. Primele pachete sunt schimbate între 500 de porturi, iar apoi NAT-T se deplasează la portul 4500. Pentru a lucra la VPN, este necesar să se adapteze corect regulile de pe firewall.

    VPN și gateway-ul RADIUS

    Clienții VPN

    Client Cisco VPN

    Gateway-ul VPN de mai sus este compatibil cu clientul VPN Cisco, configurat pentru modul de grup (la fel ca autentificarea Hybrid). Numele grupului necesar și parola grupului sunt ignorate de racoon (8). dar securitatea conexiunii nu este afectată.

    Nu uitați să trimiteți IPsec pe UDP și să activați NAT-T.

    racoon (8) ca client: exemplu de configurare

    Creați și rupeți o conexiune VPN

    Salvarea parolei Xauth

    Dacă nu doriți să imprimați de fiecare dată parola Xauth, puteți să o salvați în fișierul pre-cheie al cheii pre-partajate (PSK). Adăugați fișierul /etc/racoon/racoon.conf în secțiunea de la distanță:
    Apoi adăugați numele de utilizator și parola în fișierul /etc/racoon/psk.txt:
    Acum, executând următoarea comandă, veți crea o conexiune fără a introduce o parolă: