Miksi julkinen Linux-palvelusi vastaa sen sijaan VPN:n kautta

Mikään socketissa ei muista, mikä liitäntä kuljetti pyynnön, joten täystunnelin VPN:n oletusreitti voi siepata vastauksen, joka kuuluu WAN:iin. Palvelu ei jätä saapumisliitäntää huomiotta; Linux reitittää paikallisesti luodun vastauksen kohteen ja lähdekäytännön mukaan. Lähdeperusteinen sääntö voi sen sijaan lähettää vain palvelun vastaukset täydellisen WAN-taulun kautta ja jättää tavallisen lähdön tunneliin. Portti pysyy auki, kun vastaus lähtee väärää polkua pitkin, ja siksi oire näyttää yksipuoliselta.

Väärinkäsitys: vastaukset seuraavat liitäntää, jolta ne saapuivat

Tuntuu loogiselta, että eth0:lle saapuva paketti lähtisi eth0:lta. Tilattomat pakettisuodattimet voidaan kirjoittaa niin, ja tcpdump saapuvalla puolella näyttää pyynnön täsmälleen siellä, missä sitä odotetaan. Reititys ei toimi niin liikenteelle, jonka isäntä itse luo.

Kun palvelu hyväksyy yhteyden, sen vastaus on uusi paikallisesti luotu paketti. Ydin tarkistaa reitityssäännöt vastauksen kohteen ja lähteen osalta, ja VPN:n oletusreitti on täysin kelvollinen vastaus. Mikään socketissa ei muista, mikä liitäntä kuljetti pyynnön.

Siksi oire näyttää yksipuoliselta: pyynnöt saapuvat, vastaukset katoavat. Siksi myöskään palomuurisäännön lisääminen saapuvan portin osalta ei muuta mitään. Pakettia ei estetä sisäänmenomatkalla; se reititetään muualle ulostulomatkalla. Seuraa vastausta lähteellä täsmennetyllä haulla, niin kiertotie tulee näkyviin.

Mitä ydin oikeasti reitittää: lähdeosoite

Tarvitsemasi kahva on paikallinen osoite, jota palvelu käyttää vastauksiin. Isännässä, jonka havainnollistava eth0-osoite on 192.0.2.10/24 ja yhdyskäytävä 192.0.2.1, tämä osoite on liitännällä. Pilven VM:ssä julkinen osoite voi olla ylempänä käännetty ja puuttua vierasjärjestelmästä, joten käytä osoitetta, joka isännällä todella on.

Tarkista nykyinen tila ennen taulun numeron tai säännön prioriteetin varaamista. Olemassa olevat käytäntösäännöt voivat peittää uuden, ja samannumeroisessa vanhassa taulussa voi jo olla asiaankuulumattomia reittejä:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Valitse sitten taulu lähteen mukaan. Sääntö täsmää vastauksiin, jotka jo kantavat 192.0.2.10:tä, eli täsmälleen siihen paikallisesti päätettyyn liikenteeseen, jonka haluat jättää pois. Edelleen välitetty liikenne ja muiden paikallisten osoitteiden paketit eivät täsmää.

Rakenna täydellinen paluutaulu, älä puolikasta oletusreittiä

Taulu, jossa on vain oletusreitti, ei riitä. Ytimen on vielä ratkaistava yhdyskäytävä, ja tuo ratkaisu tarvitsee yhdistetyn etuliitteen samassa taulussa. Taulu, josta tämä etuliite puuttuu, epäonnistuu yhdyskäytävän ratkaisussa, vaikka sen oletusreitti näyttäisi oikealta. Lisää molemmat ja osoita sitten lähdesääntö tauluun:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Käytä todellista etuliitettä ja yhdyskäytävää äläkä kopioi esimerkkiä. Pilviliitäntä, joka on määritetty /32:ksi linkin yhdyskäytävällä, tarvitsee erilaisen yhdistetyn reitin, ja väärästä etuliitteestä rakennettu taulu epäonnistuu ensimmäisellä hypyllä. Attribuutti src ilmoittaa kyseisen reitin ensisijaisen lähteen; se ei korvaa lähdesääntöä.

Järjestyksellä on myös merkitystä. Laaja sääntö, jolla on pienempi prioriteettinumero, arvioidaan ensin, joten lähdesääntöön on päästävä ennen mitä tahansa sääntöä, joka lähettäisi tämän liikenteen takaisin päätauluun. Tarkista prioriteetit ip rule show:lla lisäämisen jälkeen, älä vain käynnistyksessä.

Vahvista lähteellä täsmennetyllä haulla

Pyydä ydintä reitittämään testikohde palvelun osoitteesta. Vastauksen pitäisi nimetä eth0 ja WAN-yhdyskäytävä, ei tunnelia:

ip -4 route get 198.51.100.25 from 192.0.2.10

Luo sitten uusi valtuutettu yhteys ja seuraa molempia suuntia. Haku, joka valitsee oikean taulun, kun live-yhteys edelleen epäonnistuu, viittaa käänteisen polun suodatukseen tai palomuurisääntöön, ei tauluun. Tarkista nämä ohjaimet ennen kuin poistat mitään käytöstä maailmanlaajuisesti.

Aseta lopulliset reitit ja sääntö sen verkkohallinnan alle, joka omistaa liitännän. Osoitemuutokset, DHCP:n uusiminen ja VPN:n uudelleenyhdistämiset kirjoittavat kaiken ytimen tilan uudelleen, ja käsin lisätty sääntö katoaa tai osoittaa vanhentuneeseen yhdyskäytävään seuraavan tapahtuman jälkeen.

Mihin tämä poikkeus päättyy

Sääntö vapauttaa paikallisesti päätetyn liikenteen yhdestä lähdeosoitteesta. Se ei kata Dockerin julkaisemia portteja, DNAT:ia tai isännän kautta välitettyjä palveluita, koska ne paketit reititetään välitettynä liikenteenä eivätkä koskaan kanna isännän paikallista lähdettä samalla tavalla. Sellaiset ratkaisut tarvitsevat yleensä sisääntulossa asetetun merkin ja merkin täsmäävän säännön.

Se ei myöskään saa isännän julkista osoitetta näkymään liitännällä. Kun ylempi NAT omistaa kyseisen osoitteen, vastauksen on silti lähdettävä polkua, jota se NAT odottaa, minkä vuoksi WAN-taulun on heijastettava alkuperäistä yhdyskäytävää ja etuliitettä eikä arvattua julkista aluetta.

Pidä poikkeus dokumentoituna taulun numeron, säännön prioriteetin ja tarkan lähdeosoitteen kanssa. Seuraava muutos VPN:ssä tai liitännässä voi rikkoa sen hiljaa, ja kolme arvoa nimeävä muistiinpano on nopeampi tarkistaa kuin oireen löytäminen uudelleen asiakasraportista.

Jos palvelu vastaa edelleen väärää polkua pitkin, kun lähteellä täsmennetty haku onnistuu, vertaa live-socketin lähdeosoitetta säännössä olevaan. Jokerimerkkiosoitteeseen sidottu palvelu voi valita eri lähteen kuin testaamasi osoite, ja tämä ero on jäljellä oleva aukko.