OpenVPN на GCE: дадайце alias IP, перш чым пушыць маршруты

Запушчаны маршрут не робіць VM next hop. Дадайце дыяпазон alias IP, узгадніце яго з пулам сервера і стварыце зваротны маршрут у VPC, перш чым правяраць кліентаў.

Кліент падключаецца да сервера OpenVPN на віртуальнай машыне Compute Engine, акно стану паведамляе падключана, а ping да хоста ўнутры VPC усё роўна нікуды не даходзіць. Першы імпульс — дадаць яшчэ адзін радок push, і гэта ніколі не дапамагае. Compute Engine вырашае, куды ідуць пакеты, па сваёй уласнай табліцы маршрутаў і па адрасах, якія інтэрфейс VM сапраўды трымае, таму пул тунеля, якім VM не валодае, — гэта пул, у які ніхто не дастаўляе.

Ідзіце за пакетам, які падае, а не за файлам канфігурацыі, і адсутныя часткі з'явяцца па парадку.

Пачніце з паміраючага пакета

SYN пакідае кліента, трапляе ў тунель і дасягае VM як інкапсуляваны пакет да адрасата ўнутры VPC. OpenVPN распакоўвае яго і спрабуе перадаць праз eth0, дзе fabric задае адно пытанне перад усім іншым: ці валодае гэты інстанс адрасам прызначэння. Пул тунеля, выразаны з чужой падсеткі, не праходзіць гэта пытанне, і пакет адкідваецца яшчэ да таго, як будзе правераны хоць адзін маршрут ці правіла firewall.

Значыць, у кірунку ад кліента да VPC два асобныя патрабаванні, і ні адно з іх не з'яўляецца дырэктывай push. VM патрэбны дыяпазон alias, які пакрывае пул тунеля, і менавіта гэта робіць яе законным уладальнікам гэтых адрасоў. VPC патрэбны маршрут, які называе VM наступным пераходам для кожнага абароненага прэфікса. Не хапае аднаго — пакет памірае ў іншым месцы, а кліент бачыць тое ж маўчанне.

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

Ці валодае інстанс пулам тунеля

Дайце VM другасны дыяпазон унутры яе ўласнай падсеткі, а затым прымусьце OpenVPN выдаваць адрасы роўна з гэтага дыяпазону. На інстансе, чый асноўны адрас — 10.156.0.10/20, alias /28 аддзяляе пул ад адрасоў, якія ўжо трымаюць іншыя інстансы:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

Тады дырэктыва server мусіць апісваць той самы блок. Яе першы адрас становіцца шлюзам тунеля, а астатнія адрасы раздаюцца кліентам. Тут два лікі апісваюць адзін блок, сетку і маску, і гэта той сінтаксіс пула, якога OpenVPN дагэтуль чакае.

server 10.156.1.0 255.255.255.240

Пераканайцеся, што адрас сапраўды трапіў на інтэрфейс, а не толькі ў канфігурацыю OpenVPN. Fabric перасылае тое, што паведамляе NIC, а не тое, у што верыць дэман. Адна каманда гэта вырашае:

ip -4 addr show dev eth0

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

Дайце зваротнаму трафіку наступны пераход

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

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Той самы маршрут патрэбны для любога прэфікса, што ляжыць за кліентам, а не ўнутры VPC. Гэтым прэфіксам таксама патрэбны запіс iroute у ccd-файле гэтага кліента. Гэты запіс — улік на баку сервера: ён кажа серверу, які кліент валодае прэфіксам, і нічога не ўсталёўвае на самім кліенце.

Пакіньце спіс push для кліенцкага боку размовы, бо ён толькі дадае маршруты на машыну, што падключаецца. Радок push для падсеткі VPC і маршрут VPC назад да пула — дзве паловы аднаго шляху, і любая палова сама па сабе дае тунель, які нясе запыты, але не адказы.

Firewall, перасылка і прамежкавыя пераходы

Firewall VPC ацэньвае распакаваны пакет, таму правіла ingress мусіць прапускаць пул тунеля і любы прэфікс пляцоўкі, які даходзіць да VM гэтым шляхам. Пазіцыя default-deny ціха правальваецца тут: пакет адкідваецца пасля распакавання, а журнал OpenVPN паказвае здаровую сесію.

На любым хосце Linux, які перасылае, а не завяршае, праверце, ці ўключаны net.ipv4.ip_forward. Правіла ўладання дзейнічае і там: машына, якая перасылае для падсеткі, якой у яе няма, адкідвае пакет гэтак жа, як зрабіла б VM. Прачытайце значэнне, перш чым вінаваціць тунель.

Калі не працуе роўна адзін прэфікс

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

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Адсутны маршрут праяўляецца як адсутнасць наступнага пераходу для прэфікса, а адсутны alias — як пакет, адкінуты на інтэрфейсе; з боку кліента гэтыя дзве рэчы падобныя, а ў гэтых двух вывадах зусім розныя. Калі ёсць і тое і другое, падазроны, што застаўся, — iroute у ccd кліента, які заяўляе прэфікс.

Запішыце чатыры значэнні побач з тунелем: дыяпазон alias, пул сервера, запушчаныя прэфіксы, маршруты VPC. Састарэлы alias ламае кожны адрас пула, састарэлы маршрут ламае адзін кірунак, адсутны push хавае прэфікс ад кліента, а памылковы iroute накіроўвае прэфікс не таму peer. Наступнаму чалавеку, які дадасць падсетку, патрэбны ўсе чатыры ў адным месцы, і гэтая нататка таннейшая за вечар.

Падобныя артыкулы