Два скачкі VPN на адным Pi: які маршрут нясе якога партнёра

Два адрасы тунелю на адной маленькай плаце выглядаюць як памылка, і рэфлекс — выдаліць адзін. Гэты рэфлекс ламае тое, што павінен быў прывесці ў парадак. Хост, які трымае два скачкі, захоўвае па адрасе на кожнае далучэнне, і кожны адрас выбіраецца розным маршрутам. Вартае пытанне — які маршрут выбірае якога перавозчыка для якой мэты, а не колькі адрасоў існуе.

Тры мэты, якім патрэбны розныя перавозчыкі

Ланцуг з двух скачкоў — гэта тры класы мэт, складзеныя адзін на адзін, і кожны з іх нясе розная прывязка. Знешні партнёр павінен быць дасягнуты праз фізічнае злучэнне. Унутраны партнёр павінен быць дасягнуты праз знешні тунель. Мэта ахопленага дадатку павінна быць дасягнута праз унутраны тунель, чысты транспарт якога нясе знешні.

Запоўніце радкі рэальнымі адрасамі чытача, перш чым кранаць маршрут, бо табліца карысная толькі тады, калі яна канкрэтная. Працоўны ланцуг задавальняе ўсе чатыры радкі адначасова, а паўпрацоўны звычайна задавальняе адзін з іх з няправільным перавозчыкам. Менавіта чытанне няправільнага радка як збою ператварае праблему маршрутызацыі ў цэлы вечар правак.

Адрасы маюць ролі, а не колькасць

Linux дазваляе некалькі адрасоў на адным інтэрфейсе і некалькі тунеляў на адным хосце, таму колькасць нічога не кажа пра карэктнасць. Важна, які адрас належыць якой прывязцы і ці выбірае маршрут для пэўнага партнёра тую прывязку, якую вы мелі на ўвазе. Тры прадстаўленні адказваюць на гэта з трох бакоў, і іх варта чытаць у адным і тым жа парадку кожны раз.

Інвентар адрасоў паказвае, што існуе і якая прывязка ім валодае. Табліца маршрутаў адказвае на пытанне перавозчыка для звычайнага трафіку мэт. Прадстаўленне палітыкі адказвае на яго зноў для трафіку, выбранага па крыніцы або пазнацы, што з'яўляецца звычайнай схемай, калі два кліенты дзеляць адзін хост.

ip -4 addr show
ip -4 route show table all
ip rule show

Выдаленне адраса таму, што спіс выглядае доўгім, можа прыбраць частку шляху, а выдаленне маршруту таму, што ён выглядае лішнім, робіць тое ж самое цішэй. Ні адно не дае памылкі; партнёр проста перастае адказваць на шляху, які вы мелі на ўвазе, застаючыся дасягальным праз іншы. Дадатак, які паведамляе адрас выхаду ўнутранага партнёра, не даказвае, што трафік перасек знешні тунель, бо прамы доступ дае тое ж назіранне. Менавіта гэтая прорва паміж назіраннем і доказам — прычына, па якой перавозчык правяраецца на ўзроўні маршрутызацыі.

Парадак актывацыі перамагае фіксаваны сон

Калі ўнутраны кліент залежыць ад адраса або маршруту, які пастаўляе знешні кліент, актывацыя павінна чакаць гэты рэсурс, а не затрымку. Сон працуе да таго дня, калі знешні тунель павольны, і тады ён зрэдку падае так, што ніхто не можа паўтарыць. Парадкаванне на аснове залежнасцей прыбірае здагадку і каштуе нічога, акрамя аднаго апісання залежнасці. Назвы інтэрфейсаў таксама не з'яўляюцца механізмам парадкавання.

Ядро выдае назвы накшталт tun0 і tun1 у парадку стварэння, і гэты парадак можа змяняцца паміж перазапускамі або перападлучэннямі. Прывяжыце канфігурацыю да ідэнтычнасці, якую дае інструмент, або да назвы, якую вы прызначаеце свядома. Назва, якую выбіраеце вы, — кантракт; назва, якую выбірае ядро, — выпадак.

Трымайце транспарт кожнага кліента па-за маршрутам дадатка іншага і будзьце дакладнымі адносна таго, што насамрэч абяцаюць опцыі маршрутызацыі OpenVPN 2.6. Задакументаваны механізм перанакіравання па змаўчанні захоўвае здольнасць кліента дасягаць свайго выдаленага партнёра праз шлюз, які ўжо існаваў, і гэта абрывае адзін канкрэтны цыкл рэкурсіі. Ён не робіць адзін кліент перавозчыкам іншага, таму астатняя частка ланцуга застаецца вашай распрацоўкай. Там, дзе ланцугу патрэбна палітыка, а не маршрут, напішыце яўнае правіла крыніцы або пазнакі і праверце яго трафікам, для якога яно прызначана.

Што адбываецца, калі знешні скачок памірае

Перш чым ланцуг будзе лічыцца завершаным, вырашыце, што адбудзецца, калі знешні скачок знікне. Транспарт унутранага кліента памірае разам з ім, і наступны крок — пытанне палітыкі, а не тэхнікі: збой, паўтор або прамое падключэнне праз фізічнае злучэнне. Менавіта трэці вынік варта абдумаць. Ён ціха ператварае двухскачковы дызайн у аднаскачковы ў той момант, калі карыстальнік верыць, што пакрыццё яшчэ цэлае.

Калі два скачкі абавязковыя, унутраны кліент не павінен мець магчымасці ўсталяваць прамы шлях, калі знешні знік, і спосаб даведацца — зламаць знешні скачок і паглядзець, што робіць унутраны. Узгоднены запасны варыянт — законны адказ, але ён павінен быць запісаны, правераны і паведамлены. Запасны варыянт, якога ніхто не задокументаваў, падчас разбору інцыдэнту неадрозны ад уцечкі.

DNS і іншае сямейства адрасоў належаць да таго ж рашэння. Лакальна згенераваны запыт ідзе ўласнай палітыцы хоста, а не палітыцы перанакіраванага кліента, таму рэзалвер, які працуе для перанакіраванага трафіку, можа не быць тым, які выкарыстоўвае сам хост.

Прымайце кожны ўзровень у тым парадку, у якім будавалі

Тэстуйце ў парадку, у якім будаваўся ланцуг: спачатку знешні тунель, потым транспарт унутранага кліента праз знешні тунель, потым дадатак праз унутраны тунель. Кожнае прыняцце павінна быць свежым злучэннем, а не старонкай, якая ўжо была адкрыта. Затым зламайце і аднавіце кожны ўзровень асобна і паглядзіце, што робіць наступны.

Вынік запаснога варыянту — самае каштоўнае назіранне тут, і тое, што старонка публічнага IP ніколі не паказвае. Захавайце шляхі партнёраў, адрасы, якія яны выкарыстоўваюць, і гэты вынік побач з канфігурацыяй, бо шчаслівы шлях — не тая частка, якую пазней ставяць пад пытанне.