Delegimi i prefiksit IPv6 përmes një VPN nga sajti në sajt: listë kontrolli

Ngritja e tunelit është gjysma e lehtë. Kam parë një lidhje nga sajti në sajt të qëndrojë e vendosur për ditë ndërsa çdo host në LAN-in e largët merrte vetëm heshtje, sepse prefiksi i deleguar pas atij gateway ishte konfiguruar në një ndërfaqe, por nuk ishte rrugëtuar kurrë në tunel. Adresat e tunelit përgjigjeshin ndaj ping-ut gjatë gjithë kohës, dhe pikërisht për këtë askush nuk shikonte prefiksin. Ja rendi që kontrolloj kur një prefiks IPv6 i deleguar duhet të kalojë një VPN sajti: harta e prefiksave, përzgjedhësit e trafikut, përcjellja dhe firewall-i, dhe pastaj rruga e kthimit.

Shkruaj hartën e prefiksave përpara se të prekësh tunelin

Delegimi i prefiksit i jep një bllok ruterit që e kërkoi. Ai nuk instalon një rrugë te partneri, nuk e zgjeron atë bllok on-link dhe nuk i thotë gateway-t të largët çfarë ndodhet pas ruterit kërkues. Këto tre gjëra duhet t'i konfiguroni vetë, dhe i përkasin një plani adresash përpara se të ndryshojë çdo skedar konfigurimi.

Për çdo sajt, shënoni prefiksin e deleguar, /64 që përdoret realisht në LAN, adresat e tunelit dhe pronarin e çdo rruge. Ofruesi delegon 2001:db8:a1::/56 te sajti A, i cili shërben 2001:db8:a1:10::/64 në LAN-in e tij; sajti B mban 2001:db8:b2::/64. Nëse sajti A shërben vetëm atë /64, të dy skajet duhet të përmendin 2001:db8:a1:10::/64 në vend të /56-së së plotë.

Pothuajse gjithmonë shfaqen dy gabime. Njëri është ta trajtosh prefiksin e largët si on-link, ta urazoosh ose ta vendosësh në ndërfaqen e tunelit, kështu që gateway-i përgjigjet kërkesave të fqinjëve për host-e që nuk arrin t'i prekë. Tjetri është të shpallësh të gjithë /56-n kur është konfiguruar vetëm një /64: tabela e rrugëve pohon se blloku është i arritshëm dhe shumica e adresave bien në një vrimë të zezë.

Përputh përzgjedhësit e trafikut të të dy skajeve me rrugët

IKEv2 dhe WireGuard të dy refuzojnë trafikun që nuk përputhet, mjaftueshëm në heshtje sa tuneli vazhdon të duket i shëndoshë.

Në strongSwan përzgjedhësit janë të qartë. Te sajti A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

conn-i i sajtit B pasqyron të dy nënrrjetet. Kur nuk pajtohen, përgjigjësi e refuzon CHILD_SA me TS_UNACCEPTABLE, kështu që child SA nuk ngrihet kurrë edhe pse IKE_SA u ngrit. Në të dy anët nënrrjeti i konfiguruar duhet të jetë i barabartë me atë që kernel-i lokal rrugëton drejt tunelit.

WireGuard mbart të njëjtin informacion në AllowedIPs, me një dredhi: AllowedIPs është filtër burimi në marrje dhe rrugë në dërgim. Nëse hyrja peer e sajtit B për sajtin A lë jashtë 2001:db8:a1:10::/64, paketat nga sajti A mbërrijnë me një handshake të vlefshëm dhe hidhen si të palejuara. Kjo prodhon modelin e njohur të një handshake që përtërihet vazhdimisht ndërsa asnjë përgjigje nuk del kurrë. Krahaso të dy skajet me wg show wg0 allowed-ips. Rishiko atë listë sa herë ndryshon delegimi; një /64 e vjetruar e mban sesionin gjallë dhe prefiksin e ri të paarritshëm.

Përjashto fillimisht përcjelljen, firewall-in dhe MTU-në

