Bæta einka-IPv6 við OpenVPN-rannsóknarstofu, einum eftirlitspunkti í einu

Hafðu ytri flutninginn á IPv4 og útvíkkaðu innra skipulagið. Fimm eftirlitspunktar: forskeyti, hjálpari, rútupush, framsending og prófun frá biðlara.

Þú hefur þegar biðlara sem tengist yfir IPv4 og nær einkareknu IPv4-vinnuálagi bak við þjóninn. Markmiðið er að ná einkareknu IPv6-vinnuálagi um sama göngin án þess að snerta ytri flutninginn. Þessi röð skiptir máli: ytri leiðin helst IPv4 og aðeins innra vistfangaskipulagið, leið biðlarans og endurleiðin frá þjóninum að LAN breytast. Fimm eftirlitspunktar, hver með einhverju áþreifanlegu til að skoða áður en haldið er áfram.

Eftirlitspunktur einn: tengingin sem virkar þegar

Tengdu biðlarann og staðfestu IPv4-leiðina áður en þú bætir einhverju við. Göngin sem virka gefa þér grunnlínu sem aðgreinir nýja IPv6-villu frá gömlu tengingarvandamáli. Þau segja þér líka hvaða þjóns-tilvik þú ert í raun að breyta.

Skráðu hópinn, netlögunina og push-uðu leiðirnar sem þú treystir þegar á. IPv6-vinna útvíkkar þessa stillingu; hún kemur ekki í staðinn.

Eftirlitspunktur tveir: veldu innri forskeytin

Veldu ULA /48 fyrir staðinn og skerðu tvö /64 úr henni: eitt fyrir biðlara ganganna, eitt fyrir LAN-hlutann sem hýsir IPv6-vinnuálagið. Búðu til 40-bita alheims-ID í stað þess að afrita dæmisforskeyti, og athugaðu bæði undirnetin gagnvart hverju neti sem staðurinn beinir þegar:

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

Tvö óháð /64 koma í veg fyrir að biðlarahópurinn sé skorinn út úr LAN-hlutanum, sem skiptir máli síðar þegar þú skrifar endurleiðina. Gildin hér að ofan eru eitt útunnið dæmi, ekki forskeyti til endurnotkunar.

Eftirlitspunktur þrír: bættu við hjálparanum og rútupushinu

Lestu núverandi stillingu þjónsins áður en þú bætir einhverju við. Önnur eintak af fyrirliggjandi tilskipun sameinast ekki því fyrra, og villan sem kviknar nefnir tilskipunina, ekki IPv6. Með fyrirliggjandi IPv4-hjálpara útvíkka tvær línur hann. Hver þeirra svarar annarri spurningu:

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

Fyrsta er þægilegur hjálpari sem stillir viðmótið og biðlarahópinn. Önnur nefnir LAN-áfangastaðinn sem biðlarinn á að ná. Að gefa biðlara IPv6-vistfang segir honum ekki hvaða net eru bak við þjóninn, svo báðar línurnar eru nauðsynlegar.

Hjálparinn lifir ekki samhliða kyrrstæðum IPv6-hópi né nopool. Ef uppsetningin úthlutar vistföngum viljandi kyrrstætt skaltu halda þeirri stefnu og hanna IPv6-jafngildið skýrt í stað þess að eyða stefnunni til að passa dæmi.

Eftirlitspunktur fjórir: framsending og svarleiðin

Kveiktu á IPv6-framsendingu á þjóninum í gegnum eigin stillingareiganda kerfisins, ekki með einnota keyrsluskrifi sem þú gleymir. Keyrsluformið er gagnlegt fyrir fljótlegt próf. Varanleg stilling á heima í drop-in skrá sem neteigandi dreifingarinnar les:

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

Framsending breytir IPv6-hegðun hýsilsins umfram leiðsögn pakka. Hýsill sem tók við tilkynningum leiðsögumanns sem biðlari hættir því á sama hátt þegar hann fer að senda áfram. Þess vegna þarf vél þar sem IPv6-uplink er háð RA skýra áætlun fyrir þann uplink.

Gefðu LAN-inu síðan leið til baka í gönguhópinn. IPv6-gátt vinnuálagsins er LAN-leiðsögumaðurinn, ekki VPN-þjónninn, svo leiðin á heima á þeim leiðsögumanni og vísar á LAN-vistfang þjónsins:

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

Haltu ICMPv6-gerðunum sem hlekkurinn þarf, þar á meðal MTU-viðbrögðum leiðarinnar. IPv4-eldveggjarregla þýðir ekki IPv6-regla, og almennt IPv6-bann brýtur uppgötvun nágranna á þann hátt sem lítur út eins og leiðsagnarbilun.

Eftirlitspunktur fimm: lestu biðlarann, prófaðu svo

Tengdu biðlarann aftur og lestu vistföngin sem hann fékk í raun í stað þess að álykta þau út frá hjálparavistfangi þjónsins. Viðmótslistinn sýnir báðar fjölskyldurnar á sama tæki:

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

Leið sem velur göngin sannar að biðlarinn veit hvert á að senda pakkann. Hún sannar ekki að þjóninn sendi hann áfram, að LAN-leiðsögumaðurinn hafi endurleiðina, eða að forritinu sé heimilt að svara.

Prófaðu forritið sjálft yfir hverja fjölskyldu í röð og endurtaktu eftir endurtengingu og eftir endurræsingu hýsilsins. Leið eða sysctl sem lifir aðeins til endurræsingar er próf, ekki hönnun.

Birtu AAAA-færslu aðeins þegar IPv6-leiðin svarar frá enda til enda. DNS sem er spurt yfir IPv4 getur enn skilað IPv6-vistfangi, svo leysanlegt nafn er ekki sönnun þess að eitthvað hlusti. RFC 4193 ULA-leiðbeiningarnar fjalla um að búa til alheims-ID sem gerir þessi forskeyti þín í stað eftirrits.

Tengdir greinar