Paikallinen sovellus, VPN-sääntö: miksi FORWARD-ketjusi ei koskaan laukea

Lisäät VPN-liikenteelle säännön FORWARD-ketjuun, ajat pyynnön samalta Linux-koneelta, ja laskuri jää nollaan. Sääntö on todennäköisesti oikein. Paketti ei koskaan kulkenut sitä polkua, koska koneella itsellään syntynyttä pyyntöä se ei välitä eteenpäin. Paketin elämän seuraaminen socketista johtoon selittää miksi, ja mihin sääntö oikeastaan kuuluu.

Selvitä, missä paketti syntyi

Netfilterin koukkujen järjestys erottaa kolme tapausta, ja vain yksi niistä koskee FORWARDia:

Paikallinen sovellus alkaa OUTPUT-polulta, koska ydin on jo todennut, että paketti syntyy tässä eikä ole koskaan välityksen ehdokas. Tunnelin luominen ei muuta tätä luokitusta; tunneli on laite, jonka kautta paketti voi lähteä, ei vaihe, joka muuttaa paikallisen lähdön läpikulutransitioksi.

Kaksi pakettia, yksi tarina

Kun tunneli on pystyssä, sovelluksen sisempi paketti ja salattu ulompi paketti ovat eri objekteja. Sisempi paketti kuljettaa kohteen ja hyötykuorman, jonka sovellus valitsi. Ulompi paketti kuljettaa salatekstin vertaiskumppanin osoitteeseen ja porttiin, ja juuri se ylittää fyysisen rajapinnan.

Käytäntösi koskee toista niistä, ja väärän valitseminen on yleinen syy sille, että sääntö näyttää tekevän ei mitään. Sääntö, joka vastaa vertaisen ulompaa osoitetta, näkee jokaisen tunnelipaketin samalla tavalla, mitä sovellus sisällä tekee tahansa. Sääntö, joka vastaa sisempää kohdetta, näkee liikenteen, josta välität, ja se laukeaa vain, jos paketti saapuu koukulle, jolle asensit säännön.

Nimiavaruudet siirtävät rajaa

Kontti vaikeuttaa tätä muuttamatta periaatetta. Sovelluksen pyyntö on paikallinen lähtö kontin verkkonimiavaruuden sisällä. Isäntä vastaanottaa liikenteen virtuaalisella Ethernet-rajapinnalla ja voi välittää sen, joten isännän FORWARD-sääntö voi olla mielekäs, vaikka pyynnön synnyttänyt prosessi ei koskaan koskenut isännän OUTPUT-ketjuun.

Ennen koukun valintaa selvitä, missä sääntöjoukko ja tunneli todella sijaitsevat. Tunneli kontin sisällä, tunneli isännällä kontti sen kautta reititettynä ja tunneli erillisessä nimiavaruudessa ovat kolme erilaista topologiaa ja kolme erilaista säännön sijoittelua. Lue säännöt sen nimiavaruuden sisällä, joka omistaa laitteen, älä vain oletusarvoisesta.

Kysy, tarvitsetko merkkiä lainkaan

Jos tavoitteena on lähettää yksi kohdeprefiksi tunnelin kautta, reitti sille prefiksille voi riittää. Tarkista ensin voimassa olevat reitit, mukaan lukien kaikki, mitä palvelin työnsi: uudelleenohjattu oletusreitti lähettää VPN:n kautta paljon enemmän liikennettä kuin kapea käytäntö, jonka ajattelit, eikä mikään määrä merkintää saa tulosta vastaamaan aikomusta.

Luokittelu tarvitaan, kun päätös riippuu jostakin, jota reitti ei voi ilmaista, kuten lähteestä, käyttäjästä tai prosessista. Vastaanotetulle liikenteelle merkintä PREROUTINGissa toimii. Paikalliselle liikenteelle merkinnän on tapahduttava lähtövaiheessa, joka voi laukaista uuden reittihaun merkin asettamisen jälkeen. Nftablesissa se on route-tyyppinen ketju lähtökoukulla; tavallinen lähtösuodatinketju asettaa arvon ja jättää reitin ennalleen.

Iptablesissa vastine elää mangle OUTPUT -järjestelyssä, ja sama vaatimus pätee: reitityspäätös on tarkasteltava uudelleen, kun merkki on olemassa. Sen jälkeen käytäntösäännön on kulutettava merkki ja osoitettava tauluun, jossa on käyttökelpoinen reitti. Conntrack-merkin asettaminen on kolmas, erillinen toimenpide; se tallentaa arvon virralle eikä itsessään aseta sitä arvoa nykyiselle paketille reitityksen luettavaksi.

Tarkista haku ja laskuri yhdessä

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Osoite ja merkki ovat havainnollisia, ja kaksi reittikyselyä vastaavat eri kysymyksiin. Toinen kysyy, mitä ydin tekisi, jos paketti kantaisi tuon merkin; se ei osoita, että sääntöjoukkosi jakaa sellaista. Kohtele sitä hypoteesin testinä, älä todisteena siitä, että käytäntö toimii.

Aja sitten vaaraton pyyntö ja katso kahta asiaa samalla kertaa: valitsemasi koukun laskuria ja lähtöä, jonka paketti todella otti. Jos laskuri liikkuu ja paketti lähtee muualle, merkki tai taulu on väärä. Jos kumpikaan ei liiku, paketti ei saavuta koukkuakaan, ja seuraava kysymys on nimiavaruus tai polku.

Rajoita lopuksi testi siihen, minkä mekanismi voi ilmaista. Yksi reitti yhdelle osoitteelle ei muutu pysyväksi käytännöksi palvelulle, jonka osoitteet vaihtuvat. Päätä ensin pakettien laajuus ja tarkista sitten, pystyykö reititys- ja merkintäratkaisu pitämään sen laajuuden uudelleenyhdistämisen jälkeen.