Un prefix cu aspect neobișnuit pare o evadare din conflictul de adrese dintre casă și birou, și de obicei nu este. Fiecare bloc din registrul IPv4 pentru scopuri speciale are un proprietar, un scop și un motiv de a exista, iar împrumutarea unuia pentru că pare liniștit mută coliziunea în loc să o elimine. Executați acest lucru ca o secvență: citiți alocarea, inventariați ce se suprapune deja și abia apoi decideți dacă renumărați, traduceți sau generați spațiu nou. Ordinea contează pentru că al treilea pas depinde de ce au găsit primele două.

Citiți alocarea înainte de a împrumuta un interval

Registrul de scopuri speciale al IANA separă intervalele care sunt spațiu privat reutilizabil de intervalele care servesc unui scop tehnic anume. Utilizarea privată, spațiul de adrese partajat, referința și blocurile de documentare arată la fel într-o foaie de calcul și se comportă complet diferit odată ce sunt rutate.

RangeCategoryWhat it means for a VPN plan
172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8RFC 1918 private useReusable by any network, so remote sites may already use the same numbers
100.64.0.0/10Shared address spaceIntended for provider-side carrier-grade NAT arrangements, not a second private pool
198.18.0.0/15BenchmarkingReserved for test traffic measurement; not spare production space
203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24Documentation (RFC 5737)Illustration only; a guide that uses them is not assigning them to you
169.254.0.0/16, 240.0.0.0/4Link-local, reservedNever a routed site subnet, whatever the prefix length suggests

Două prefixe care diferă doar în al doilea octet nu sunt același bloc: 198.18.0.0/15 poartă rezervarea de referință, în timp ce 192.18.0.0/16 nu poartă nimic de acest fel. Un număr care doar seamănă cu un interval rezervat nu îi moștenește sensul. Această confuzie este destul de comună pentru a merita o a doua privire înainte de a ajunge într-o regulă de firewall.

Produsele folosesc uneori deliberat un interval special în cadrul unei suprapuneri coordonate, iar acesta este designul lor care trebuie documentat. Asta nu face din același interval spațiu liber pentru o rețea LAN nelegată. Nici spațiul public nu este o ascunzătoare: o rută privată către o adresă care aparține altcuiva deturnează traficul destinat destinației sale legitime.

Inventariați suprapunerile pe care le aveți deja

Înainte de a alege un prefix, enumerați fiecare rețea care va fi accesibilă din tunel. Siturile, grupurile de clienți, VPC-urile din cloud și legăturile cu parteneri contează toate, iar legătura cu partenerul este cea pe care oamenii o uită până când prima încercare de conectare eșuează.

ip -4 route show table all
ip -6 route show
ip -br addr
ip route get 192.168.1.10

Puneți rezultatele într-un singur tabel cu proprietarul fiecărui interval alături. Un interval pentru care nu puteți numi un proprietar este un interval pe care nu îl veți putea renumăra mai târziu, iar inventarul este cel care transformă o discuție despre prefixe «neobișnuite» într-o decizie despre numere concrete. Vă spune și dacă conflictul pe care încercați să îl evitați este real sau imaginat.

Dacă rețeaua de acasă a unui lucrător la distanță folosește același prefix ca LAN-ul biroului, acel conflict este vizibil în inventar și poate fi tratat explicit. Nu este dovada că un bloc de referință ar fi o alegere deșteaptă, iar tratarea lui astfel este modul în care se creează următoarea coliziune.

Generați o ULA unică în loc să copiați un prefix

IPv6 rezolvă problema reutilizării cu un alt mecanism în loc de un număr mai frumos. RFC 4193 definește adrese locale unice atribuite local cu un identificator global pseudo-aleator de 40-bit, ceea ce vă dă un /48 pentru un sit foarte improbabil să se ciocnească cu al altcuiva. Probabilitatea este mare, nu absolută, iar un prefix ULA tot nu oferă accesibilitate la internet.

openssl rand -hex 5

Zece cifre hexazecimale sunt patruzeci de biți. Puneți fd în față și grupați-le în /48: o ieșire 3f9c1a7b02 devine fd3f:9c1a:7b02::/48. Generați câte unul pentru fiecare sit și notați-l, în loc să lipiți același fd00::/48 comod în fiecare implementare.

Apoi confirmați că întreaga cale vorbește într-adevăr IPv6. Clienții, gateway-ul, rutele, DNS-ul privat și politica de serviciu trebuie să fie toate de acord, iar atribuirea unui prefix tunelului nu face ca o aplicație doar IPv4 să îl folosească.

Planificați suprapunerea pe care nu o puteți elimina

Unele suprapuneri sunt permanente, de obicei pentru că un partener nu va renumăra și nu îl puteți obliga. Atunci alegeți deliberat un mecanism acceptat: renumărare de partea dumneavoastră, un context de rutare izolat sau traducere explicită la o frontieră. Alegerea deliberată înseamnă să scrieți pe care l-ați ales și de ce au fost respinse celelalte două. Acea notă este ceea ce o viitoare revizuire a modificărilor va citi cu adevărat.

Traducerea trebuie să păstreze calea de întoarcere, ceea ce înseamnă să înregistrați atât prefixul original, cât și pe cel prezentat și să le potriviți cu numele DNS private care se rezolvă în ele. Un alias mapat poate face o conexiune lipsită de ambiguitate; nu face adresele originale unice global și nu va supraviețui unui al doilea partener suprapus fără o a doua mapare.

Notați alocarea împreună cu excepția ei

Încheiați cu un document care listează fiecare prefix, categoria lui, proprietarul lui și motivul alegerii. Adăugați excepțiile cu regula lor de traducere sau renumărare și data la care cineva le-a aprobat. Păstrați-l lângă regulile de firewall care îl implementează, nu într-un wiki pe care nimeni nu îl deschide în timpul unui incident. Documentul este livrabilul, nu un rezumat al lui.

Acea înregistrare este ceea ce împiedică următorul inginer să caute un număr cu aspect mai ciudat, și așa este redescoperită această problemă la fiecare câțiva ani sub un nume nou. Oferă, de asemenea, revizuirii modificărilor ceva concret de aprobat în loc de o opinie despre prefixe. Scrieți-o o dată, la sfârșitul alocării, cât timp raționamentul este încă în fața dumneavoastră.

Articole similare