Host yltää IPsec-vastapuoleen, Docker-kontti ei

Pingaat etäisäntää Linux-koneelta ja se vastaa, joten tunneli toimii. Vieressä oleva kontti aikakatkeaa edelleen, ja luonnollinen seuraava askel on Dockerin uudelleenkäynnistys. Siltatietoverkon kontti alkaa yleensä eri lähdeosoitteella ja tulee isäntään edelleenohjauksella isännän oman sovelluksen lähtöpolun sijaan, joten onnistunut testi mittasi toisen paketin. Politiikkapohjaiselle strongSwan-tunnelille tavallinen reitti etäiseen aliverkkoon ei riitä, kun edelleenohjattu paketti ei vastaa asennettua IPsec-käytäntöä.

Alla oleva katsaus seuraa yhtä kohdetta kahden lähteen läpi ja lukee tilan ennen kuin mitään muutetaan.

Aloita yhdestä kohteesta ja kahdesta lähteestä

Valitse ensin IP:n perusteella tunnettu palvelu, jotta et samalla selvitä DNS:ää. Kirjaa kolme seikkaa: kontin siltaprefiksi, toimineen isäntäpyynnön lähdeosoite sekä tunnelille neuvotellut paikalliset ja etäiset liikennevalitsimet. Ne kolme lukua selittävät lähes jokaisen tämän oireen tapauksen.

Toista sitten epäonnistunut pyyntö kontin sisältä ja kaappaa lähde, jota se todella käyttää. Jos paikallinen valitsin ei kata tuota osoitetta, tiedät jo tuloksen, eikä kontin uudelleenluonti muuta sitä.

Lue käytännöt ennen kuin kosket Dockeriin

Vain lukemiseen tarkoitetut isäntätarkistukset kattavat reitityspäätökset, käytäntötietokannan ja ne säännöt, jotka valitsevat niiden välillä:

ip rule show
ip route show table all
ip xfrm policy

Käytäntöluettelo näyttää valitsimet ja suunnan ilman avainaineistoa täynnä olevaa IPsec-tilakaappausta, siksi se on turvallista liittää tikettiin. Etsi paikallinen valitsin, joka kattaa isännän osoitteen mutta ei siltaprefiksiä. Tarkista myös päällekkäisyys: kontin reitti, joka kohtelee etäkohdetta paikallisena, ei koskaan tuota odotettua edelleenohjattua pakettia, ja tunneli saa syyn. Tallenna luettelo kontin lähdeosoitteen viereen, sillä ne kaksi yhdessä ovat koko vertailu.

Jos kontin prefiksi puuttuu, pysähdy ja päätä arkkitehtuuri ennen kuin muutat mitään muuta. Katsauksen loppu olettaa, että olette sopineet, minkä lähdeosoitteen pitäisi näkyä verkossa.

Tarkista suodatus ja käännös järjestyksessä

Dockerin Linux-siltapalomuuri voi estää edelleenohjauksen IPsecistä riippumatta. iptables-taustalla tarkista FORWARD-polku ja DOCKER-USER-päätökset ja muista, että aiemman ratkaisun jälkeen lisätty sääntö ei välttämättä koskaan suoritu. nftables-taustalla integraatio toimii eri tavalla, joten älä luo DOCKER-USER-ketjua vain siksi, että jokin iptables-esimerkki nimesi sen; tarkista, mitä taustaa daemonisi todella käyttää.

Tarkista sitten lähdeosoitteen käännös. Laaja MASQUERADE-sääntö voi muuttaa paketin, joka aiemmin vastasi IPsec-valitsinta, sellaiseksi, joka ei enää vastaa, ja vika näyttää täsmälleen reititysongelmalta. strongSwanin edelleenohjausopas dokumentoi NAT-poikkeuksen, joka tarvitaan ennen tällaista käännöstä jo käytäntöön sopivalle liikenteelle.

Poikkeus ei ole tapa lisätä kattamaton kontin lähde tunneliin. Se suojaa vain liikennettä, joka jo sopii suunnitteluun, joten ratkaise ensin valitsinta ja paluupolkua koskevat kysymykset ja sovita sitten NAT ja suodatus vastauksen mukaiseksi. Jos alat sen sijaan laajentaa poikkeusta, muutettava asia on valitsin, ei NAT-sääntö.

Päätä sitten reititetty vai käännetty

Reititetty kontin aliverkko vaatii, että molemmat vastapuolet hyväksyvät aliverkon ja että sinne on etäinen paluupolku, mikä yleensä tarkoittaa valitsimen muutosta molemmissa päissä ja keskustelua kauemman puolen omistajan kanssa. Tarkoituksella käännetty suunnittelu sen sijaan esittää käytännön kattaman osoitteen olennaisessa hakuvaiheessa, mikä yleensä tarkoittaa kapeaa, dokumentoitua sääntöä oletusarvoisen MASQUERADEn sijaan.

Kumpikaan järjestely ei seuraa automaattisesti isännän toimivasta tunnelista, ja niiden välillä valitseminen on omistajan omaava suunnittelupäätös. Kirjoita ylös, kumman valitsit, sillä muuten seuraava insinööri johtaa sen uudelleen palomuurin laskureista.

Varo myös hybridivikaa: puolet sääntöjoukosta käännetty ja puolet ei, mikä tuottaa ajoittaista onnistumista, joka riippuu kohdeportista eikä mistään verkossa.

Varmista uudella yhteydellä, älä uudelleenkäynnistyksellä

Käytä uutta sovellusyhteyttä ja seuraa samalla kapeita palomuurilaskureita ja etävastaanottajaa, jotta jokaisella havainnolla on lähde. Dockerin uudelleenkäynnistys voi muuttaa sääntöjen tilaa ja häiritsee myös työkuormia, mikä vie sinulta sen puhtaan signaalin, jota yritit saada.

Pysyvä tulos on neljä väitettä, jotka voit näyttää: kontin lähde, vastaava suojattu polku, sallittu edelleenohjaus ja vastaus, joka palaa. Kun kaikki neljä pitävät, kontti yltää vastapuoleen samasta syystä kuin isäntä.