Гэты адрас тунеля — партнёр, а не падсетка для прагляду
Маска на двухкропкавым злучэнні апісвае далёкі канец, а не дыяпазон суседзяў. Прачытайце адрас партнёра, перш чым лічыць падсетку няправільнай.
Ваш кліент падключаецца і паказвае пару адрасоў або адзін адрас з маскай 255.255.255.255, і першая рэакцыя — што сервер выдаў нешта зламанае. Нішто не зламана: тунельны інтэрфейс — гэта двухкропкавае злучэнне, і маска апісвае далёкі канец гэтага аднаго злучэння, а не дыяпазон суседзяў. Чытанне пары як лакальнага адраса і партнёра тлумачыць дзіўную маску, маршрут да аднаго вузла побач і адсутную табліцу суседзяў. Чаго тое ж чытанне не апраўдвае, дык гэта плана адрасоў, які перасякаецца з офіснай сеткай.
Чаму маска выглядае няправільна на тунельным злучэнні
На інтэрфейсе Ethernet адрас і маска сцвярджаюць дзве рэчы: гэты хост валодае адрасам, а ўсё ўнутры прэфікса — прамы сусед. Ядро выводзіць з гэтых двух фактаў маршрут на злучэнні і затым вырашае адрасы злучэння для суседзяў, якія, на яго думку, прысутнічаюць. Двухкропкавы інтэрфейс захоўвае валоданне і адкідвае суседзяў, таму другі адрас у радку кліента — гэта далёкі канец, а не іншы хост у агульным сегменце. Няма апаратнай адрасацыі, няма трафіку вырашэння і няма шырокавяшчальнага дамена, да якога далучыцца, таму інтэрфейс паводзіць сябе як труба з роўна адным прызначэннем.
Менавіта таму маршрут да асобнага вузла побач з шырокай маскай тут нармальны, а не сімптом. Дасягальнасць на гэтым злучэнні азначае адзін адрас, і ядро запісвае менавіта гэта. Чытайце два адрасы разам, перш чым вырашыць, што канфігурацыя няправільная, бо кожны з іх паасобку выглядае як памылка.
Дзве тапалогіі, дзве формы адрасоў
Старэйшая двухкропкавая тапалогія выдае кожнаму кліенту невялікі блок і выкарыстоўвае два сярэднія адрасы, таму маска выглядае як фрагмент сеткі, а не як пул. Тапалогія падсеткі выдае адрас з пула з маскай пула і называе тунельны адрас сервера партнёрам. Абедзве даюць сапраўднае злучэнне, і яны адрозніваюцца толькі тым, якія адрасы з’яўляюцца ў профілі і якую маску карыстальнік схільны паставіць пад сумнеў.
| Topology | Client address shape | Peer | Route to expect |
|---|---|---|---|
| Point-to-point block per client | Two neighbouring addresses inside a small block | The far address of that block | A single host route on the tunnel device |
| Shared pool | One address carrying the pool mask | The server's tunnel address | A single host route on the tunnel device |
Які б радок ні адпавядаў вашаму кліенту, спачатку чытайце партнёра, бо ён называе далёкі канец і таму тлумачыць маску. Профіль, скапіяваны паміж серверамі з рознымі тапалогіямі, пакажа няправільную форму для новага месца, і гэтую неадпаведнасць лёгка прыняць за збой сервера.
Калі пул і офісная сетка прэтэндуюць на адныя біты
Паколькі злучэнне маршрутызаванае, пулу патрэбны прэфікс, якога няма ні ў адной з сетак, даступных серверу. Падзяліце адзін — і кліент трымае адзін маршрут для дыяпазону, які азначае два месцы, і тое, якое месца пераможа, вырашае маршрут, усталяваны апошнім. Збой праяўляецца на кліенце, хоць рашэнне за ім належыць плану адрасоў. Карыстальнікі паведамляюць, што лакальны маршрутызатар знікае, калі ўзнімаецца тунель, або што адказваюць толькі некаторыя офісныя хасты.
Прэфіксы, якія проста выглядаюць падобна, — іншая справа, і параўнанне актэтаў на вока не з’яўляецца параўнаннем прэфіксаў. Запішыце абодва і палічыце замаскіраваныя біты: 192.168.4.0/24 супраць 192.168.6.0/24 супадаюць да біта 22 і разыходзяцца на біце 23, бо трэці актэт чытаецца як 00000100 супраць 00000110, таму гэтыя дзве сеткі сапраўды асобныя. Пастаўце 10.8.0.0/24 побач з іншым 10.8.0.0/24 і ўсе 24 замаскіраваныя біты супадуць, што азначае, што адзін маршрут не можа выразіць абодва месцы. Даўжыня маскі вызначае, дзе спыняецца параўнанне, і сетка, усталяваная другой, прайграе.
Што не можа даць маршрутызаванае злучэнне
Шырокавяшчальны і групавы трафік не праходзяць праз маршрутызаванае злучэнне, а некалькі звычных функцый пабудаваны на іх. Спісы агляду, аб’явы імёнаў і выяўленне службаў мяркуюць агульны сегмент, таму файлавы сервер можа адказваць на кожны запыт па адрасе і ўсё ж ніколі не з’явіцца ў спісе. Вырашэнне імёнаў, якое залежыць ад лакальнага шырокавяшчання, правальваецца па той жа прычыне, і ніякая праўка профілю не змяняе таго, што тунель здольны перадаць. Ці гэта важна — пытанне патрабаванняў, а не маршрутызацыі.
Кліент, якому сапраўды патрэбны такія дастаўкі, патрабуе маставога інтэрфейса, які перадае кадры Ethernet і таму захоўвае шырокавяшчальны дамен. Кошт — больш шумнае злучэнне, страта чыстай адрасацыі, апісанай вышэй, і значна большая паверхня збояў, як толькі з’яўляюцца петлі. Абгрунтуйце патрабаванне перад пераключэннем і аддайце перавагу службе імёнаў, якая працуе праз маршрутызаваныя злучэнні, калі патрабаванне датычыцца толькі імёнаў.
Чытанне інтэрфейса перад праўкай профілю
Спытайце ў ядра, што яно ўсталявала, а не што нібыта кажа профіль. Вывад адрасоў паказвае партнёра, які тлумачыць маску, а вывад маршрутаў — ці існуе шлях да яго. Запуск абодвух супраць тунельнага інтэрфейса займае імгненне і вырашае пытанне.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
Калі гэтыя тры сыходзяцца, профіль робіць тое, для чаго быў настроены, а рэштка праблемы ў іншым месцы. Змяняйце тапалогію толькі з прычыны, якая называе адсутную магчымасць, бо незнаёмая маска такой не з’яўляецца.