Настройка сети oracle cloud
Oracle Cloud Infrastructure makes it easy to allow secured ways to let your compute instances in the Oracle Public Cloud to reach the internet, as well as being reachable from the Internet when needed. There are 2 main types of Networking Gateways that makes this easy to implement:
- Internet Gateway: This type of gateway is directly attached to your Virtual Cloud Network (VCN) and lets your compute instances, that reside in a public subnet, to reach the Internet and being reachable from the Internet. A classic example of this is a bastion host that needs to be accessed via SSH from outside your VCN and that also needs connectivity to the Internet.
- NAT Gateway: NAT gateways are like Internet gateways, in the sense that it lets your compute instances to be able to reach out the Internet, but they forcibly disallow the ability to reach these instances from the Internet, in other words, they are private instances. A classic example of this is a DB system running on a private subnet on your VCN, that needs to reach out Internet to download patches, but you don’t want anybody outside your VNC to be able to reach your DB.
Given this is the first of many more blogs around Oracle Cloud Infrastructure, I am going to assume not previous knowledge and start from scratch and build each of the networks primitives one at a time. Obviously, Oracle allows us to fast track and simply select defaults and create all network resources automatically, when spinning up a VM, but I believe that knowing where everything fits, will give us the ability to change the defaults if needed in the future.
Let’s first create your VCN, Subnets and other Networking primitives
Perhaps the first thing that you have to think of is the Network framework that will govern a particular purpose. In this case, we will need 2 subnets; a public subnet used to test the Internet Gateway and a Private subnet used to test your NAT Gateway. Also, since subnets are logical constructs governed by a Virtual Cloud Network (VCN), I recommend always to think about creating your VCN first and think of the CIDR ranges that will reflect your required network topology.
In this case, let’s keep thing simple, the only real rule that I want to highlight is, always design your networks making sure that you don’t overlap CIDR blocks :
Let’s create first the VCN, for this:
When you create a VCN, by default a routing table, DHCP and security list are created and attached to it. However, it is always a good practice to leave these default configurations and create your own, specific for your needs. That way you can apply different rules per subnet.
Also, by default the default security list already establishes an ingress stateful rule to open incoming traffic on port 22. This means that, in theory for this exercise, we don’t need to create any new security list. Having said that, since we are learning best practices, let me show you how you would normally create separate route tables and security lists for each of your subnets, so that you can, if needed, in the future tighten different security requirements per subnet.
So, for this demo, we are going to create a pair of routing table and security lists each for one of our subnets:
- On the left menu under Resources, click on Route Tables and click on Create Route Table.
- This is going to be used for our public subnet, so give it a sensible name and add it within the same compartment that you chose before for your subnets.
- Then click on Create Route Table. Your new route table will be displayed:
- Repeat these steps to create another route table, but this time, give it a name associated with the private subnet, so that you can identify them later. Once you complete this, your 2 new security lists should be displayed:
- Similarly, click on Security Lists under Resources and create 2 new security lists. Don’t add any rules to it yet, just leave the defaults, we will come back to that later. Just make sure that, you give then sensible names, one associated to the public subnet and one for the private subnet. This is just so that you can recognise them later, when assigning them into the subnets.
Now, let’s create the 2 type of gateways that we want to play with:
Finally, we need to:
Associate to each subnet the right security list (you can associate up to 5 security lists per subnet).
Finally, we need to associate a default destination route on each of the Route Tables to the corresponding type of Gateway. That is:
- Within Resources > Route Tables, click on the route table associated with your public subnet.
- Click on Add Route Rules.
- Target Type: Internet Gateway
- Destination CIDR block: 0.0.0.0/0 (This means all the Internet; we can obviously just add specific networks/hosts with tighter CIDR blocks)
- Compartment: Same compartment I’ve been using so far.
- Target Internet Gateway: Simply select from the drop-down menu the Internet Gateway that we created previously.
- When ready, click on Add Route Rules.
- Now, let’s repeat these steps, but this time to add the NAT Gateway into the routing rule associated with the Private subnet.
- Normally for NAT Gateways, we don’t open the destination CIDR block to the whole Internet, but just the ranges where we would be getting the patches from, for example. For the sake of this exercise, you can simply add the whole Internet.
- When ready, click on Add Route Rules.
We are ready to spin up VMs on each of these subnets.
Now, let’s spin up VMs into the Subnets
We are ready to spin up VM compute nodes into each of our subnets, for this, let’s simply add Ubuntu machines (I love Ubuntu).
In the compute creation, let’s first create the bastion host, that is, the VM that will be in the public subnet:
- Enter a sensible name: bastionhost1_vm
- Select the Availability Domain (you normally have 3 Availability Domains per Region)
- Change Image Source to Ubuntu 16.04
- Instance Type: VM
- Shape: Leave the default VM.Standard2.1
- Add your RSA public key, so that you can ssh later, using its corresponding private key.
- VCN Compartment: Select the compartment that you have been using so far.
- VCN: Select the VCN that you created previously
- Subnet Compartment: Select the corresponding compartment.
- Subnet: Since this is the bastion host, select the public subnet that you created previously.
- Verify and when ready click on Create.
- You know it is ready when it comes all green:
Notice that the VM is associated with a Public IP Address, use your private key to ssh into this new VM. The default user for Ubuntu VMs is “ubuntu”.
For example, for me:
- Great, now repeat the same steps, but this time to create a new Ubuntu VM in the private subnet.
- Notice that since this second VM is associated with a private subnet, it will not have a public IP Address. In other words, we cannot reach it from the Internet, which is exactly what we wanted.
- However, since we associated a NAT Gateway with the private subnet route table, we should be able to reach the Internet from any compute instance under the private subnet. Let’s test it.
- For this, let’s use our bastion host to ssh our private VM (using its private IP Address, e.g. 10.105.1.2 in this case).
- For this case, once you SSH into the bastion Host, let’s simply create a new file and store the private key (there are better ways to do it using dynamic groups, but that would be another blog).
- Now, simply ssh from the bastion host into the private VM:
Ok, not a great joke, but at least we know that we can hit the Internet from an instance running on the private subnet.
Сразу предупреждаю, что бесплатно выдаются машинки достаточно слабенькие (одноядерные, на каждой RAM 1Gb, суммарное дисковое пространство обоих машин до 100Gb, подключение к сети 480Mbit), но для экспериментов этого более чем достаточно. Впрочем на них вполне можно развернуть почтовый сервер для небольшой организации, собственную систему управления умным домом или какой-нибудь FreePBX.
Я не буду здесь полностью описывать процедуру регистрации в Oracle Cloud, она достаточно хорошо представлена на официальном сайте, ссылка есть в конце статьи. Просто скажу, что для этого вам понадобится действующий адрес электронной почты, действующий (российский) телефон с возможностью приема SMS и банковская карта, на которой имеется хотя бы 1EUR или соответствующий рублевой эквивалент. Электронная почта и телефон используются в процессе регистрации, на них отправляются коды, которые необходимо будет затем подтвердить. На последнем шаге привязывается банковская карта (я использовал цифровую дебетовую от банка ВТБ), на ней в процессе регистрации блокируется сумма порядка 1EUR для проверки валидности карты. В дальнейшем она возвращается и больше карта никак не используется, если только вы не захотите сделать апгрейд с Free Tier на какой-либо платный тариф. Замечу, что сразу после завершения регистрации вам предоставляется бонус в размере 250EUR на 30 дней. Т.е. в течении месяца вы можете абсолютно бесплатно попробовать и другие сервисы, которые не входят в программу Free Tier.
Описанную ниже последовательность действий можно сильно упростить, если впоследствии вы не планируете подключать облачную инфраструктуру к своей локальной или офисной сети штатными средствами. В этом случае можно не создавать виртуальную сеть вручную, а сразу перейти к созданию виртуальных машин. Однако если хотите разобраться во взаимосвязи всех облачных элементов, лучше делайте все пошагово, не используя возможностей wizard.
В Oracle Cloud облачная приватная сеть (VCN), имеющая подключение к Интернет, в общем случае выглядит следующим образом:
Service Gateway, так же как и NAT Gateway, нам пока не нужны. Мы хотим получить виртуальную машину, полностью доступную из внешнего мира. Правда (и, видимо, это особенность большинства сервис-провайдеров) внешний адрес IP будет назначен не непосредственно виртуальной машине, а посредством технологии NAT 1:1 (на рисунке выше она фактически реализуется в объекте Internet Gateway).
Итак начнем с создания собственной сети (VCN) в датацентре домашнего региона. Для этого в меню (левый верхний угол страницы) выбираем пункт Networking.
Выбираем в меню "Networking"=>"Virtual Cloud Networks" и нажимаем на кнопку "Create VCN". Придумываем и вводим в поле "Name" идентификатор нашей VCN, а в поле "CIDR Blocks" добавляем минимум одну сеть. Пусть это будет сеть 172.31.254.0/26, в адресном пространстве которой будут адреса создаваемых нами виртуальных машин и всякие служебные туннели для связи виртуальной сети с нашей локальной или офисной сетью. Галочку в пункте "USE DNS HOSTNAMES IN THIS VCN" оставляем отмеченной, чтобы впоследствии можно было бы привязать внутренний DNS к этой VCN.
После создания VCN система также создаст нам следующие объекты по умолчанию: CIDR Blocks (1 шт), Route Tables (1 шт), Security Lists (1 шт) и DHCP Options (1 шт).
Теперь мы должны будем создать внутри VCN подсеть IP-адресов. Для этого нажимаем кнопку "Create Subnet". В поле "Name" вводим имя подсети (сейчас создаем подсеть, в которой будут располагаться виртуальные машины, поэтому назовем ее "Virtual Machines"). Subnet type выбираем "Regional", в поле "CIDR Block" запишем значение 172.31.254.0/28 (хватит нам для начала 13 адресов на 2 бесплатные виртуальные машины?). В "SUBNET ACCESS" выбираем "PUBLIC SUBNET" (чтобы на виртуальные машины нам потом выделили внешние IP-адреса), остальные поля заполняем единственно доступными для выбора на данном этапе значениями.
После создания VCN мы можем создать в ней Internet Gateways. Здесь вообще все просто: в поле "Name" вводим имя создаваемого Internet Gateway и нажимаем кнопку "Create Internet Gateway"
Остался предпоследний шаг, который обеспечит нам возможность выходить из нашей VCN в сеть Интернет (а также входить из Интернета в нашу VCN, используя NAT 1:1). Сначала в меню идем по пунктам "Networking"=>"Virtual Cloud Networks", затем в списке выбираем созданную ранее VCN Zurich, внутри нее в блоке "Resources" выбираем "Route Tables", в появившемся списке выбираем таблицу "Default Route Table for VCN Zurich" (она была создана ранее автоматически), и нажимаем кнопку "Add Route Rule". В поле "Target type" выбираем "Internet Gateway", в поле "DESTINATION CIDR BLOCK" пишем маршрут по умолчанию 0.0.0.0/0, в поле "Target Internet Gateway" выбираем элемент, созданный нами на предыдущем шаге (впрочем он пока вообще будет единственным в списке выбора).
А теперь стоит разрешить ICMP Echo запросы из внешнего мира к нашей внутренней инфраструктуре (по умолчанию они запрещены). Для этого снова выбираем наш VCN Zurich, в его ресурсах выбираем Security Lists. Там будет единственный элемент, созданный автоматически при создании VCN.
Выбираем его в списке, нажимаем кнопку "Add Ingress Rules" и добавляем правило, разрешающее ICMP Echo Requests с любых адресов.
Отлично, мы создали себе сетевую инфраструктуру с требуемым диапазоном внутренних адресов и с подключением к сети Интернет. Теперь можно перейти непосредственно к созданию виртуальных машин.
В меню выбираем пункты "Compute"=>"Instances" и нажимаем кнопку "Create Instance". В поле "Name" указываем имя создаваемой машины, выбираем требуемую нам ОС, в Shape указываем тип VM.Standard.E2.1.Micro (это бесплатная виртуальная машина), в блоке "Configure networking " устанавливаем значение "Assign a public IPv4 address: Yes" (чтобы нашей виртуальной машине выделили внешний адрес в сети Интернет). Ну и убеждаемся, что сеть VCN и подсеть внутри нее выбраны правильно (т.е. те, которые мы создавали на предыдущих шагах). При необходимости можно загрузить уже существующий открытый ключ SSH или создать новый.
Возвращаемся в пункт "Instances" чтобы узнать внешний IP-адрес вновь созданной виртуальной машины.
Примечание: на картинке выше в списке отображаются две виртуальные машины: одна только что созданная и одна с именем "eu-zurich-1-ad-1.vedga.com". Эту машину я создавал ранее, а потом удалил. Но она все равно еще сутки будет отображаться в этом списке в состоянии "Terminated". Беспокоиться нечего: удаленные машины ресурсы не потребляют и не помешают вам создавать новые виртуальные машины (в пределах бесплатного лимита).
Для проверки делаем ping на внешний адрес, и если сеть на предыдущих шагах была настроена правильно, то мы получим ответ от нашей виртуальной машины. Теперь на нее можно зайти по SSH. Замечу, что при создании виртуальной машины из образа Ubuntu, первый вход надо делать не с именем root, а с именем ubuntu и заданным при создании машины SSH-ключом. Впрочем если попробуете зайти под root сразу он вас хотя и не пустит, но укажет, что надо сделать. Для перехода в режим root введите команду sudo /bin/bash, скопируйте содержимое /home/ubuntu/.ssh/* в /root/.ssh и поменяйте владельца файла /root/.ssh/authorized_keys на root:root. Теперь можно будет зайти на машину сразу под root-пользователем, используя ключ SSH.
Теперь у вас есть одна (или две) виртуальные машины, защищенные облачным firewall, и доступ к ним из внешнего мира. Кому-то этого будет достаточно, кто-то быстро поставит на них OpenVPN и свяжет их со своей сетью. А мы будем строить VPN штатными средствами Oracle Cloud (IPSec со статической или динамической BGP маршрутизацией и Mikrotik или Linux на другом конце туннеля), но это уже тема отдельной статьи. Итак, продолжение следует.
N.B. В комментариях пишут, что иногда Oracle удаляет созданные ресурсы без предупреждения. А также то, что через некоторое время с привязанной карты повторно списывается и возвращается 1EUR (подтверждаю, у меня тоже был запрос авторизации с немедленной отменой). Возможно эти вещи взаимосвязаны: пока есть живая карта, Free Tier будет работать. Если карта пропала, значит пропал и пользователь и ресурсы можно удалять. Но это только предположение.
На этот раз статья будет короткой и во многом самоочевидной. Потому что большинство потенциальных пользователей просто не знают о такой возможности, а сама настройка проста, как апельсин.
Oracle, придя на рынок облачных сервисов, активно привлекает новых клиентов. И одним из инструментов такого привлечения являются Always Free сервисы - зарегистрировавшийся клиент может пользоваться каким-то достаточно ограниченным набором ресурсов, как это следует из названия, бесплатно и неограниченно во времени. В список этих ресурсов входит два compute инстанса (каждый 2 ядра, 1GB RAM, 45GB HDD), которые можно использовать подо что угодно, но в нашем случае мы можем построить на них полностью бесплатный OpenVPN-сервер, буквально не умея практически ничего, кроме тыкания в кнопку Next. Чем мы и займемся.
Делай два - запускаем сервер OpenVPN
Ваш аккаунт подтвердился, вам пришло уведомление об этом на электронную почту. И теперь вы, возможно, ожидаете, что мы будем разворачивать инстанс, ставить на него вручную и настраивать сервис, открывать для него порты. Но это же облако, там всё уже сделано за нас.
Идем в маркетплейс, там нажимаем на зеленую кнопку Get App справа сверху. Далее он нас попросит залогиниться - выбираем Commercial Market, логинимся. В появившемся окне нужно выбрать Compartment (он у вас пока что один) и подтвердить, что вы прочитали и приняли Terms of Use. После этого станет доступна кнопка Launch Stack, на которую мы немедленно и нажимаем.
Это запускает мастер создания инстанса, где на первом этапе никаких важных для нас настроек нет, можно просто нажать Next.
На втором этапе уже есть кое-что важное. В поле Compute Shape обязательно надо выбрать VM.Standard.E2.1.Micro вариант (возможно, когда вы это читаете - там могут быть другие цифры, но важно, что Micro - только они попадают под Always Free опцию).
Ниже, в Application Configuration, нам нужно создать админские логин и пароль к сервису (их можно будет использовать и для подключения к VPN, а можно будет создать для этого дополнительные реквизиты).
В Network Configuration в принципе всё можно оставить по умолчанию, если у вас есть какие-то специальные требования к адресации внутри VPN - здесь их можно скорректировать.
И, наконец, в Additional Configuration имеет смысл вставить ваш публичный ssh-ключ, чтобы вы смогли подключиться к сервису по SSH для управления из консоли. Если вам эта возможность не требуется - то и без него всё совершенно точно будет работать.
После нажатия Next мастер позволит вам обозреть ваши настройки в последний раз и нажать Create, после чего задача встанет в очередь на исполнение в Terraform'е. Исполняться иногда может долго, был случай - ждало больше 15 минут, но чаще всего через десятки секунд уже можно наблюдать радующее "Выполняется" в состоянии инстанса в списке. Провалившись в инстанс, можно в разделе "Доступ к экземпляру" посмотреть "Общедоступный IP-адрес", который и будет адресом вашего VPN-сервера.
Делай три - заходим в интерфейс управления
На самом деле необязательный шаг, но для понимания нюансов.
Логин и пароль для админки - те, которые вы ввели в настройках на шаге №2. На том конце - классический веб-интерфейс OpenVPN Access Server, так что в рамках непревращения статьи в "100500я статья про OpenVPN в интернете" описывать какие-то настройки здесь я не буду, тем более, что работать будет и с настройками по умолчанию.
Option 2: Private Subnet
Oracle recommends this option for a production system. The subnet is private and cannot be reached from the internet. See the following diagram and description.
Gateways for the VCN:
-
, with a FastConnect or Site-to-Site VPN to your on-premises network. to reach Object Storage for database backups and patching, and to reach Oracle YUM repos for OS updates. Also see Option 2: Service Gateway Access to Both Object Storage and YUM Repos in Service Gateway for the VCN. (to reach public endpoints not supported by the service gateway).
Route Table: A custom route table for the subnet, with these rules:
- A route for the on-premises network's CIDR, and target = DRG.
- A rule for the service CIDR label called All region Services in Oracle Services Network , and target = the service gateway. See Overview of Service Gateways.
- If you want to access the Oracle YUM repos through the NAT gateway, add a route rule for the regional YUM repo's public IP address, and target = the NAT gateway. See Public IP Addresses for the Oracle YUM Repos. If you just use the next rule only, the traffic to the YUM repo would still be routed to the service gateway, because the service gateway route is more specific than 0.0.0.0/0.
- A rule for 0.0.0.0/0, and target = NAT gateway.
Requirements for IP Address Space
If you are setting up DB systems (and thus VCNs) in more than one region, make sure the IP address space of the VCNs does not overlap.
The subnet you create for a bare metal or virtual machine DB system cannot overlap with 192.168.16.16/28, which is used by the Oracle Clusterware private interconnect on the database instance.
The following table lists the minimum required subnet size.
The Networking service reserves three IP addresses in each subnet. Allocating a larger space for the subnet than the minimum required (for example, at least /25 instead of /28) can reduce the relative impact of those reserved addresses on the subnet's available space. For more information, see IP Addresses Reserved for Use by Oracle.
1 + 3 reserved in subnet = 4
Постскриптум
Много вопросов поступает про "OpenVPN - фу, а как L2TP?" и на место L2TP можно подставить любой другой протокол, например, WireGuard. Вряд ли стоит ради этого писать отдельные статьи, зачем порождать информационный мусор. Но если коротко - для любого другого протокола нужно просто завести инстанс, например, ubuntu minimal, а потом использовать готовые автосетапы road warrior - например, L2TP, OpenVPN и WireGuard. Единственный неочевидный момент здесь - открыть на сервисе нужные протоколу входящие порты (в свойствах инстанса - subnet - security list и там добавить соответствующие ingress rules).
Предоставление бесплатных серверов от малопопулярного облачного провайдера - это не новость. А новость в том, что теперь Oracle, вдобавок к двум едва живым бесплатным x86_64 серверам, открывает доступ к мощностям на ARM64 - для всех, даром, и пусть никто не уйдет обиженным!© Предложение по ARM значительно более производительное, чем на традиционных процессорах. Добавляя к этому остальные бесплатные "плюшки", я задаюсь вопросом: а зачем я до сих пор плачу за VPS и держу собственный серверок в подвале?! Все это можно выкинуть если удастся надежно и безопасно связать дата центр с домашней сетью.
Проблемы и ограничения
Не у всех поднимается доступ по SSH. Тут, к сожалению, ничего сказать не могу, потому что мне такой кейс отлаживать не приходилось. Рекомендовать могу только на втором этапе выше тщательно проверить, что вставился правильный публичный ключ. Имя пользователя при этом выводится в том же разделе "Доступ к экземпляру".
Нужно помнить, что это не просто виртуальная машина, а инстанс в облаке, закрытый сетевыми настройками не только внутри инстанса (чаще всего там уже заточенный iptables), но и снаружи его - в NetworkSecurityGroup, назначенной на виртуальную облачную сеть (VCN) инстанса. Поэтому если нужно открыть какие-то нестандартные порты - это может потребоваться делать в нескольких местах.
OpenVPN Access Server без лицензии позволяет не более двух одновременных подключений. Поэтому решение подходит для персонального VPN. Но в целом, конечно, ничто не мешает не ставить его из маркетплейса, а поднять пустой инстанс в Оракле (или не Оракле) и установить OpenVPN (или не OpenVPN) на этот инстанс самостоятельно из консоли. Это уже просто будет другая история.
Важный апдейт от @osipov_dv - в сервисе бесплатны только 10 ТБ исходящего трафика в месяц (в случае VPN получается суммирование вашего входящего и исходящего), а потом он будет вам стоить $0.0085/GB. Впрочем, на практике дотянуться до 10 ТБ потребления - это надо очень, очень постараться. По моим логам более 2 ТБ за месяц общего потребления моя семья никогда не осиливала, несмотря на немаленькую домашнюю ферму виртуализации. Но никогда не помешает оценить свои объемы потребления, прежде чем подписываться.
И еще один важный апдейт про Ampere-инстансы. На них в долгосрок рассчитывать не стоит, потому что см. ниже. Пересоздать их можно, но при этом IP будет новый. Поэтому для VPN и прочих публичных ресурсов подходит только x86.
А что дальше?
После создания кластера из 6 4 виртуальных машин (UPDATE: спасибо @ky0. суммарный бесплатный объем диска 200 ГБ, а минимальный объем загрузочного диска для VM - 47 ГБ, т.е. больше 4 машин на Free Tier создать не получится. Официальное подтверждение тут), нагрузив их самой минимальной полезной нагрузкой стало понятно, что хочется большего. Хочется переложить все домашние сервисы на датацентры oracle, а именно: мелкие базы данных всех мастей, полезные при разработке ПО, сервер автоматизации рутины n8n, локальный gitea для backup'ов github репозиториев, Pi-hole и прочие прелести доморощенного хостинга. Но все это очень не хочется выставлять в интернет, даже с паролями, даже с файерволами, совсем никак.
Мне поможет VPN! Были рассмотрены варианты:
VPN сервер на Mikrotik + VPN клиент в облаке. Этот вариант требует либо настройки VPN на каждом интансе, либо настройки маршрутизации внутри облачной сети через один "главный" инстанс, а уже на нем VPN. Такой вариант мне не понравился тем, что требует настройки каждый раз при пересоздании инстанса, а пересоздавать их иногда хочется.
VPN сервер на одном из инстансов + VPN клиент на Mikrotik. Вариант уже лучше, но все равно, появляется "священная корова" - инстанс с VPN сервером, который нельзя убивать, с ним нужно очень аккуратно экспериментировать, и при пересоздании устанавливать все по новой.
Site-to-Site VPN. Нужно всего-то настроить VPN со стороны Oracle Cloud, настроить VPN на Mikrotik, профит! Проблема была только в одном. В сети нет инструкции как это делать. Будем разбираться. (тут важно отметить, что для реализации этого варианта обязательно наличие белого IP на вашем Mikrotik).
Итак, имея за плечами скромный опыт настройки VPN, понимание компьютерных сетей на университетском уровне и отсутствие опыта работы с облачными провайдерами, я приступил к настройке.
Хочу предостеречь профессионального читателя, в тексте могут быть и будут ляпы, связанные с пониманием предметной области в криптографии и маршрутизации, статья не претендует на энциклопедическую точность, а лишь призвана обобщить и сохранить тот опыт, который автор собрал, наступая на грабли и исследуя различные источники при создании Site-to-Site VPN на Mikrotik.
Option 1: Public Subnet with Internet Gateway
This option can be useful when doing a proof-of-concept or development work. You can use this setup in production if you want to use an internet gateway with the VCN, or if you have services that run only on a public network and need access to the database. See the following diagram and description.
-
. . to reach Object Storage for database backups and patching.
Route Table: A custom route table for the subnet, with two rules:
- A rule for 0.0.0.0/0, and target = internet gateway.
- A rule for the service CIDR label called OCI region Object Storage , and target = the service gateway. See Overview of Service Gateways and Service Gateway for the VCN.
Note
See this known issue for information about configuring route rules with service gateway as the target on route tables associated with public subnets.
Заключение
Понимаю, что большинство читателей способны самостоятельно настроить VPN-сервер, поэтому не претендую на техническую полезность статьи. Скорее это просто рассказ о существующей возможности, про которую слышали далеко не все. Теперь, надеюсь, знающих будет больше.
Создание ресурсов
Описывать создание ресурсов (виртуальных машин, сетей и правил) я не буду, все это достаточно подробно описано в статье "Получаем бесплатные сервера в Oracle Cloud Free Tier". Замечу только, что для получения именно ARM64 инстанса нужно сменить Shape при создании Compute Instance на Ampere и выбрать выделяемые ресурсы (для бесплатного использования обещают 1 instance с 4 OCPU и 24 GB RAM или 4 кратно меньших, т.е. 1 OCPU/6 GB).
Выбор arm сервера
Настройка Oracle
На панели управления ресурсами есть мастер настройки сети, который проведет пользователя через все нужные шаги в одном месте.
Если вы создали хотя бы один вычислительный инстанс в инфраструктуре Oracle, у вас должен был автоматически создаться служебный элемент "Virtual Cloud Network", выберите его, если он не выбран в мастере. Если это первая попытка создания VPN, в мастере нужно выбрать создание нового "Dynamic Routing Gateway" (DRG), имя заполнится автоматически. При повторных попытках создания VPN можно выбирать существующий DRG.
Подсети и безопасность. Security List позволяет настроить правила файервола. Можно, конечно, выбрать автоматически создавшийся при создании первого инстанса Default Security List, но я рекомендую все же создать новый, чтобы иметь возможность независимо настраивать внутреннюю безопасность и внешнюю.
Следующий шаг позволяет выбрать настройки маршрутизации. Если читателю знаком протокол динамической маршрутизации BGP, он может быть настроен здесь. В статье же я ограничусь более простым вариантом - это статическая маршрутизация. Если у вас дома стоит Mikrotik, вы наверняка знаете какие подсети используются у вас во внутренней сети. В моем случае это 192.168.6.0/24, именно для нее Oracle будет отправлять трафик через VPN на ваш Mikrotik.
Со стороны Oracle создается два туннеля - это просто дублирование для надежности.
При желании можно настроить мониторинг состояния туннелей, это позволит получать уведомления при разрыве соединения, но я не стал этого делать.
Дальше, ответственный момент - указание IP-адреса вашего маршрутизатора. Проверить его можно на ifconfig.io или в любом другом подобном сервисе, тот же самый IP-адрес должен быть на одном из интерфейсов вашего маршрутизатора.
Проверьте, что все указано правильно.
Дальше запускается облачная магия.
Спустя несколько секунд ваш туннель со стороны Oracle готов, можно просмотреть его настройки.
Нажатие кнопки View VPN покажет нам состояние и адреса двух туннелей со стороны Oracle, не закрывайте страницу, адреса нам еще пригодятся.
Еще нам понадобится Shared Secret для одного (или каждого) туннеля, посмотреть его можно провалившись внутрь по ссылке с названием туннеля, там есть кнопка для отображения ключа.
Делай раз - регистрируемся
Идем на адрес https://signup.cloud.oracle.com/. Проходим крайне самоочевидный мастер регистрации, подтверждаем почту, привязываем платежную карту, доходим до дашборда, где будет написано "Your account is currently being set up, and some features will be unavailable. You will receive an email after setup completes." Дальше можно знакомиться с интерфейсом, но лучше до того, как аккаунт станет полностью подтвержденным, ничего значимого не делать. Обычно на это уходят единицы, в крайнем случае десятки минут.
Из тонких моментов - да, платежная карта нужна. На ней должен быть минимум 1 евро, который снимется при проверке карты. Но если вы будете пользоваться только always free ресурсами, никаких других денег с вас не снимут. По отзывам, далеко не все карты российских банков работают, я для подобных сервисов обычно использую карты из партнерских программ с Золотой Короной (Кукуруза от Связного, Озон.Кард - десятки их), с ними никаких проблем при регистрации в Оракле не возникало. Та же озоновская карта делается за единицы минут без изменения положения тела в пространстве.
Еще может быть непонятным момент выбора региона - тут, разумеется, вы выбираете, исходя из ваших целей, но я бы рекомендовал рассматривать наиболее географически к вам близкие регионы. Нужно помнить, что для VPN-сервиса задержка передачи пакета от клиента до сервера и назад добавляется к общей задержке, даже если вы пытаетесь подключиться к серверу в соседней с вами комнате. Также имеет смысл учитывать жесткость законодательства по авторским правам в конкретной стране - вдруг у вас торренты через этот канал польются. Вероятность проблем, конечно, невысока, но зачем потенциально усложнять ситуацию. Для себя я выбираю Нидерланды - там и AMS-IX рядом, да и в принципе страна хорошая. Но, повторюсь, вы можете выбрать любой регион из доступных и повлияет это только на задержку.
Настройка Mikrotik
Самая трудоемкая и неудобная часть пройдена, осталось настроить домашний маршрутизатор. Здесь во многом мне помогла статья "AWS Site-to-Site VPN with MikroTik (RouterOS)", спасибо автору. Дополнить ее пришлось параметрами из документации Oracle и экспериментами.
Дальше я приведу необходимые параметры и рабочую очередность их настройки, без объяснения что это и зачем оно нужно, пытливый читатель сможет найти описания и объяснения в документации Oracle или Mikrotik.
Внимание! Важно чтобы правило обхода NAT было в списке выше, чем правило NAT c Action "masquerade"!
Если все сделано правильно, то между сетями должна появиться связь, пинги и данные начнут ходить в соответствии с настройками выбранного SecurityList из Oracle Cloud.
При желании можно создать второй туннель, но Mikrotik не позволяет создать 2-х Policy с одинаковыми Source Address и Destination Address. Вариантов использования второго туннеля несколько:
Задать для одного policy несколько peer, в таком случае первый будет основным, если он недоступен, используется следующий и так далее.
Разделить вашу подсеть на сегменты, и использовать для них разные peer. Например, имея подсеть 192.168.Х.0/24, поделим ее на 192.168.Х.0/25 и 192.168.Х.128/25, дальше можно создать для каждой из них отдельный policy, тогда трафик будет балансироваться в зависимости от сегмента, в котором находится источник трафика.
Если на вашем Mikrotik не одна сеть, а больше, то можно чередовать пиры для разных подсетей. Этот вариант также поможет балансировать трафик в зависимости от подсети из/в которую направлен трафик.
Прописать дополнительный peer к существующему policy, в этом случае туннель будет активироваться при проблемах с основным peer.
Разделить локальную или удаленную подсеть на 2 части (например 192.168.Х.0/24, можно поделить более мелкие сегменты 192.168.X.0/25 + 192.168.X.128/25) и использовать разные туннели для разных сегментов.
Для тех у кого на Mikrotik настроена более чем одна сеть настроить разные сети через разные туннели.
Собственно, на этом все. Состояние туннелей можно контролировать на портале Oracle Cloud.
Before you set up a bare metal or virtual machine DB system, you must set up a virtual cloud network (VCN) and other Networking service components.
To launch a DB system, you must have:
- A VCN in the region where you want the DB system
- At least one subnet in the VCN (either a public subnet or a private subnet)
In general, Oracle recommends using regional subnets, which span all availability domains in the region. For a bare metal or virtual machine DB system, either a regional subnet or AD-specific subnet works. For more information, see Overview of VCNs and Subnets.
You will create a custom route table. You will also create security rules to control traffic to and from the DB system's compute notes. More information follows about that.
Certain details of the VCN and subnet configuration depend on your choice for DNS resolution within the VCN. For more information, see DNS for the DB System .
Делай четыре - подключаемся к VPN
VCN Creation Wizard: Not for Production
The Networking section of the Console includes a wizard that creates a VCN along with related resources. It can be useful if you just want to try launching an instance. However, the wizard automatically creates a public subnet and an internet gateway. You may not want this for your production network, so Oracle recommends you create the VCN and other resources individually yourself instead of using the wizard. For more information on the wizard, see Virtual Networking Quickstart.
Читайте также: