IPv6 link-local nuk funksionon përmes VPN: pse fe80 ndalon në lidhje
Një adresë fe80:: ka kuptim vetëm në një lidhje. Shihni pse një VPN i rutuar nuk mund ta mbajë atë, si duket dështimi dhe cilën adresë të përdorni në vend të saj.
Ju ngrini tunelin, bëni ping te fe80::1 me tunelin si ndërfaqe burimore dhe nuk kthehet asgjë. Nuk është një rregull firewall që keni harruar. Një adresë link-local ka kuptim vetëm në atë lidhje të vetme ku u formua, dhe një VPN i rutuar nuk është ajo lidhje. fe80::1 i ruterit të largët jeton në segmentin LAN të largët; ju ndodheni një hop më tej në një segment tjetër, dhe IPv6 nuk ka fare mekanizëm që një ruter të përcjellë paketa link-local.
Prefiksi fe80 përshkruan një shtrirje, jo një interval
Link-local unicast është fe80::/10, dhe vetia përcaktuese nuk është numri, por shtrirja. Adresa vlen vetëm në një lidhje, dhe çdo ndërfaqe formon një nga identifikuesi i vet, prandaj dy makina të palidhura në dy rrjete të palidhura mund të përgjigjen të dyja për fe80::1 pa asnjë konflikt. Prefiksi në thelb thotë «në ndonjë lidhje»; vetë lidhja vjen nga konteksti.
Në një host, ai kontekst është zona, ose scope ID, që shtoni pas shenjës së përqindjes: fe80::1%eth0 në Linux, fe80::1%3 ose fe80::1%12 në Windows dhe në mjetet që shfaqin indekset e ndërfaqeve. Kernel-i e zgjidh adresën bashkë me indeksin e ndërfaqes dhe pastaj dërgon. Nëse e hiqni zonën, destinacioni bëhet i paqartë, kështu që stivi nuk ka mënyrë të zgjedhë një segment.
Pse një tunel i rutuar nuk mund ta dorëzojë
Një VPN i rutuar është një ndërfaqe pikë-për-pikë që mban adresat e veta, zakonisht një /64 të hapësirës IPv6 unique-local ose private brenda tunelit. LAN-i i largët është një lidhje e veçantë, e arritur nga pika fundore e tunelit që rutan dhe përcjell në emrin tuaj. Këto janë dy segmente të veçanta, prandaj një adresë nga njëri nuk është destinacion i vlefshëm në tjetrin.
Rregulli i përcjelljes është i shprehur në standard, jo një teke e klientit tuaj: ruterat nuk përcjellin paketa me burim ose destinacion link-local. Prandaj paketa vdes edhe kur tabela e rrugëtimit duket e saktë. Shtoni një rrugë për fe80::/64 drejt tunelit dhe një stiv konform ose e refuzon atë ose e pranon dhe hedh çdo paketë që përputhet: shtrirja e destinacionit thotë «vetëm kjo lidhje», dhe ndërfaqja dalëse nuk është ajo lidhje.
Zbulimi i fqinjëve përforcon të njëjtin kufi. Hostet zgjidhin hop-et e ardhshme link-local me një kërkesë fqinji të dërguar në multicast me shtrirje lidhjeje dhe kufi hop-i 255, kështu që ruterat mund të refuzojnë çdo gjë të përcjellë. Ta bësh këtë të funksionojë përmes tunelit do të thoshte të proxy-sh zbulimin për një segment të largët, që është urë Layer 2 me një kapelë tjetër.
Ka një dështim të dytë më të qetë, dhe ai kap njerëzit që prapë përpiqen të detyrojnë rrugën: zona. Çfarëdo zone që shkruani lokalisht emërton ndërfaqen e tunelit, ndërsa adresa që dëshironi është e lidhur me ndërfaqen e LAN-it të largët. Të dyja nuk përputhen kurrë, kështu që paketa nuk mund të drejtohet te ndërfaqja e duhur në skajin e largët.
Si duket dështimi në praktikë
Dalja e mjetit për një gabim shtrirjeje lexohet si gabim rrugëtimi ose firewall, dhe pikërisht për këtë njerëzit kalojnë një pasdite në shtresën e gabuar.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
Rreshti i tretë humb më shumë kohë, sepse një klient ssh pa dalje duket si problem i një shërbimi që dëgjon. Nëse keni ndonjë mënyrë për të hyrë, kontrolloni anën e largët dhe konfirmoni nëse sshd është i lidhur me të gjitha adresat apo vetëm me një.
Përdorni një adresë që ishte menduar të rutohet
Për çdo gjë që duhet të arrini përmes tunelit, përdorni adresën që shërbimit iu dha pikërisht për këtë qëllim: një adresë unicast globale, ose një adresë unique-local nga fc00::/7, intervali i rezervuar pikërisht për këtë rast të brendshëm. Konfirmoni që dëgjuesi vërtet e lidh atë, dhe kontrolloni rrugën e kthimit dhe çdo rregull firewall të hostit.
Shikoni hostin e largët në vend që të hamendësoni. ip -6 addr show rendit adresat që ekzistojnë, dhe ss -6 -ltn rendit atë që demoni dëgjon. Një shërbim i lidhur vetëm me fe80:: është i arritshëm vetëm nga segmenti i vet, që zakonisht është një parazgjedhje që askush nuk e zgjodhi me qëllim dhe që mund të ndryshohet me pëlqimin e administratorit.
Kur shërbimi vërtet nuk mund të lidhet përsëri, ngjisni urën lart në shtresën e aplikacionit në vend të asaj të rrjetit. Një rele në hostin e largët që dëgjon në një adresë të rutueshme dhe lidhet me atë link-local e zgjidh problemin pa zgjatur asnjë segment:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Këtu zona ndodhet në anën e duhur, në hostin që vërtet ka eth0 në atë lidhje. Klienti juaj flet me fd00:1:2::10, që rutohet normalisht, dhe releja e bën hop-in link-local lokalisht. I njëjti truk funksionon për ndërfaqen web të një pajisjeje ose një BMC të vjetër që reklamon vetëm një adresë link-local.
Kur ura është vërtet përgjigjja, dhe çfarë të kontrolloni
Disa vendosje vërtet kanë nevojë për një segment të përbashkët: një pajisje që flet vetëm zbulim link-local, një aparat që varet nga multicast, një laborator që riprodhon një LAN të rrafshët. Ky është problem i Layer 2 dhe kërkon një përgjigje Layer 2, si një pajisje tap e uruar te ndërfaqja e largët ose një produkt klienti me modalitet urë të qartë. Kjo të kushton trafik broadcast dhe multicast që kalon tunelin plus zbulimin e fqinjëve që duhet të funksionojë nga fillimi në fund.
Mos iu afroni kësaj duke shtuar fe80::/64 në një profil të rutuar. Kjo prodhon gjendjen më të keqe: konfigurimi duket i përfunduar, tabela e rrugëtimit tregon një zë, dhe çdo paketë prapë hidhet diku midis dy stivave që të dy sillen saktë.
Verifikoni me ndërfaqen, jo me ping. ip -6 addr show tun0 ju tregon nëse lidhja e tunelit formoi një adresë link-local të vetën, dhe ip -6 route get fe80::1%tun0 ju tregon çfarë do të bënte kernel-i në të vërtetë me një destinacion me shtrirje. Kur kernel-i thotë se destinacioni është i paarritshëm në atë ndërfaqe, asnjë cilësim tuneli nuk do ta ndryshojë atë, dhe është koha të ndaloni së redaktuarit e profilit.
Një sekuencë e shkurtër që e zgjidh pyetjen:
- Lexoni adresën në hostin e largët dhe vini re nëse është fe80:: ose një prefiks i rutueshëm.
- Nëse është fe80::, lidhni shërbimin përsëri, bëni rele në atë host ose uroni segmentin; nëse është i rutueshëm, rregulloni rrugën, firewall-in ose adresën e lidhjes.
- Rikontrolloni zonën sa herë që ritestoni, sepse një komandë e kopjuar zakonisht mban ndërfaqen e gabuar.
Burimet: RFC 4291, arkitektura e adresimit IPv6.