Cum să planificați un bazin de adrese pentru clienții VPN care se potrivește
Alegeți bazinul în câmpul serverului, apoi citiți adresa pe care clientul o primește efectiv, urmăriți răspunsul înapoi și notați intervalul, modul, ruta și sfera DNS.
Începeți în câmpul bazinului de pe serverul VPN, nu într-o foaie de calcul. Ce scrieți acolo devine spațiul de adrese intern pentru fiecare client care se conectează ulterior, iar acesta trebuie să coexiste cu LAN-ul pe care ajung acei clienți, cu site-urile rutate din spatele lui și cu orice adresă pe care clientul o are deja acasă. Conectați un client imediat ce bazinul este salvat, pentru că acea primă conexiune vă spune dacă valoarea funcționează în practică. De acolo turul se extinde spre exterior: adresa pe care clientul a primit-o, calea pe care merge un răspuns și înregistrarea pe care o lăsați în urmă.
Începeți la câmpul bazinului, înainte de a se conecta vreun client
Fiecare produs expune asta diferit, așa că găsiți obiectul care alocă efectiv adrese. OpenVPN are o directivă de bazin pe partea de server care distribuie următoarea adresă liberă, o poartă IKEv2 are o secțiune de bazin legată de configurația perechii, iar WireGuard nu are niciuna pentru că fiecare pereche își poartă propria adresă în fișierul său de configurare. O directivă de bazin și o adresă per pereche nu sunt interschimbabile, iar editarea celei greșite risipește restul turului.
Odată ce aveți câmpul, enumerați intervalele care există deja: LAN-ul biroului, fiecare site rutat, VPC-ul din cloud și orice alt bazin aflat încă în uz. Suprapunerea se decide prin aritmetica prefixului, nu prin faptul că numerele de gazdă par familiare, așa că comparați agregatul cu fiecare dintre acele intervale. Două intervale care amândouă arată ca 10.x sunt inofensive când agregatele lor nu se intersectează și un incident de suport când se intersectează.
Apoi decideți dacă adresa este o funcție de cine se conectează sau de când se conectează. Alocarea dinamică oferă ce este liber, în timp ce alocarea pe identitate leagă o adresă fixă de o acreditare. Notați alegerea, pentru că schimbă cum ar trebui să arate o reconectare mai târziu.
Citiți adresa pe care clientul a primit-o efectiv
Conectați un client și citiți ce raportează tunelul, nu ce a promis bazinul. Clientul își afișează adresa internă în starea conexiunii, iar pe Linux interfața o poartă direct.
Comparați acea adresă cu intervalul pe care l-ați salvat. Dacă se află în afara intervalului, priviți o altă cale de alocare decât cea pe care ați editat-o. Verificați și lungimea prefixului, pentru că un client cu /32 nu are pereche pe legătură și trimite fiecare destinație prin ruta sa implicită.
ip -4 addr show tun0
ip route get 192.168.50.20
Un client care se conectează de la un router de acasă ce folosește același interval se va conecta și apoi nu va ajunge aproape nicăieri. Clientul își păstrează ruta locală pentru acel prefix, așa că adresa tunelului se ciocnește cu rețeaua din spate și traficul iese prin interfața greșită. Acel caz nu poate fi reparat pe server; remediul documentat este renumerotarea rețelei de acasă sau alegerea unui interval de bazin suficient de îndepărtat încât coliziunile să rămână rare. Notați și defecțiunea, și remediul, pentru că serviciul de asistență îl va întâlni din nou.
Reconectați același client și urmăriți adresa. Un bazin dinamic poate returna aceeași valoare sau una diferită, iar ambele sunt corecte, în timp ce un bazin pe identitate care schimbă adresa nu respectă legătura. Verificarea durează secunde și decide dacă modul notat în prima secțiune este modul în vigoare.
Urmăriți un răspuns înapoi de la serviciu
Bazinul funcționează doar când răspunsurile pot călători înapoi la el. Un serviciu din LAN răspunde la adresa internă, deci poarta lui are nevoie de o rută pentru bazin sau de o traducere în fața serviciului. Când o cerere sosește prin tunel și răspunsul pleacă pe o altă cale, un firewall cu stare sau o verificare a căii inverse îl aruncă, iar clientul vede un serviciu care se conectează și apoi se blochează. Puneți bazinul în proiectarea rutării ca un singur bloc rezumabil, în loc să adăugați rute pentru fiecare gazdă.
Traducerea schimbă ce vede restul sistemului. Când sursa este rescrisă, adresa din firewall-ul gazdei și din jurnalul aplicației este cea tradusă, așa că o regulă scrisă împotriva adresei bazinului nu se potrivește cu nimic și o linie de jurnal nu poate fi urmărită până la un client. Documentația strongSwan despre redirecționare acoperă jumătatea dinspre server a acelei căi pentru o poartă IKEv2. DNS poartă aceeași constrângere, pentru că un nume care se rezolvă la o adresă ce nu poate fi atinsă de client eșuează mai târziu și în altă parte.
Doi clienți, apoi o revocare
Conectați doi clienți simultan și citiți ambele adrese. Ele trebuie să fie distincte, utilizabile și în interiorul bazinului, iar fiecare trebuie să atingă serviciul căruia îi este destinat. Un bazin care distribuie adrese duplicate se arată de obicei aici, nu la primul test cu un singur client.
Revocați o acreditare în timp ce celălalt client rămâne conectat, apoi încercați serviciul din clientul care a supraviețuit. O revocare care tulbură cealaltă sesiune indică stare partajată, cel mai adesea o acreditare sau o adresă refolosită între dispozitive. Reconectați clientul revocat și confirmați că îi este refuzat accesul, în loc să primească adresa eliberată.
Încheiați cu o destinație care ar trebui refuzată. Un client care atinge tot a fost conectat, nu testat.
Scrieți cele patru valori acolo unde le va găsi următoarea schimbare
Înregistrarea este scurtă: intervalul și prefixul bazinului, modul de alocare, calea de întoarcere sau traducerea în uz și sfera DNS care răspunde pentru acele destinații. Puneți-o lângă configurația serverului, nu într-un tichet, și datați-o. Cine schimbă mai târziu una dintre cele patru are nevoie de celelalte trei în față, pentru că o redimensionare a bazinului rupe ruta, iar o schimbare de rută rupe răspunsul DNS.
Păstrați alături nota de proprietate: intervalul tunelului aparține serverului VPN, iar o rezervare făcută în sfera DHCP a LAN-ului nu rezervă nimic pentru un client din interiorul tunelului. Acea singură linie previne cea mai frecventă relucrare, în care cineva adaugă o rezervare și se așteaptă ca adresa tunelului să o urmeze.