Jinsi ya kuelekeza trafiki ya kontena za Docker pekee kupitia OpenVPN

Acha mwenyeji kwenye uplink yake ya kawaida na weka subnet moja ya kontena kwenye handaki: mpangilio wa NAT, sheria za chanzo, iroute ya OpenVPN na ukaguzi wa MSS.

Pakiti ya kontena haifiki kamwe tun0 , na uwezo wa ziada kwenye kontena hautabadilisha hilo. Kati ya mgeni na handaki kuna utafutaji wa njia mbili: mmoja ndani ya nafasi ya majina ya mtandao wa mgeni, mmoja kwenye mwenyeji baada ya fremu kutua kwenye daraja, na wa pili unauliza jedwali lingine lenye kanuni tofauti za ulinganifu. Mpangilio wangu wa marejeleo ni mwenyeji wa Linux anayeendesha OpenVPN mteja anayeshikilia 10.8.0.10 kwenye tun0 , daraja la Docker kwenye 172.18.0.0/16 , na anwani ya faragha ambayo upande wa handaki pekee unaweza kufikia. Lengo linabaki jembamba: subnet hiyo ya mgeni inatoka kupitia handaki wakati mwenyeji anabakiza uplink yake ya kawaida.

Kuendesha mteja wa VPN ndani ya kontena ni muundo mwingine , si njia ya mkato. Wakati huo kontena linamiliki handaki yake na vitambulisho vyake, na kazi inahamia kwenye Dockerfile badala ya kubaki kwenye iptables.

Upelekaji huchagua njia kwa lengwa, kisha NAT huandika upya chanzo

Wakati net.ipv4.ip_forward=1 imewekwa, pakiti inayopelekwa huelekezwa kwa lengwa pekee, kwenye jedwali kuu. Chanzo hakina nafasi yoyote katika uamuzi huo. Ni baada ya njia kuchaguliwa tu ndipo kernel huendesha POSTROUTING , na hapo ndipo sheria ya Docker yenyewe ilipo: -s 172.18.0.0/16 ! -o br-appnet -j MASQUERADE . Kila kitu kinachoacha daraja kuelekea kiolesura kingine hutafsiriwa, na anwani inayokuwa inategemea kiolesura ambacho njia ilimtuma.

Sheria hiyo inaeleza dalili nyingi ninazoulizwa. Ikiwa jedwali kuu halina njia ya lengwa la faragha, pakiti inatoka kupitia uplink ikiwa imebeba anwani ya kimwili ya mwenyeji. Mtoa huduma wako hutupa lengwa, au tovuti ya mbali hutupa chanzo cha RFC 1918 ambacho hakikutegemea, na kontena linapata muda umeisha wakati handaki linasimama na likiwa zuri. Kunasa kwenye tun0 hakuonyeshi kitu, na hiyo ndiyo ishara. Ikiwa njia inaelekea tun0 , MASQUERADE huandika upya chanzo kuelekea 10.8.0.10 , na kontena hilo hilo hufanya kazi bila wewe kugusa chochote.

Omba utafutaji unaotaja chanzo cha mgeni. Bila from na iif mwenyeji hujibu kwa soketi yake mwenyewe na huripoti njia ambayo pakiti iliyopelekwa haitawahi kuichukua:

ip route get 192.168.11.222 from 172.18.0.5 iif br-appnet

Ikiwa jibu hilo linataja uplink, handaki haliko kwenye picha na hakuna mpangilio wa upande wa handaki utakaosaidia.

Hamishia mgeni kwenye anwani ya handaki yenyewe

Mabadiliko madogo yanayofanya kazi ni uandikaji upya wazi wa chanzo wakati wa kutoka. Ingiza badala ya kuongeza: Docker tayari imekaa kwenye kichwa cha POSTROUTING , kwa hiyo sheria iliyoongezwa kwa -A hutathminiwa nyuma ya ile ya Docker na haiwashi kamwe.

iptables -t nat -I POSTROUTING 1 -s 172.18.0.0/16 -o tun0 -j SNAT --to-source 10.8.0.10

Masharti mawili huamua kama hili litadumu. Anwani lazima iwe ile ambayo mteja anayo kweli, kwa hiyo ibandike kwa ingizo kwa kila mteja lenye ifconfig-push 10.8.0.10 255.255.255.0 ; sheria inayotaja anwani ambayo haijawahi kutolewa huzalisha matone ya kimya, si hitilafu. Na upande wa mbali lazima ukubali chanzo hicho na kuelekeza majibu kurudi, ndiyo maana orodha ya ruhusa huko hutaja anwani ya handaki si subnet ya mgeni. Wakati anwani ya mteja inabadilika, -j MASQUERADE pamoja na -o tun0 hufuata kile kiolesura kilicho nacho, kwa gharama ya sera ya mbali ambayo huwezi kuandika thamani isiyobadilika dhidi yake.

Uchujaji ni nusu nyingine. Docker huweka sera ya FORWARD kwenye drop na hufuta minyororo inayomiliki kila daemon inapoanza upya, kwa hiyo weka sera ya ndani kwenye DOCKER-USER , ambayo hudumu:

