Dijeljenje vašeg /64 ne usmjerava IPv6 na VPN klijente

Klijent prikazuje globalnu IPv6 adresu, handshake je završen i ništa se ne vraća s interneta. Postavka poola izgleda ispravno jer jest ispravna; adresa je važeća i tunel je nosi. Ono što ne uspijeva je dostava, a dostava zavisi od odluke donesene iznad VPN servera na koju nijedna konfiguracija na strani klijenta ne može uticati.

Mit: dio vašeg /64 je već dostupan

Priča je privlačna: server ima javni /64, prepolovite ga, drugu polovinu dajte VPN poolu i ti klijenti su sada na internetu. Dijeljenje prefiksa zaista dodjeljuje adrese bez kolizija. Ali ne mijenja kako upstream mreža odlučuje kuda treba ići paket za jednu od tih adresa.

IPv6 nema zadani sloj za prevođenje na koji bi se oslonio, pa povratni put mora postojati kao usmjeravanje ili kao dostava na nivou linka. Paket adresiran na tunelsku adresu klijenta stiže na upstream ruter, a taj ruter donosi odluku o prosljeđivanju iz vlastite tablice. Ako tablica pokazuje na fizički link, paket ide tamo bez obzira na to što vaš VPN server misli.

To je cijeli kvar: smjer naprijed radi jer ga vaš server šalje, a povratni smjer umire jedan hop dalje jer upstream nikada nije saznao da klijent postoji.

Šta dostava na linku zapravo zahtijeva

Kada upstream smatra da je cijeli /64 na fizičkom linku, rješava svaku odredišnu adresu otkrivanjem susjeda. Šalje zahtjev na taj link i očekuje da vlasnik adrese odgovori. VPN klijent iza tunela nije na tom linku i ne može odgovoriti, pa zahtjev ostaje bez odgovora i paket se odbacuje.

Izdvajanje /65 ne mijenja to očekivanje. Upstream i dalje tretira raspon kao da je na linku, jer jedino što bi ga razuvjerilo je ruta ili proxy koji odgovara u ime klijenta. Ni jedno se ne pojavljuje jer ste uredili VPN konfiguraciju. Upravo ta praznina objašnjava zašto pool može savršeno raditi među vlastitim klijentima i ipak biti nedostupan s bilo kojeg drugog mjesta.

Proxy otkrivanje susjeda je mehanizam koji može premostiti dva svijeta. Gateway odgovara na zahtjeve za konkretne klijentske adrese koje posjeduje i prosljeđuje promet u tunel. Radi, i mora biti ograničen tačno na te adrese s životnim ciklusom koji prati pool, jer odgovaranje za adresu koju više ne opslužujete pretvara tuđi promet u crnu rupu. Neki upstreami neće prihvatiti proxy odgovore koje nisu očekivali, pa ovaj dizajn treba i saglasnost provajdera.

Šta usmjerena dostava zahtijeva

Čistiji dizajn je dodjela koju upstream zaista usmjerava na vaš gateway. To može biti delegirani prefiks ili statička ruta za manji blok, a zahtjev je u oba slučaja isti: upstream tablica mora pokazivati na vaš server za raspon klijenata. Tada povratni promet stiže na gateway i gateway ga prosljeđuje u tunel.

Usmjerena dostava potpuno uklanja pitanje otkrivanja susjeda, i zato ga vrijedi zatražiti od provajdera prije nego što izgradite nešto pametno. Zatražite rutu u pisanoj formi i potvrdite da je sljedeći hop adresa koju upstream zaista može dosegnuti.

Oba dizajna i dalje trebaju omogućeno IPv6 prosljeđivanje na gatewayu i firewall pravila koja dozvoljavaju proslijeđeni tok u oba smjera. Dostava je preduslov, a ne zamjena, za ostatak puta. Ruta koja radi s onemogućenim prosljeđivanjem proizvodi tačno istu tišinu kao ruta koja nedostaje, pa provjerite oboje prije nego što bilo šta redizajnirate.

Dvije nezavisne rute koje treba podesiti

Prefiks poola i vlastita zadana ruta klijenta su odvojene postavke, a njihovo miješanje proizvodi djelimičnu povezanost koja izgleda kao pokvaren tunel. Pool govori serveru koje adrese dodijeliti. Rute klijenta odlučuju na koja odredišta klijent uopće šalje promet u tunel.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Prefiks iznad je dokumentacijski prostor, a preusmjeravanje se odnosi samo na IPv6, što je upravo ono što dvostruko postavljanje često želi dok se IPv6 dostava još popravlja. IPv4 preusmjeravanje ne uspostavlja IPv6 pokrivenost, i nijedna postavka ne podrazumijeva onu drugu.

Održavajte kontrolni promet od kojeg IPv6 zavisi funkcionalnim pod kojom god politikom da primijenite. Packet Too Big poruke su klasična žrtva firewalla koji dozvoljava samo TCP i UDP, a njihovo odbacivanje stvara veze koje se uspostave i zatim zaglave na većim prijenosima.

Router oglasi su treći pokretni dio. Ako gateway počne oglašavati na uplinku, to može promijeniti šta klijenti i susjedi vjeruju o prefiksima na linku, što može tiho poništiti dizajn koji ste upravo dokumentovali.

Zabilježite dizajn da ga ponovna izgradnja reproducira

Zapišite tri objekta odvojeno: dodjelu klijenta, odredišnu rutu klijenta i način dostave dodjele od strane upstreama. Čitalac koji ima sva tri može ponovo izgraditi postavljanje; čitalac koji ima samo postavku poola reprodukovat će izvornu grešku.

Zatim eksplicitno testirajte povratni smjer, paketom koji se mora vratiti izvana. openvpn(8) priručnik pokriva opcije server-ipv6 i redirect, a potvrda usmjeravanja od vašeg provajdera pokriva polovinu koju priručnik ne može.