Enkursigado de trafiko de VM en host-only-retaro tra TUN OpenVPN-servilo

Host-only-adaptiloj kreas lokan virtualan reton, kaj enkursigitaj TUN-tuneloj portas IP-paketojn inter adresoj. Neniu el ili estas ponto al la alia, tial funkcianta agordo devas diri, kiu plusendas kaj al kiu apartenas la returna itinero. Se vi eraros pri tiuj du taskoj, la gasto respondos al la tunelo per fonto, kiun la tunela kliento neniam petis. La suba dezajno tenas ambaŭ prefiksojn apartaj kaj igas la returnan vojon eksplicita.

Du retoj, du prefiksoj

Donu al la tunela baseno kaj al la host-only-retaro malsamajn prefiksojn kaj neniam reuzu unu por la alia. En ĉi tiu ekzemplo la VPN-baseno estas 10.44.0.0/24 kaj la host-only-retaro estas 192.168.99.0/24, kun la gastiganto ĉe 192.168.99.1 kaj gasto ĉe 192.168.99.20. Asigni la saman prefikson kaj al TUN-aparato kaj al la host-only-adaptilo ne kunigas ilin. Ĝi kreas du postulojn pri unu adresaro, kaj la enkursiga tabelo poste respondas por tiu postulo, kiun ĝi hazarde konservis.

La host-only-adaptilo ekzistas sur la gastiganto kaj ene de la gasto, kaj ĝi mem ne havas vojon for de la maŝino. Pontaj kaj NAT-alkroĉoj havas malsaman elmetiĝon, kaj ŝanĝi al ponta reĝimo ne estas kondiĉo por atingi unu gastan servon.

La gastiganto jam tenas la vojon

Rigardu, kio ekzistas antaŭ ol aldoni ion. La gastiganto havas interfacon en la host-only-retaro kaj itineron por tiu prefikso, ambaŭ kreitaj kiam la adaptilo ekfunkciis.

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

La tria linio estas la mekanismo, kiu igas la gastiganton saltpunkto. Sen ĝi paketo alvenanta el la tunelo estas adresita al reto, kiun la gastiganto povas atingi sed ne plusendos. Plusendado estas necesa kaj ne sufiĉa. La filtra politiko ankoraŭ decidas, ĉu aparta fluo inter la tunela interfaco kaj la host-only-interfaco estas permesata, kaj tiu decido apartenas skribe, ne al defaŭlta politiko, kiun neniu legis.

Puŝu la itineron, poste filtru, kion ĝi atingas

La servilo povas liveri la host-only-prefikson al klientoj, kiuj akceptas puŝitajn itinerojn, kio estas la sama mekanismo uzata por iu ajn alia subreto malantaŭ la tunelo.

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

Tiuj du reguloj permesas unu servon en unu direkto kaj ĝiajn respondojn. Itinero, kiu atingas la tutan prefikson, kaj filtrilo, kiu permesas unu pordon, estas intenca kombinaĵo; itinero plus senkondiĉa akcepto estas la maniero, kiel laboratoria servo fariĝas elmetita. Puŝita itinero ankaŭ ne estas rajtigo. La kliento akceptas ĝin, la gastiganto plusendas ĝin, kaj la fajroŝirmilo de la gasto kaj la servo mem ankoraŭ havas voĉon.

La gasto bezonas returnan vojon

Gasto atingata de 10.44.0.x devas sendi siajn respondojn al la host-only-adreso de la gastiganto, aŭ la gastiganto devas traduki la fonton. Ricevi adreson de VirtualBox DHCP diras nenion pri iu ajn el la du aranĝoj.

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

Aldoni tiun itineron ene de la gasto konservas la originan fonton, kio tenas politikon kaj protokolojn por ĉiu kliento signifoplenaj. Limigita fonttraduko sur la gastiganto estas la alternativo, kaj ĝi funkcias, je la kosto kaŝi, kiu kliento konektiĝis. Interkovro estas la alia fiaskmaniero. Fora kliento, kies hejma LAN jam uzas 192.168.99.0/24, legos la puŝitan itineron kiel sian propran reton, kaj neniu ŝanĝo ĉe la servila flanko solvas tiun dusencecon. Renumeru unu flankon aŭ elektu prefikson malverŝajne kolizian.

TUN-aparato portas IP-paketojn, do aldoni defaŭltan enirejon ene de gasto ne igas la tunelon Ethernet-segmento kun la host-only-adaptilo. TAP-pontado estas malsama dezajno kun propra klienta subteno kaj adresa posedo, kaj miksi la du priskribojn kondukas al agordoj, kiuj neniam konverĝas.

Kontrolu, poste faru ĝin postvivi restarigon

Testu unu sendanĝeran servon el ordinara fora kliento, kontrolu la returnan itineron de la gasto, kaj konfirmu, ke servo, kiun vi ne permesis, estas rifuzata anstataŭ malrapida.

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

Poste restarigu la VPN-servon kaj la retadon de la virtuala maŝino kaj ripetu la samajn tri kontrolojn. Itinero aldonita permane postvivas ĝis la sekva restarigo, kaj agordo, kiu funkcias nur en varma seanco, ne estas dezajno. Notu la du prefiksojn, la plusendan politikon kaj la gastan itineron kune. Kiu aldonas la sekvan virtualan maŝinon bezonos ĉiujn tri kaj alie reeltrovos ilin unu fiaskinta konekto post la alia.