VM trafika maršrutēšana host-only tīklā caur TUN OpenVPN serveri

host-only adapteri izveido lokālu virtuālo tīklu, un maršrutēti TUN tuneļi pārnēsā IP paketes starp adresēm. Neviens no tiem nav tilts uz otru, tāpēc strādājošai konfigurācijai jāsaka, kas pārsūta un kam pieder atgriešanās maršruts. Sajaucot šos divus piešķīrumus, viesis atbild tunelim ar avotu, ko tuneļa klients nekad nav prasījis. Zemāk esošais risinājums tur abus prefiksus atsevišķi un padara atgriešanās ceļu skaidru.

Divi tīkli, divi prefiksi

Piešķiriet tuneļa baseinam un host-only tīklam dažādus prefiksus un nekad neizmantojiet vienu otra vietā. Šajā piemērā VPN baseins ir 10.44.0.0/24 un host-only tīkls ir 192.168.99.0/24, hosts ir 192.168.99.1 un viesis ir 192.168.99.20. Viena un tā paša prefiksa piešķiršana gan TUN ierīcei, gan host-only adapterim tos nesavieno. Tas rada divas pretenzijas uz vienu adrešu diapazonu, un maršrutēšanas tabula tad atbild par to pretenziju, kuru nejauši paturēja.

host-only adapters pastāv uz hosta un viesa iekšienē, un tam pašam par sevi nav ceļa ārā no mašīnas. Tilta un NAT savienojumiem ir atšķirīga iedarbība, un pāreja uz tilta režīmu nav nosacījums, lai sasniegtu vienu viesa pakalpojumu.

Hosts jau tur ceļu

Apskatieties, kas ir, pirms kaut ko pievienojat. Hostam ir saskarne host-only tīklā un maršruts šim prefiksam, abi izveidoti, kad adapters pacēlās.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Trešā rinda ir mehānisms, kas hostu pārvērš lēcienā. Bez tā no tuneļa atnākušais pakets tiek adresēts tīklam, kuru hosts var sasniegt, bet nepārsūtīs. Pārsūtīšana ir nepieciešama un nav pietiekama. Filtrēšanas politika joprojām izlemj, vai konkrēta plūsma starp tuneļa saskarni un host-only saskarni ir atļauta, un šim lēmumam jābūt rakstiskam, nevis noklusējuma politikā, ko neviens nav lasījis.

Pabīdiet maršrutu, pēc tam filtrējiet, ko tas sasniedz

Serveris var nodrošināt host-only prefiksu klientiem, kas pieņem pabīdītus maršrutus, un tas ir tas pats mehānisms, ko izmanto jebkuram citam apakštīklam aiz tuneļa.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Šie divi noteikumi atļauj vienu pakalpojumu vienā virzienā un tā atbildes. Maršruts, kas sasniedz visu prefiksu, un filtrs, kas atļauj vienu portu, ir apzināta kombinācija; maršruts kopā ar beznosacījumu pieņemšanu ir ceļš, kā laboratorijas pakalpojums kļūst atklāts. Pabīdīts maršruts arī nav pilnvarojums. Klients to pieņem, hosts to pārsūta, un viesa ugunsmūris un pats pakalpojums joprojām saka savu vārdu.

Viesim vajag ceļu atpakaļ

Viesim, kas sasniegts no 10.44.0.x, atbildes jāsūta uz hosta host-only adresi, vai hostam jātulko avots. Adreses saņemšana no VirtualBox DHCP neko nepasaka par nevienu no šiem diviem izkārtojumiem.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Šī maršruta pievienošana viesa iekšienē saglabā sākotnējo avotu, un tas saglabā jēgpilnu katram klientam paredzēto politiku un žurnālus. Ierobežota avota tulkošana uz hosta ir alternatīva, un tā strādā, bet par cenu, ka tiek slēpts, kurš klients savienojās. Pārklāšanās ir otrs kļūmes režīms. Attālināts klients, kura mājas LAN jau izmanto 192.168.99.0/24, pabīdīto maršrutu lasīs kā savu tīklu, un neviens servera puses grozījums šo neskaidrību neatrisina. Pārnumurējiet vienu pusi vai izvēlieties prefiksu, kas, visticamāk, nesadursies.

TUN ierīce pārnēsā IP paketes, tāpēc noklusējuma vārtejas pievienošana viesa iekšienē nepārvērš tuneli par Ethernet segmentu ar host-only adapteri. TAP tilts ir cits risinājums ar savu klientu atbalstu un adrešu īpašumtiesībām, un abu aprakstu sajaukšana noved pie konfigurācijām, kas nekad nesatiekas.

Pārbaudiet, pēc tam padariet to izturīgu pret pārstartēšanu

Izmēģiniet vienu nekaitīgu pakalpojumu no parasta attālināta klienta, pārbaudiet viesa atgriešanās maršrutu un pārliecinieties, ka pakalpojums, kuru neļāvāt, tiek noraidīts, nevis ir lēns.

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Pēc tam restartējiet VPN pakalpojumu un virtuālās mašīnas tīklu un atkārtojiet tos pašus trīs pārbaudījumus. Ar roku pievienots maršruts pastāv līdz nākamajai pārstartēšanai, un konfigurācija, kas strādā tikai siltā sesijā, nav risinājums. Piefiksējiet abus prefiksus, pārsūtīšanas politiku un viesa maršrutu kopā. Tas, kurš pievienos nākamo virtuālo mašīnu, visus trīs atradīs vajadzīgus, un citādi viņš tos no jauna atklās pa vienam neizdevušamies savienojumam.