Përpara se të lexosh një rresht tjetër logu, konfirmo që gateway-t përcjellin fare. sysctl net.ipv6.conf.all.forwarding duhet të kthejë 1 në të dyja, i aplikuar edhe në ndërfaqet e tunelit dhe të LAN-it. Vjen bashkë një kurth: kur përcjellja është ndezur, një ndërfaqe me accept_ra=1 ndalon pranimin e reklamave të ruterit nga ofruesi, kështu që makina mund të humbasë rrugën e parazgjedhur të sipërme ndonëse brenda tunelit rrugëton në mënyrë të përsosur. Vendos accept_ra=2 atje ku RA e ofruesit nevojitet ende.

Pastaj rregullat e firewall-it duhet ta lejojnë prefiksin në të dy drejtimet, dhe ICMPv6 duhet të mbijetojë: zbulimi i fqinjëve, packet-too-big dhe destination-unreachable nuk janë opsionale. Nëse i hedh, zbulimi i MTU-së së rrugës prishët dhe merr lidhje që hapen e pastaj ngecin në përgjigjen e parë të madhe. Një çift minimal rregullash duket kështu:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU-ja qëndron pas kësaj. Tuneli e zvogëlon MTU-në e përdorshme nën 1500, dhe IPv6 kërkon që çdo lidhje të mbartë të paktën 1280. Ping-et e vogla kalojnë, një sesion SSH ngrin në një shpërthim të madh, dhe /proc/net/snmp6 tregon mesazhe packet-too-big që nuk kthehen kurrë. Vendos në mënyrë të qartë MTU-në e tunelit, ose kufizo MSS-në TCP në tabelën mangle, dhe lëre ICMPv6 që njofton MTU-në më të vogël të kthehet.

Testo rrugën e kthimit, jo adresën e tunelit

Dështimi që merr më shumë kohë është rrugëtimi njëdrejtimësh. Çdo gateway e rrugëton prefiksin e largët në tunel, por host-et përgjigjen përmes gateway-t të tyre të parazgjedhur sepse aty banon /64 e tyre. Ta çosh një paketë në destinacion është gjysma e rrugës.

Dy komanda zgjidhin pjesën më të madhe. Te sajti A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 tregon cilën ndërfaqe do të përdorte një përgjigje nga ai burim; bëj kontrollin pasqyrë te sajti B. Pastaj gjenero trafik nga një host dhe jo nga gateway-i, dhe krahaso numëruesit në të dy skajet.

Nëse kërkesa e fqinjëve për prefiksin e largët shfaqet në tunel, ai prefiks është on-link diku ku nuk duhet të jetë; rregulloje këtë përpara se të rregullosh rrugët. Proxy NDP mbulon rastet kur urazimi është vërtet i nevojshëm, nuk është zëvendësues i një rruge.

Planifiko ndryshimin e prefiksit nën ty

Delegimi i prefiksit është një qira midis ruterit që delegon dhe atij që kërkon, dhe rinovimi mund të kthejë një bllok tjetër: një /56 tjetër pas migrimit të ofruesit, ose një qira më e shkurtër se sa tuneli ka qenë lart. Çdo vend që emërton prefiksin e vjetër vjetrohet përnjëherë: rrugët, përzgjedhësit, AllowedIPs, rregullat e firewall-it, regjistrimet DNS dhe çdo monitorim që kodon adresa fjalëpërfjalë. Rrjedha e mesazheve është në RFC 8415.

Aty ku pritet që prefiksi të lëvizë, mba një plan adresash të brendshëm që nuk varet prej tij dhe përkthe në kufi. NPTv6 është opsioni pa gjendje dhe e mban politikën e brendshme të lexueshme, por është përkthim prefiksi, jo një shtresë magjike: kufijtë /64 duhet të përputhen, checksum-at rregullohen, dhe aplikacionet që përfshijnë adresa fjalëpërfjalë ndërsa thyhen. Nëse i mban adresat e ofruesit nga skaji në skaj, shënoni sjelljen e qirasë dhe një procedurë ndryshimi në planin e adresave.

Përfundo me një test që i reziston kohës: një host i lejuar në çdo LAN arrin një shërbim në LAN-in tjetër, përgjigjja kthehet përmes tunelit, dhe i njëjti çift vazhdon të punojë pas një rindezjeje të tunelit dhe një rinovimi të delegimit. Nëse pjesa e fundit dështon, dizajni varet nga një gjendje që nuk do t'i mbijetojë javës.