GKE-podit menettivät VPN-yhteyden version 1.14 jälkeen: kaksi tapaa korjata lähde

Päivitys saapuu, ja tunnelin toisella puolella olevat järjestelmät alkavat hylätä podien liikennettä, joka toimi edellisellä viikolla. Tunneli on pystyssä, palomuurin säännöt ovat koskemattomia, eikä kukaan muokannut vastapuolen käytäntöä. Muutos on näkymätön klusterin lokeissa: lähdeosoite, jonka nuo järjestelmät nyt näkevät. Tämä ero selittää vian, joka näyttää verkkokatkokselta ja käyttäytyy kuin käyttöoikeusongelma.

On kaksi kelvollista vastausta, ja ne vievät eri paikkoihin. Valitse lähdesopimus ennen kuin muokkaat ConfigMapia.

Oletussääntö, jota ei enää asennettu

Aiemmat GKE-julkaisut asensivat masquerade-säännön, joka korvasi podien lähteet solmun osoitteella aina, kun kohde oli 10.0.0.0/8:n ulkopuolella. Kyseisen alueen sisällä oleva VPN-yhdyskäytävä näki podin osoitteen, kun taas kauempana oleva näytti tulevan solmulta. Vastapuolet rakensivat sallittujen listoja ja paluureittejä solmujen osoitteiden ympärille, koska sitä he havaitsivat.

Myöhemmät julkaisut lakkasivat asentamasta tuota oletussääntöä. Podien liikenne saapuu nyt yhdyskäytävälle podien osoitteilla riippumatta kohteesta. Vastapuoli, joka reitittää vain solmujen osoitteita, pudottaa vastaukset, eikä kumpikaan puoli kirjoita hyödyllistä lokimerkintää. Pyyntö voi jopa onnistua kaukopäässä, ja juuri se tekee viasta vaikeasti jäljitettävän.

Mikään ei ole rikki kuolleen komponentin mielessä. Kaksi puolta vain ovat eri mieltä siitä, mikä lähde on laillinen.

Valitse lähde, jonka vastapuolen pitäisi nähdä

Podien osoitteiden säilyttäminen on tarkempi sopimus. Kaukopää näkee työkuorman, joka tuotti liikenteen, lokit pysyvät rehellisinä ja podikohtainen käytäntö tulee mahdolliseksi. Hinta on, että vastapuolen on kannettava podien etuliite.

Solmujen osoitteiden säilyttäminen on halvempi sopimus. Kytke maskeraus uudelleen päälle kyseiselle kohteelle, ja vastapuoli näkee edelleen osoitteen, johon se jo luottaa.

Yksi kysymys ratkaisee näiden välillä: mitä vastapuoli tekee lähteellä? Jos se kirjaa lokiin, soveltaa lähdekohtaista käytäntöä tai vaatii kapeaa paluureititystä, podien osoitteet oikeuttavat lisämäärityksen. Jos sen tarvitsee vain lähettää vastauksia, maskeraus maksaa vähemmän eikä vaadi toiselta puolelta mitään. Kumpi tahansa valinta on puolustettavissa, kunhan molemmat tiimit kirjoittavat sen muistiin.

Kolmas vaihtoehto on yleensä virhe: maskeraa kaikki ja menetä kyky kohdistaa liikenne. Vältä sitä, ellet vastapuoli todella pysty reitittämään mitään muuta kuin solmujen osoitteita.

Kohdista nonMasqueradeCIDRs todellisiin alueisiin

GKE ajaa ip-masq-agentia kube-systemissä, ja sen ConfigMap luettelee kohteet, jotka ohittavat maskerauksen. Jotta podien lähteet säilyvät tunneliin päin, podien alue, solmun aliverkko ja paikallinen etuliite kuuluvat kaikki tuohon listaan.

Korvaa esimerkkiarvot oman klusterisi alueilla. Älä tee listasta leveämpää kuin vaatimus edellyttää, koska jokainen lisämerkintä muuttaa sitä, mitä jokin toinen kohde näkee. Alla olevat kolme merkintää edustavat podien verkkoa, solmun aliverkkoa ja tunnelin takana olevaa etuliitettä:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Merkintä 0.0.0.0/0 poistaa maskerauksen käytöstä kaikilta kohteilta, mikä muuttaa sitä, miltä liittymättömät työkuormat näyttävät ulkoisille palveluille, ja on harvoin tarkoituksellista. Agentti lukee määrityksensä uudelleen resyncIntervalilla, joten uudelleenkäynnistys ei yleensä ole tarpeen. Tarkista, että agentin pod on käynnissä, ja avaa sitten sen sisään liitetty tiedosto. Juuri tuon tiedoston lukeminen todistaa, että muutos saapui perille.

Paluupolku on toinen puoli

Maskeraus muuttaa pyynnön lähdettä eikä mitään muuta. Minkä lähteen vastapuoli saakin, se tarvitsee yhä reitin takaisin siihen, ja klusteri tarvitsee yhä reitin vastapuolta kohti.

Kaappaus VPN-yhdyskäytävällä erottaa kaksi vikaa nopeasti. Paketit, jotka saapuvat podien osoitteilla eivätkä koskaan saa vastausta, tarkoittavat, että vastapuolelta puuttuu reitti podien etuliitteelle. Vastaus, joka ilmestyy yhdyskäytävälle mutta ei koskaan saavuta klusteria, tarkoittaa, että paikallinen reitti puuttuu. Kirjoita sopimus tikettiin joka tapauksessa: minkä lähteen vastapuoli näkee ja mihin etuliitteeseen se reitittää vastauksen.

Tarkista uudelleen jokaisen päivityksen jälkeen

Maskerauksen oletuskäyttäytyminen on jo muuttunut kerran, ja solmupoolin vaihtaminen voi nollata klusterin verkon. Käsittele lähdesopimusta asiana, joka on tarkistettava, ei asiana, joka oletetaan.

Lähetä päivityksen jälkeen yksi pyyntö podista paikalliseen palveluun ja lue lähde, jonka vastapuoli kirjaa lokiin. Se yksi havainto nappaa regression, jonka tunnelin tilasivu mielellään raportoisi terveeksi. Sen toistaminen maksaa minuutin ja säästää seuraavalta ihmiseltä illan.