Zašto IPv6 otkrivanje susjeda ne radi kroz usmjerenu VPN
Otkrivanje susjeda protokol je lokal za vezu, pa ga usmjereni tunel prekida. Most može produljiti vezu, ali samo kao projektna odluka s posljedicama.
IPv6 otkrivanje susjeda pripada vezi, a usmjereni 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 usmjerivač, 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. Usmjerivač između vašeg tunela i udaljene LAN mreže prosljeđuje IPv6 pakete i ne prenosi poruke susjeda u njegovo ime. Zato predmemorija 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 usmjerivaču, a to uključuje /64 usmjeren 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. Usmjerite nešto manje prema udaljenom hostu ili završite prefiks na usmjerivaču 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 usmjerivača 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 je točka razlog 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. Poslužitelj, 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 usmjerene 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 usmjerivač.
Zapišite koji dizajn imate
Zabilježite usmjereno 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.