iptables -I DOCKER-USER -i br-appnet -o tun0 -j ACCEPT
iptables -I DOCKER-USER -i tun0 -o br-appnet -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sheria ya kurudi ni muhimu: jibu linalofika kwenye tun0 kwa muunganisho uliofunguliwa na daraja halikubaliwi kwa sababu tu mwelekeo wa kutoka ulikubaliwa.

Weka mwenyeji moja kwa moja kwa sheria ya chanzo

Wakati daraja lote linapaswa kutumia handaki lakini hakuna kingine kwenye mwenyeji, ruka NAT na upe chanzo hicho jedwali lake. Anwani za mgeni basi zinabaki zinaonekana kutoka mwanzo hadi mwisho.

echo "200 vpnbox" >> /etc/iproute2/rt_tables
ip rule add from 172.18.0.0/16 lookup vpnbox pref 1000
ip route add default dev tun0 table vpnbox

Sheria hushauriwa kabla ya jedwali kuu, na from hulingana na chanzo. Pakiti za nje za handaki yenyewe hubeba chanzo cha kimwili cha mwenyeji, kwa hiyo hazilingani kamwe na from 172.18.0.0/16 , na handaki haliwezi kuelekeza yenyewe kurudi ndani yake. Kutojumuisha huko ndiko kunafanya mpangilio kuwa thabiti.

Njia ya kurudi sasa inahitaji msaada. Upande wa mbali unaona 172.18.0.x isiyotafsiriwa na hauna sababu ya kujua inapoishi. Kwenye seva, faili kwa kila mteja inahitaji iroute 172.18.0.0 255.255.0.0 ili jedwali la ndani la seva limpe kiambishi hicho mteja huyu, na route 172.18.0.0 255.255.0.0 iliyosukumwa ili wateja wengine wajue kwamba ipo.

Ukaguzi mbili kabla ya kuamini. Endesha ip route show default : pamoja na redirect-gateway def1 jedwali lina 0.0.0.0/1 na 128.0.0.0/1 kupitia tun0 , na mwenyeji hakai moja kwa moja hata kidogo, kwa sababu nusu-chaguo hizo hushinda bila kubadilisha default . Sheria zilizoongezwa kwa ip rule add pia hutoweka kwenye kuwasha upya, kwa hiyo zibebe kwenye skripti ya up.

Ukubwa wa pakiti ni hitilafu ya pili unayokutana nayo

Kiolesura cha daraja cha baiti 1500 hulipa handaki zaidi ya inavyoweza kubeba vichwa vya nje vya UDP na IP vinapoongezwa. Mabadilishano madogo hupita, kwa hiyo DNS hutatuliwa na kupeana mikono kwa TLS hukamilika, kisha upakiaji mkubwa huning'inia bila hitilafu yoyote mahali popote. Mtumaji huendelea kurudia ukubwa huo wa sehemu kwa sababu ujumbe wa ICMP kuhusu hitaji la kugawanyika, ambao ungemwambia apunguze, haufiki kamwe.

Rekebisha kwenye kiolesura, kwenye MSS, au vyote viwili. Ukandamizaji hauhitaji ushirikiano wa mgeni:

ip link set dev tun0 mtu 1400
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ukandamizaji huandika upya TCP pekee. UDP, ikiwa ni pamoja na QUIC, inahitaji badala yake kiolesura cha mgeni kilichopunguzwa, pamoja na --opt com.docker.network.driver.mtu=1400 wakati wa kuunda mtandao au ufunguo wa compose unaolingana.

DNS na ukaguzi unaostahili kurudiwa

Utatuzi wa majina hufuata njia hiyo hiyo. Kitatuzi kilichopachikwa cha Docker kwenye 127.0.0.11 hupeleka kwa seva zilizosanidiwa za mwenyeji, kwa hiyo kontena hurithi kile mwenyeji anachotumia. Wakati eneo la faragha linajibiwa na kitatuzi kinachofikika kupitia handaki pekee, elekeza mgeni kwenye anwani hiyo, na ujaribu kwa getent hosts ndani ya kontena badala ya kwenye mwenyeji.

  • Endesha ombi linaloshindwa ndani ya mgeni; jaribio la upande wa mwenyeji hutumia anwani nyingine ya chanzo na huficha tatizo.
  • Soma vihesabu kwenye sheria za NAT na uchujaji ulizoongeza. Sheria isiyo na ulinganifu wowote ni kosa la uelekezaji, si kosa la sera.
  • Thibitisha kwamba anwani ya handaki kwenye sheria yako ya SNAT ni ile ambayo mteja anayo kweli.
  • Punguza MTU ya mgeni au kandamiza MSS kabla ya kulaumu seva kwa kukwama.

Pitia orodha hiyo na usimame kwenye hitilafu ya kwanza. Tabaka hilo ndilo la kurekebisha; kitu chochote kilichoongezwa chini zaidi huficha tu mpaka unaovunjika.

Makala zinazohusiana