Af hverju macvlan-gámur getur ekki svarað VPN-biðlara

Ímyndaðu þér Linux-hýsil sem lýkur VPN og keyrir líka gám á macvlan-neti. LANið er 192.168.60.0/24, gámurinn hefur 192.168.60.210 og VPN-biðlarar koma frá 10.95.0.0/24. Biðlarinn nær í þjónustuna, svarið kemur aldrei til baka og hver eldveggjarregla á hýslinum virðist rétt. Tvö aðskilin takmörk valda þessum einkennum, og að laga annað skilur hitt eftir á sínum stað.

Tvö takmörk, ein einkenni

Fyrra takmarkið er einangrun: macvlan-ökumaður Docker leyfir ekki gámi að tala við sinn eigin hýsil í gegnum foreldraviðmótið. Umferð milli stafla hýsilsins og gámsins hefur enga leið, hvernig sem leiðirnar á hýslinum eru skrifaðar.

Seinna takmarkið er afturleiðin. Sjálfgefin gátt gámsins er venjulega LAN-leiðarinn, svo svar sem er beint til VPN-biðlara fer út um þann leiðara. Ef leiðarinn hefur enga leið til baka í VPN-safnið er svarinu hent einhvers staðar í miðjunni.

Þessi tvö bil líta eins út frá sjónarhóli biðlarans: beiðni sem berst og svar sem kemur aldrei. Þau þurfa mismunandi viðgerðir, og breið masquerade-regla getur falið hvort þeirra er enn í ólagi. Þess vegna er fyrsta prófið upptaka á gámahliðinni frekar en önnur eldveggjabreyting. Ef beiðnin birtist þar aldrei er það einangrunartakmarkið sem er í gangi.

Byggðu shimið á hýsilhliðinni, þröngt

Annað macvlan-viðmót á hýslinum, tengt sama foreldri í brúarham, gefur stafla hýsilsins sína eigin auðkenni á því LAN-hluta. Taktu frá því vistfang utan DHCP-safnsins og utan sviðs gámsins, og beindu aðeins gámnum í gegnum það.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Fyrsta skipunin býr til viðmótið í brúarham, sem er skjalfest sjálfgefið gildi fyrir þennan ökumann og sá hamur sem þú vilt fyrir umferð milli hýsils og gáms. Sú önnur úthlutar /32 svo vistfangið rekist ekki á LAN-forskeytið, og sú fjórða sendir aðeins vistfang gámsins í gegnum shimið.

Beindu ekki öllu LANinu í gegnum nýja viðmótið. Venjulega tengda leiðin helst óbreytt, og leið hýsilsins er vísvitandi þröng svo einn gámur fái leið án þess að afgangur hlutans breyti hegðun sinni. Sjálfgefin leið að shiminu væri önnur hönnun með öðrum afleiðingum. Haltu henni nákvæmri og skaðasviðið helst lítið.

Þessar skipanir breyta netstillingum á hýsli í notkun. Á tæki eða stýrðum vettvangi skaltu nota studda stillingaraðferð þess vettvangs, því gagnvirk breyting í root-skelf gæti ekki lifað uppfærslu af.

Ákveddu hvernig uppruninn er varðveittur

Með shimið á sínum stað getur gámurinn náð í hýsilinn, og spurningin verður hvaða upprunavistfang svarið ber. Að varðveita upprunalega VPN-upprunann er hreinna módelið: gámurinn sér raunverulegt vistfang biðlarans, og skrár og aðgangsreglur þjónustunnar geta notað það.

Til að það virki verður netstilling gámsins að senda umferð fyrir 10.95.0.0/24 á 192.168.60.250 sem gátt sína fyrir þessa leið. Það er studd leiðar- eða gáttarstilling innan eigin stillingar gámsins, ekki bragð á hýsilhlið. Staðfestu það innan úr gámnum í stað þess að gera ráð fyrir að stillingin hafi tekið gildi. Sjálfgefin gátt sem bendir enn á LAN-leiðarann mun halda áfram að senda svör í sama gatið.

Ef samþykkta hönnunin felur upprunana VPN í staðinn skaltu afmarka þýðinguna þröngt: raunverulega VPN-safnið, shimið sem útviðmót og tiltekinn gámur og þjónusta.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Paraðu shimið sem útviðmót, ekki göngin. Regla sem nefnir göngin sem útviðmót passar ekki við pakka á leið að gámnum, og það er mistakið sem svona uppsetning inniheldur venjulega. Haltu reglunni eins þröngri og setningin hér að ofan og endurskoðaðu hana þegar safnið breytist.

Staðfestu frá biðlaranum, ekki frá hýslinum

Beiðni frá hýslinum sjálfum, bundin við vistfang shimsins, sannar að shimið nái í gámuna. Hún sannar ekki að gámurinn geti sent umferð til baka til varðveitts uppruna 10.95.0.x, því upprunavistfangið í því prófi er vistfang shimsins sjálfs.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Fyrsta skipunin prófar kaflann frá hýsli að gámi, og sú önnur sýnir hvað fer í raun í gegnum shimið meðan raunverulegur VPN-biðlari sendir beiðnina. Horfðu á upprunavistfangið á innleið og hvort svar birtist með sama flæði.

Vista þarf áframleiðslu á hýslinum, og áframleiðsluleiðin þarf heimild fyrir VPN-safnið að shiminu á þjónustuhliðinni ásamt uppsettum svörum. INPUT-regla á hýslinum heimilar ekki áframleidda umferð, og það er algeng ástæða þess að pakkanum er hent eftir að leiðsögn virðist rétt.

Keyrðu raunverulega forritið með raunverulegum skilríkjum og athugaðu svo að önnur, ótengd þjónusta á sama gámi synji þér enn. Ef eina leiðin til að láta það virka var að opna hverja áframleiðslureglu er hönnunin ekki fullbúin. Taktu líka eftir hvaða upprunavistfang þjónustan skráði, því það munu eigin aðgangsreglur hennar nota héðan í frá.