Un prefix public pentru clienții VPN: ce strică de fapt
Un prefix public împrumutat nu expune clienții prin el însuși. Capturează destinații care aparțin altcuiva și își schimbă sensul când tunelul cade.
Un pool de clienți ales pentru că numerele arată ordonat este o rută care așteaptă să fie instalată. Prefixul nu trebuie să fie privat pentru ca VPN-ul să funcționeze, iar folosirea unui bloc care aparține altcuiva nu îți expune automat utilizatorii pe internet. Ce face este să dea acestor adrese un alt sens cât timp tunelul este sus, iar apoi din nou alt sens când cade. Parcurge cele cinci verificări de mai jos în ordine și oprește-te acolo unde răspunsul este „alocat în altă parte”.
Alocarea nu este anunțare
Punerea unei adrese pe o interfață de tunel nu o anunță pe internet. Accesibilitatea publică necesită o rută, o cale autorizată și un furnizor dispus să o transporte, și nimic din toate acestea nu apare pentru că un client a primit adresa dintr-un pool. Politica de firewall și autorizarea gazdei sunt din nou decizii separate.
De aceea riscul nu este ceea ce presupun majoritatea. Prefixul împrumutat nu îți face clienții accesibili; face destinațiile altcuiva inaccesibile dinspre clienții tăi, ceea ce este o defecțiune diferită cu un proprietar diferit. Nimeni nu este atacat și niciun anunț nu scapă. Un utilizator pur și simplu nu poate deschide un site care funcționa ieri, iar serviciul de asistență nu are niciun motiv să suspecteze poolul VPN.
Distincția contează când alegi un pool. Dacă singura preocupare ar fi expunerea pe internet, un bloc public ar părea sigur pentru că nimic nu îl anunță. Preocuparea este ruta locală pe care clientul o instalează pentru acel prefix, iar acea rută este instalată indiferent dacă altcineva o poate vedea.
Ce capturează de fapt ruta clientului
Când tunelul urcă, clientul primește o rută pentru prefixul poolului, iar acea rută învinge ruta implicită pentru fiecare destinație din interiorul ei. O cerere către o gazdă legitimă din acel bloc merge acum la VPN în loc de internet. Dacă eșuează, se blochează sau ajunge la serverul greșit depinde de ce face partea ta cu ea.
ip route get 198.51.100.20 ip -br addr show tun0 traceroute -n 198.51.100.20
Rulează căutarea cu tunelul sus și din nou cu el jos. Adresa înseamnă un lucru în primul caz și ceva complet diferit în al doilea, iar orice aplicație care a stocat în cache o conexiune sau o rezoluție de nume peste acea tranziție se va comporta inconsecvent. Acea inconsecvență este mai greu de susținut decât o defecțiune curată, pentru că depinde de moment. Un utilizator care se reconectează în momentul greșit are o experiență diferită de unul care nu o face.
De aceea nici o adresă IP familiară nu este dovadă de identitate. Păstrează validarea certificatului și a numelui de server pentru destinația reală, pentru că adresa numerică la care ai ajuns acum cinci minute poate aparține acum altei conversații.
Compară poolul cu fiecare rețea pe care o cunoști
RFC 1918 rezervă trei blocuri pentru uz privat: 192.168.0.0/16, 172.16.0.0/12 și 10.0.0.0/8. Milioane de organizații separate le refolosesc, așa că privat este o afirmație despre alocare și niciodată o promisiune că nimeni altcineva nu a ales aceleași numere.
Compară poolul candidat cu LAN-urile de birou, VPC-urile din cloud, alte pooluri VPN, legăturile cu parteneri și intervalele pe care lucrătorii la distanță le au probabil acasă. Cazul de acasă nu este un motiv să inventezi un prefix ciudat; este un motiv să păstrezi poolul mic și documentat.
Coordonează alocarea cu cel care deține rutarea și înregistrează calea de întoarcere în același loc. Un pool către care nimeni nu poate ruta înapoi este un pool care va fi redescoperit în timpul unei întreruperi. Pune poolul în același document ca intervalele siturilor, nu într-o configurație de client pe care a editat-o o singură persoană. Documentul este ceea ce face următoarea coliziune evitabilă.
Când adresarea publică este răspunsul corect
Organizațiile cu spațiu global alocat corect pot construi cu siguranță un pool VPN cu adrese publice, iar unele o fac intenționat pentru a evita traducerea. Acel design are în continuare nevoie de rutare, validarea sursei, reguli de acces și autentificarea clienților; alocarea nu oferă niciuna dintre acestea.
Ce oferă este unicitatea, proprietatea de care prefixul împrumutat duce lipsă. Dacă deții blocul, ruta pe care clientul tău o instalează indică adrese care sunt cu adevărat ale tale, iar sensul nu se schimbă când tunelul cade.
Nu adăuga NAT automat pentru a compensa o alegere de pool. Un design privat rutat cu rute de întoarcere explicite este mai curat decât traducerea aplicată pentru că adresarea nu a fost niciodată planificată, iar IPv6 are nevoie de propriul plan deliberat în loc de o copie a presupunerilor IPv4.
Retrage un pool prost fără a pierde accesul
Dacă poolul este deja implementat, fă un inventar înainte de a-l schimba: rezervări de adrese, rute instalate, înregistrări DNS care se rezolvă în bloc, domenii de firewall și aplicațiile care depind de ele. Apoi programează schimbarea cu aceeași grijă ca orice altă tranziție de rutare. Anunță-o oamenilor care o vor observa, pentru că sesiunile lor vor cădea când poolul se mută. O schimbare silențioasă a adresării clienților generează tichete de asistență care par fără legătură cu munca.
Păstrează o cale de recuperare care nu depinde de poolul pe care îl elimini, pentru că momentul în care îl retragi este momentul în care accesul tău la distanță poate dispărea odată cu el. Apoi validează ambele direcții: destinațiile private dorite încă funcționează, iar destinațiile de internet care erau capturate acum se rezolvă către proprietarii lor reali.
Ce vrei este un pool pe care echipa de rețea îl poate aloca, ruta și retrage ca un singur lucru coerent. Un format de adresă singur nu stabilește nici siguranță, nici conectivitate.