-Building a file server with Samba (CentOS 8.1 / openSUSE 15.1 / Ubuntu 20.04) -Source compilation of Apache2.4 + PHP7.4 on Linux-- 1. Apache introduction / [Raspberry Pi] / items / 67686eccaaec73251458) -Source compilation of Apache2.4 + PHP7.4 on Linux-- 2. PHP introduction / [[Raspberry Pi]](https://qiita.com/kazumi75kitty / items / 50f1a447f6ebc2ee2b61) -Source compilation of Apache2.4 + PHP7.4 on Linux-- 3. MySQL introduction/[[Raspberry Pi]](https://qiita.com/kazumi75kitty / items / 4212dacc45944f27ca94) -Apache2.4 + PHP7.4 on Linux --4 Security (chown and firewalld) -Build an IPsec gateway on Linux VPN-- 1. Introduce StrongSwan / [[Ubuntu 20.04 + Raspberry Pi]](https://qiita.com/kazumi75kitty/ items / 08259681247a6c2ebd0d) -Build an IPsec gateway on Linux for VPN-- 2. Check connection to VPN / [Ubuntu 20.04 + Raspberry Pi: This article]
Last time, we built an IPsec-VPN environment by compiling StrongSwan source, but this time let's check if we can actually connect to VPN! (˶ ・ ᴗ ・) ੭⚐⚑
--Minimal installation of OS. Also, the OS must be updated in the latest state. --User installed as root (in my verification, it is an administrator account called admin, and it is processed by sudo from there) --The IPsec gateway uses ufw for the firewall (In Raspberry Pi OS of Raspberry Pi, for firewalld, since the linkage around IPv6 was a waste, I decided to use the Debian standard ufw)
IPsec negotiation receiving gateway (left in the figure below, Raspberry Pi): --Internet side (eth0): 192.168.1.22 --VPN area side (eth1): 192.168.2.1
IPsec negotiation caller gateway (right of the figure below, Ubuntu 20.04): --Internet side (eth0): 192.168.1.18 --VPN area side (eth1): 192.168.5.1
--Network segment: --Internet connection possible: 192.168.1.0/24 --Raspberry Pi (negotiation receiving side on the left of the figure) Secure segment: 192.168.2.0/24 --Ubuntu 20.04 (Negotiation originator listed as "CentOS 8" on the right of the figure) Secure segment: 192.168.5.0/24
--Terminals that connect to VPN: --Client (Ubuntu 20.04): 192.168.2.2 (belongs to 192.168.2.0/24) --Linux Web server (CentOS 8.1): 192.168.5.2 (belongs to 192.168.5.0/24)
Here we will try ** 192.168.2.2 Ubuntu client to make a VPN connection to a 192.168.5.2 Linux web server **. Note that both the server and client connected to the VPN will connect only within the range of the VPN and will not connect to the Internet.
Other required packages are installed with the distribution's standard package commands (dnf, apt, etc.) and do not need to be downloaded individually.
For download, you can access the official website, download from there and transfer it by FTP, or you can get it with wget if you know the URL of the download file, but the acquisition method is omitted.
Last time, eth1 just added a network adapter, and no IP address has been assigned yet. In the case of Raspberry Pi OS, I had to add /etc/dhcpcd.conf manually. .. Of course, dhcpcd.conf has both the default gateway and DNS server specified, so if you specify more than one, the network ranking will be confused, so only the IP address is described in the newly established eth1.
Reference article:
-Set static route for multiple NICs with RasberryPi (stretch)
RaspberryPiOS(2020.08)
# vi /etc/dhcpcd.conf
/etc/dhcpcd.conf(RaspberryPiOS)
[Added the following interface information to the last line]
#interface eth1
interface eth1
static ip_address=192.168.2.1/24
noipv6
RaspberryPiOS(2020.08)
# reboot
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [MAC address of the network adapter from the beginning] brd ff:ff:ff:ff:ff:ff
inet 192.168.1.22/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 [IPv6 address of the network adapter from the beginning] scope global dynamic noprefixroute
valid_lft 14373sec preferred_lft 12573sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [MAC address of the extension network adapter] brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.5.255 scope global noprefixroute eth1
valid_lft forever preferred_lft forever
inet6 [IPv6 address of extension network adapter] scope link noprefixroute
valid_lft forever preferred_lft forever
# ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.22 metric 100
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1 metric 101
The IP address configuration file is too distribution-dependent, and it's hard if you don't get used to it. ٩ (. ›‹. ♡) ۶ I have set an IP address for eth1. Of course, 192.168.2.0/24 was also recognized in the routing.
On the other hand, with Hyper-V Ubuntu, you can set it on the GUI screen instead of SSH, so you only need to specify the address and netmask there and save the settings ٩ (. ›‹. ♡) ۶
Ubuntu20.04(Hyper-V/x64)
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [MAC address of the network adapter from the beginning] brd ff:ff:ff:ff:ff:ff
inet 192.168.1.18/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 [IPv6 address of the network adapter from the beginning] scope global temporary dynamic
valid_lft 14043sec preferred_lft 12243sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether [MAC address of the extension network adapter] brd ff:ff:ff:ff:ff:ff
inet 192.168.5.1/24 brd 192.168.5.255 scope global noprefixroute eth1
valid_lft forever preferred_lft forever
inet6 [IPv6 address of extension network adapter] scope link noprefixroute
valid_lft forever preferred_lft forever
# ip route
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.18 metric 100
192.168.5.0/24 dev eth1 proto kernel scope link src 192.168.5.1 metric 101
Needless to say this. Connect the server and client with a LAN cable and set the IP address manually (the DHCP server is not in the VPN area, so you have to set it manually)
As shown in "Server Conditions", assign an IP address with a LAN cable connection as shown in the figure below. Of course, in the case of a virtual machine, all you have to do is assign a virtual switch.
--Connect Ubuntu client to Raspberry Pi (192.168.2.0/24). Set IP address to 192.168.2.2 --Connect the Linux web server to the Hyper-V virtual machine (192.168.5.0/24). Set IP address to 192.168.5.2
The screen is for CentOS + openSUSE, but even in the case of using Ubuntu this time, when I checked whether the client (192.168.2.2) could pass to the Web server (192.168.5.2) in the opposite VPN area, it passed easily (´ ´). థ ౪ థ)
Even in the case of Ubuntu's IPsec gateway, it seems that the Web is not seen over the VPN area at that time.
Of course wget should also be "No route"
For packets tunneled by IPsec, the port for communication between the server and client in the VPN must be opened because the rule for permitting forwarding must be added again in the ufw of the IPsec gateway. Here, since the client is 192.168.2.2 and the server is 192.168.5.2, transfer permission for 192.168.2.0/24 → 192.168.5.0/24 is added to the rule, but in the case of ufw, it is necessary to specify the route.
The port used by the web server is 80, 443, 8080, 8443, which is the web, so of course, if you enter the following command, the IPsec gateway should forward it over the VPN.
[192.168.2.0/24 → 192.168.5.0/24 HTTP permission]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 80 proto tcp
[192.168.2.0/24 → 192.168.5.0/24 HTTPS permission]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 443 proto tcp
[192.168.2.0/24 → 192.168.5.0/24 Port 8080 Allowed]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 8080 proto tcp
[192.168.2.0/24 → 192.168.5.0/24 port 8443 permit]
# ufw route allow from 192.168.2.0/24 to 192.168.5.0/24 port 8443 proto tcp
[To check]
# ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] 30303/tcp ALLOW IN 192.168.1.0/24
…(Omission)…
[10] 192.168.5.0/24 80/tcp ALLOW FWD 192.168.2.0/24
[11] 192.168.5.0/24 443/tcp ALLOW FWD 192.168.2.0/24
[12] 192.168.5.0/24 8080/tcp ALLOW FWD 192.168.2.0/24
[13] 192.168.5.0/24 8443/tcp ALLOW FWD 192.168.2.0/24
…(Omission)…
reference:
In CentOS 8.1 of Hyper-V virtual machine, firewalld and direct are not compatible (specifically, it seems that registration with nftables is not successful), so [Problem that transfer rule cannot be transferred well even if it is registered with firewalld. Occurs](https://qiita.com/kazumi75kitty/items/f5a33abda9f8edd5c47f#firewalld%E3%81%AE%E8%BB%A2%E9%80%81%E8%A8%B1%E5%8F%AF% E3% 82% 92% E3% 81% 99% E3% 82% 8B% E3% 81% 8Ccentos-81% E3% 81% AEnftables% E3% 81% AE% E9% 80% A3% E5% 8B% 95% E3% 81% AB% E3% 83% 8F% E3% 83% 9E% E3% 81% A3% E3% 81% A6% E6% 96% AD% E5% BF% B5), but Ubuntu 20.04 And Raspberry Pi OS (2020/08 version) firewall has not yet encountered such a problem, and since Debian OS will recommend nftables in the future, if the problem of nftables and transfer rules is not solved early, CentOS It might be a second dance, but ...
-Solve the story that the name cannot be resolved from the Docker container with centOS8 with the nft command -Relationship between netfilter, firewalld, iptables and nftables -Introduction to the new packet filtering tool "nftables" in Linux --Knowledge of Sakura
If I could allow forwarding on both IPsec gateways, I tried to see if the client could access the server in the VPN over the VPN.
This success screen is the screen for CentOS + openSUSE, but it is actually working well on Ubuntu! !!
After all, even in the case of Ubuntu, the packet confirms the encryption in the IPsec tunnel as shown in the screen below (˶ ・ ᴗ ・) ੭ ♡♡
I tried to access the page from the server with the client without encrypting "QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ..." with HTTPS, but when I picked it up by tunneling between IPsec gateways, it was encrypted. I did! !!
With StrongSwan, Raspberry Pi OS and Ubuntu 20.04 of Hyper-V virtual machine also built an IPsec gateway and confirmed that it meets the usage as IPsec-VPN. After all, I found that the security measures are the same as in the case of CentOS, but it seems that there are still issues of compatibility with nftables ufw and firewalld in the future ... ⸝⸝ᵕᵕ⸝⸝
Recommended Posts