Shtoni IPv6 private në një laborator OpenVPN, një pikë kontrolli në një herë

Ju tashmë keni një klient që lidhet përmes IPv4 dhe arrin një ngarkesë pune IPv4 private pas serverit. Qëllimi është të arrihet një ngarkesë pune IPv6 private përmes të njëjtit tunel pa prekur transportin e jashtëm. Ky rend ka rëndësi: rruga e jashtme mbetet IPv4, dhe ndryshojnë vetëm plani i brendshëm i adresave, rruga e klientit dhe rruga e kthimit nga serveri në LAN. Pesë pika kontrolli, secila me diçka konkrete për t'u parë përpara se të vazhdoni.

Pika e parë e kontrollit: lidhja që tashmë funksionon

Lidhni klientin dhe konfirmoni rrugën IPv4 përpara se të shtoni ndonjë gjë. Një tunel që funksionon ju jep një vijë bazë që ndan një gabim të ri IPv6 nga një problem i vjetër lidhjeje. Ju tregon gjithashtu se cilën instancë të serverit po redaktoni në të vërtetë.

Shënoni pishinën, topologjinë dhe rrugët e shtyra ku mbështeteni tashmë. Puna me IPv6 e zgjeron atë konfigurim; nuk e zëvendëson.

Pika e dytë e kontrollit: zgjidhni prefikset e brendshme

Zgjidhni një ULA /48 për faqen dhe prisni dy /64 prej saj: një për klientët e tunelit, një për segmentin LAN që mban ngarkesën IPv6. Gjeneroni ID-në globale 40-bitëshe në vend që të kopjoni një prefiks shembull, dhe kontrolloni të dy nënrrjetet kundrejt çdo rrjeti që faqja ruton tashmë:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Dy /64 të pavarura pengojnë prerjen e pishinës së klientëve nga segmenti LAN, gjë që ka rëndësi më vonë kur shkruani rrugën e kthimit. Vlerat më sipër janë një shembull i përpunuar, jo një prefiks për ripërdorim.

Pika e tretë e kontrollit: shtoni ndihmësin dhe shtytjen e rrugës

Lexoni konfigurimin aktual të serverit përpara se të shtoni ndonjë gjë. Një kopje e dytë e një direktive ekzistuese nuk bashkohet me të parën, dhe gabimi që del emërton direktivën, jo IPv6. Me ndihmësin IPv4 ekzistues, dy rreshta e zgjerojnë atë. Secili përgjigjet një pyetjeje tjetër:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

E para është një ndihmës i përshtatshëm që konfiguron ndërfaqen dhe pishinën e klientëve. E dyta emërton destinacionin LAN që klienti duhet të arrijë. Dhënia e një adrese IPv6 klientit nuk i thotë se cilat rrjete ekzistojnë pas serverit, prandaj nevojiten të dy rreshtat.

Ndihmësi nuk bashkëjeton me një pishinë statike IPv6 apo me nopool. Nëse vendosja i cakton adresat qëllimisht në mënyrë statike, mbajeni atë politikë dhe projektoni ekuivalentin IPv6 në mënyrë të qartë në vend që të fshini politikën për t'u përshtatur me një shembull.

Pika e katërt e kontrollit: përcjellja dhe rruga e përgjigjes

Aktivizoni përcjelljen IPv6 në server përmes pronarit të konfigurimit të sistemit, jo me një shkrim të vetëm në kohë ekzekutimi që do ta harroni. Forma e kohës së ekzekutimit është e dobishme për një test të shpejtë. Konfigurimi i përhershëm i takon një skedari drop-in që lexohet nga pronari i rrjetit të shpërndarjes:

sysctl -w net.ipv6.conf.all.forwarding=1

Përcjellja ndryshon sjelljen IPv6 të hostit përtej rutimit të paketave. Një host që pranonte njoftime ruteri si klient ndalon së bëri këtë në të njëjtën mënyrë sapo fillon të përcjellë. Prandaj një makinë, lidhja lart e së cilës IPv6 varet nga RA, ka nevojë për një plan të qartë për atë lidhje.

Më pas, jepini LAN-it një rrugë kthimi drejt pishinës së tunelit. Porta IPv6 e ngarkesës është ruteri i LAN-it, jo serveri VPN, prandaj rruga i takon atij ruteri dhe tregon adresën LAN të serverit:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Mbajini llojet ICMPv6 që i nevojiten lidhjes, duke përfshirë reagimin e MTU-së së rrugës. Një rregullfirewall IPv4 nuk nënkupton një rregull IPv6, dhe bllokimi i plotë i IPv6 prish zbulimin e fqinjëve në mënyra që duken si defekt rutimi.

Pika e pestë e kontrollit: lexoni klientin, pastaj testoni

Lidhni përsëri klientin dhe lexoni adresat që mori vërtet, në vend që t'i nxirrni nga adresa e ndihmësit të serverit. Lista e ndërfaqeve tregon të dyja familjet në të njëjtin pajisje:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

Një rrugë që zgjedh tunelin dëshmon se klienti e di ku ta dërgojë paketën. Nuk dëshmon se serveri po e përcjell, se ruteri i LAN-it e ka rrugën e kthimit, ose se aplikacionit i lejohet të përgjigjet.

Testoni vetë aplikacionin për secilën familje me radhë, pastaj përsëriteni pas një rilidhjeje dhe pas një rinisjeje të hostit. Një rrugë ose sysctl që zgjat vetëm deri në rinisje është test, jo projekt.

Publikoni një regjistrim AAAA vetëm kur rruga IPv6 përgjigjet nga fillimi në fund. DNS-ja e pyetur përmes IPv4 mund të kthejë ende një adresë IPv6, prandaj një emër i zgjidhshëm nuk është provë se diçka po dëgjon. Udhëzimi RFC 4193 për ULA mbulon gjenerimin e ID-së globale që i bën këto prefikse tuajat dhe jo një kopje.