Docker eta VM trafikoa OpenVPN atzean: bideratu edo zenbakiak berritu?

Ostalariak tunelen bidez nabigatzen du eta ondoko edukiontziak ez du ezer lortzen. Bere VPN bezeroa duen edukiontzi batetik ataka bat argitaratzea okerragoa da: eskaera iristen da eta erantzuna ez da inoiz ateratzen. Biak ostalarian bideratze-erabakiak dira, eta Docker mezularia baino ez da.

Hiru galderak erabakitzen dute bi kasuetatik zein duzun aurrean, eta minutu bat inguru behar dute.

Itxura bera duten bi hutsegite

Lehena itzulera-bidearen arazoa da. Argitaratutako ataka edukiontzira itzultzen da, eskaera iristen da, eta erantzuna ostalariaren ibilbide lehenetsiaren bidez bideratzen da, OpenVPN bezeroak tun0-ra zuzendu duena. Erantzuna urruneko parekideek espero ez duten helbide batetik ateratzen da, eta baztertu egiten da. Bigarrena aurrizkien talka da: Dockeren zubi lehenetsiak 172.17.0.0/16 du eta korporazio-tunel batek tarte bera bultzatzen du.

Bata bideratze-taularekin konpontzen da, bestea zubi bat zenbakiak berrituta. Zein den zein jakin aurretik editatzea da funtzionatzen duen edukiontzi bat hondatzeko bidea.

Erabaki hiru galderarekin

Lehen galdera: desagertzen da hutsegitea VPN-a gelditzean? Tunela jaitsita dena ondo badabil, susmatu itzulera-bidea. Bigarren galdera: ip route show table all aurrizki bera bi aldiz zerrendatzen du, behin zubi batean eta behin tun0-n? Hori da talka. Hirugarren galdera: kaltetutako helbidea edukiontzi bat da, NAT bezero bat edo zubi bidezko bezero bat?

Hirugarren galderak garrantzia du, bakoitzak konponbide zuzen desberdina duelako, eta edukiontziaren konponbidea libvirt bezero bati aplikatzeak gau oso bat galtzen du.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Itzulera-bidea: taula bat iturburu-helbide baterako

Edukiontziaren trafikoak interfaze fisikoan zehar atera behar duenean ostalariak berak tunela erabiltzen duen bitartean, iturburuan oinarritutako bideratzea da aldaketarik txikiena. Gehitu edukiontziaren helbidearekin bat datorren arau bat eta bidali taula dedikatu batera. Ostalarian ez da besterik mugitzen.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Iturburua helbide hori duen pakete bakoitzak 10 taula kontsultatzen du lehenengo, eta 10 taulak zubiaren atebidera bidaltzen du tunelera beharrean.

Egiaztatu honekin: ip route get 1.1.1.1 from 172.22.0.3. Erantzunak zubiaren interfazea aipatu behar du, ez tun0. Horrela gehitutako arauak berrabiaraztean desagertzen dira, beraz jarri edukiontzia duen unitatean edo sare-kakoan.

Eredu bera funtzionatzen du WireGuard edukiontzi batean, non erantzun-bideak ere arau esplizitua behar duen.

Aurrizkien talka: berritu zubiaren zenbakiak

Bideratze-taulak aurrizki bat leku bakarrera bidaltzen du. VPN-ak 172.17.0.0/16 bultzatzen badu Dockeren zubia jada han dagoen bitartean, metrika baxuenak irabazten du: Dockerek bere ibilbide konektatua 0 metrikarekin instalatzen du, eta bultzatutako ibilbidea 50 metrikarekin iristen da. Orduan tunelak hondatuta dirudi Dockerek lanean jarraitzen duen bitartean, edo alderantziz, instalazio-ordena kontuan hartuta. Berritu zubiaren zenbakiak metrikarekin borrokatu beharrean.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Aldaketaren ondoren berrabiarazi Docker eta sortu berriro pool zaharrarekin eraikitako sareak. Metrika aldatzeak gatazka hurrengo abiaraztera eramaten du soilik.

VMek beste erantzun bat behar dute berriro

NAT sare lehenetsiko libvirt bezero batek ostalariaren bideratzea heredatzen du eta kanpora iristeari uzten dio ostalariaren tunelak ibilbide lehenetsia duenean. Bezeroa zubi edo macvtap gailu batera aldatzeak bere bidea ematen dio sare fisikoan. virt-managerren, gehitu hardwarea, aukeratu Network, jarri iturburua macvtap ostalari-gailuan, mantendu virtio modelo gisa, eta gero desaktibatu NAT interfaze zaharra.

macvtap bezero batek normalean ezin du bere ostalarira iritsi. Espero den portaera da, ez hutsegitea, eta han uzten duzun oharrean sartu behar da.

Ostalariaren LAN-a baino behar ez duen bezero batentzat, hornitzailearen bezeroak falta den etengailua izan dezake: Mullvadekin, mullvad lan set allow tokiko irisgarritasuna berreskuratzen du libvirt ukitu gabe. Eta edukiontzi bat tunelen bidez soilik irisgarria izan behar denean, lotu argitaratutako ataka tuneleko helbidera, -p 10.8.0.5:8080:8080, helbide guztietan argitaratu beharrean.