Зошто откривањето соседи во IPv6 не работи преку рутиран VPN

Откривањето соседи во IPv6 припаѓа на една врска, а рутираниот тунел е граница меѓу две врски. Тоа едно изречение објаснува речиси секој извештај за далечен домаќин што одговара по адреса и не може да се најде на друг начин. Пред да го проверите тунелот, проверете го опсегот на адресата што ја тестирате. Адресата локална за врската има смисла само на сопствената врска, а multicast групата на бараниот јазол е ограничена на ист начин. Ниту една не преминува рутер, затоа ping до глобална адреса може да успее додека откривањето за истиот домаќин не успева.

Опсегот доаѓа пред конфигурацијата

Барањето и објавата на сосед носат ограничување на скокови 255 и не се препраќаат, по дизајн. Рутерот меѓу вашиот тунел и далечната LAN препраќа IPv6 пакети и не ги пренесува пораките на соседите во негово име. Така кешот на соседи на интерфејсот на тунелот го содржи партнерот и малку друго, што е правилно однесување, а не дефект што треба да се поправи.

Адреса локална за врската, како запис fe80::, исто така е ограничена на зона, и истиот текст може да означува друг домаќин на друга врска. Тестирањето на една таква од другата страна на тунелот не докажува ништо освен дека адресата е двосмислена.

Стапицата е претпоставката дека префиксот е на врската

Домаќин што верува дека префиксот е на врската испраќа барање на сосед наместо да го предаде пакетот на својот рутер, а тоа вклучува /64 рутиран кон далечна локација. Кога таков префикс пристигнува како на врската, домаќинот ја прашува локалната врска за домаќин што живее на друго место, и ништо не одговара. Рутирајте нешто помало кон далечниот домаќин или завршете го префиксот кај рутерот што ќе одговара наместо него.

/128 за една услуга е најмалку изненадувачкото решение и целосно ја отстранува двосмисленоста. Спецификацијата за откривање соседи го опишува множеството пораки и знамето „на врската“ што го одлучува тоа.

Мостот намерно ги менува правилата

Кога тунелот пренесува Ethernet рамки, далечниот и локалниот сегмент стануваат една врска, multicast стигнува до двете страни, и откривањето соседи се однесува како на комутатор. Последиците доаѓаат со тоа: поплава од broadcast и multicast, откривање дупликат адреси преку мостот и објави од рутер што истекуваат во сегмент што не треба да ги види. Доменот на дефекти сега опфаќа и две локации. Ништо од тоа не е аргумент против мост, и секоја точка е причина да се гради мост намерно, а не случајно.

Префрлање на профил од TUN на TAP за да се појави откривање е погрешен редослед на постапки. Серверот, клиентот и планот за адресирање мора да се согласат, а мобилните клиенти воопшто не нудат TAP интерфејс, затоа таков дизајн работи на преносен сметач, а не успева на телефон. Прокси и релеа за соседи се одделни механизми со свои барања, и тие припаѓаат на документираното уредување на мрежниот администратор, а не на поставките на апликација.

Тестирајте со адресата што ја користи апликацијата

Потврдете ја рутата со ip -6 route get, прегледајте го записот за сосед со ip -6 neigh, потоа потврдете ја услугата по рутираната патека. DNS и повратната патека се одделни проверки, а здрав запис за сосед не докажува ниту една од нив.

Ако апликацијата инсистира на цел локална за врската или заснована на откривање, тоа е разговор за дизајн, а не вежба за подесување, затоа што ниту една поставка на клиент не го прави механизмот ограничен на врската функционален преку рутер.

Запишете каков дизајн имате

Запишете дали е рутиран или мост пред инцидентот, бидејќи двете распоредувања одговараат различно на овие прашања и дежурниот инженер не треба тоа да го заклучи од профил.

Еднократното читање на множеството пораки ја отстранува желбата да се објасни својство на опсегот на врската како грешка во VPN, што е најскапата погрешна дијагноза во оваа област.