Zašto IPv6 otkrivanje susjeda ne radi kroz rutiranu VPN

IPv6 otkrivanje susjeda pripada vezi, a rutirani tunel je granica između dvije veze. Ta jedna rečenica objašnjava gotovo svaku prijavu udaljenog hosta koji odgovara na adresu i ne može se naći ni na koji drugi način. Provjerite opseg adrese koju testirate prije nego provjerite tunel. Adresa lokalna za vezu ima smisla samo na svojoj vezi, a multicast grupa traženog čvora ograničena je na isti način. Nijedna ne prelazi ruter, zato ping na globalnu adresu može uspjeti dok otkrivanje za isti host ne radi.

Opseg dolazi prije konfiguracije

Zahtjev i objava susjeda nose ograničenje skoka 255 i ne prosljeđuju se, po dizajnu. Ruter između vašeg tunela i udaljene LAN mreže prosljeđuje IPv6 pakete i ne prenosi poruke susjeda u njegovo ime. Zato keš susjeda na sučelju tunela sadrži partnera i malo toga drugog, što je ispravno ponašanje, a ne nedostatak koji treba popraviti.

Adresa lokalna za vezu poput unosa fe80:: također je vezana za zonu, a isti tekst može označavati drugi host na drugoj vezi. Testiranje takve adrese s druge strane tunela ne dokazuje ništa osim da je adresa dvosmislena.

Zamka je pretpostavka da je prefiks na vezi

Host koji vjeruje da je prefiks na vezi šalje zahtjev susjeda umjesto da paket preda svom ruteru, a to uključuje /64 rutiran prema udaljenoj lokaciji. Kada takav prefiks stigne kao na vezi, host pita lokalnu vezu za host koji živi negdje drugdje i ništa ne odgovara. Rutirajte nešto manje prema udaljenom hostu ili završite prefiks na ruteru koji će odgovarati za njega.

/128 za jednu uslugu najmanje je iznenađujuće rješenje i potpuno uklanja dvosmislenost. Specifikacija otkrivanja susjeda opisuje skup poruka i zastavicu „na vezi“ koja to odlučuje.

Premošćivanje namjerno mijenja pravila

Kada tunel prenosi Ethernet okvire, udaljeni i lokalni segment postaju jedna veza, multicast doseže obje strane, a otkrivanje susjeda ponaša se kao na preklopniku. Posljedice dolaze s tim: poplava broadcasta i multicasta, otkrivanje dupliciranih adresa preko mosta i objave rutera koje cure u segment koji ih ne bi trebao vidjeti. Domena kvara sada također pokriva dvije lokacije. Ništa od toga nije argument protiv premošćivanja i svaka točka razlog je da se most gradi namjerno, a ne slučajno.

Prebacivanje profila s TUN na TAP kako bi se otkrivanje pojavilo pogrešan je redoslijed radnji. Server, klijent i plan adresiranja moraju se složiti, a mobilni klijenti uopće ne nude TAP sučelje, pa takav dizajn radi na prijenosniku, a pada na telefonu. Posrednici i releji susjeda odvojeni su mehanizmi s vlastitim zahtjevima i pripadaju dokumentiranom uređenju mrežnog administratora, a ne postavkama aplikacije.

Testirajte adresom koju aplikacija koristi

Potvrdite rutu pomoću ip -6 route get, pregledajte unos susjeda pomoću ip -6 neigh, zatim potvrdite uslugu preko rutirane putanje. DNS i povratna putanja odvojene su provjere i zdrav unos susjeda ne dokazuje nijednu od njih.

Ako aplikacija inzistira na odredištu lokalnom za vezu ili na otkrivanju, to je razgovor o dizajnu, a ne vježba podešavanja, jer nijedna klijentska postavka ne čini mehanizam ograničen na vezu funkcionalnim kroz ruter.

Zapišite koji dizajn imate

Zabilježite rutirano ili premošćeno prije incidenta, jer dvije implementacije na ova pitanja odgovaraju različito i dežurni inženjer to ne bi trebao zaključivati iz profila.

Jednokratno čitanje skupa poruka uklanja iskušenje da se svojstvo opsega veze objasni kao VPN greška, što je najskuplja pogrešna dijagnoza u ovom području.