Чаму маршрут поўнага тунэлю адсякае сервер, які яго нясе
Маршрут па змаўчанні праз тунель захоплівае і знешнія пакеты, якія яго нясуць. Замацуйце канчатковы пункт маршрутам да хоста і трымайце адказы сервера па-за ім.
Уключыце поўны тунель — і кожны пункт прызначэння цяпер належыць VPN-інтэрфейсу, уключна з машынай, якая яго завяршае. Знешнія пакеты, што нясуць тунель, адрасаваныя гэтай машыне, таму маршрут у рэшце рэшт спажывае транспарт, ад якога залежыць. Адзін дадатковы канкрэтны маршрут вырашае гэта, і прычыну варта зразумець. Без гэтай прычыны наступная перабудова зноў унясе памылку.
Маршрут, які з’ядае ўласны транспарт
Інкапсуляцыя загортвае кожны пакет у другі загаловак. Знешні адрасаваны ад лакальнага фізічнага адраса да публічнага адраса сервера, і ён мусіць перасекчы фізічнае звяно, перш чым з’явіцца хоць які тунель.
Цяпер дазвольце пошуку па гэтым публічным адрасе выбраць тунель. Каб адправіць пакет, машына мусіць яго інкапсуляваць, а гэта патрабуе маршруту да таго ж адраса, які вяртае тунель. Кліенты спраўляюцца з гэтым адным з двух спосабаў. Асцярожны адмаўляецца ўсталёўваць маршрут па змаўчанні і паведамляе пра памылку, а менш асцярожны паведамляе пра поспех і потым нічога не зрушвае. Ціхая няўдача — тая, што каштуе паўдня.
Найдаўжэйшае супадзенне прэфікса вырашае пошук раней за любую метрыку, таму маршрут на адзін адрас пераўзыходзіць кожны маршрут па змаўчанні на машыне. Увесь механізм рамонту менавіта такі.
Усталюйце выключэнне перад маршрутам па змаўчанні
Стварыце маршрут на адзін адрас для сервера, з фізічным шлюзам як наступным крокам, перш чым зрушыцца маршрут па змаўчанні. Парадак важны: усталёўка потым азначае жыццё са зламаным тунелем, пакуль вы друкуеце.
Большасць кліентаў робіць гэта без нагадвання. OpenVPN шукае аддалены адрас і замацоўвае яго, перш чым перапісаць шлюз па змаўчанні, а яго опцыя route-delay існуе для платформ, дзе гэтая паслядоўнасць гоніцца. wg-quick ідзе цалкам іншай дарогай, пазначаючы пакеты і звяртаючыся да правіла палітыкі замест таго каб дадаць выключэнне. Розныя механізмы, адна патраба: знешні пакет мусіць уцячы з тунеля, які ён стварае.
ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10
Вынік пошуку — гэта прыёмачны тэст. Ён мусіць называць фізічную прыладу і фізічны наступны крок. Тунельная прылада ў гэтым адказе азначае, што выключэнне адсутнічае або было змешчана пасля чагосьці, што яго перакрывае.
Люстраное адлюстраванне на серверы
Тая ж пастка чакае на іншым баку, у адваротным кірунку. Дайце серверу маршрут па змаўчанні праз іншы тунель або прапхніце яму маршрут, які ахоплівае публічныя адрасы кліентаў, і яго адказы набудуць звычку ісці не туды.
Уявіце кліента, які падключаецца і адпраўляе запыт. Адказ адрасаваны публічнаму адрасу гэтага кліента, які цяпер супадае з тунельным маршрутам, таму ён выходзіць з іншага інтэрфейсу, несучы крыніцу, якую кліент ніколі не набіраў. Кліент можа атрымаць гэты пакет і ўсё роўна адкінуць яго, бо нішто не звязвае яго з адпраўленым запытам. Працуйце ад рашэння маршрутызацыі сервера, а не ад тайм-аўту кліента, бо толькі адно з іх паказвае фактычны выбар.
ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44
Існуюць тры рамонты, і яны не роўныя. Замацаванне сэрвісу за фізічным адрасам або трансляцыя крыніцы — абодва хаваюць рашэнне маршрутызацыі замест таго каб выправіць яго. Адпраўка адказных патокаў для тунельнага пула праз асобную табліцу выпраўляе прычыну, а два іншыя дапушчальныя толькі пакуль дызайн маршрутызацыі замарожаны.
Выключэнні, якія тунель няспынна крадзе
Жменьцы задач патрэбны адкрыты інтэрнэт нават тады, калі тунель валодае маршрутам па змаўчанні, і кожнай патрэбна сваё выключэнне. Абнаўляльнік дынамічнага DNS звычайна ламаецца першым.
Ён вызначае правайдэра, адкрывае злучэнне і бачыць, што ўласныя пакеты ідуць праз тунель, адрас якога змяніўся секунды таму, таму абнаўленне правальваецца або публікуе няправільны адрас. Тры выйсці: замацаваць правайдэра маршрутам да хоста праз фізічны шлюз, запусціць абнаўленне да ўзняцця тунеля або даць абнаўляльніку табліцу палітыкі, да якой тунель не дакранаецца. Сінхранізацыя часу мае тую ж экспазіцыю на прыладзе, якая загружаецца без рэзалвера, і канчатковыя пункты праверкі сертыфікатаў належаць у спіс з той жа прычыны.
Выключэнне, якога ніхто не запісаў, — гэта выключэнне, якое наступная перабудова моўчкі адкіне.
Праверце гэта пасля перападключэння, а не да
Праверце тры пункты прызначэння, а не адзін: канчатковы пункт, прыватны адрас за тунелем і публічны адрас за ім. Адзін паспяховы пошук не кажа амаль нічога пра два іншыя.
ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1
Затым перазапусціце злучэнне, бо кліент, які перабудоўвае сваю табліцу пры перападключэнні, адкіне маршрут, набраны ўручную. Калі ўключаны kill switch, праверце, што канчатковы пункт дазволены, інакш тунель не зможа вярнуцца пасля змены сеткі і сімптом будзе выглядаць як аварыя. Захоўвайце выключэнне ў профілі або unit-файле, а не ў гісторыі shell, каб перападключэнне стварала яго зноў, а не сцірала.