Lähdeperusteinen reititys kahdelle VPN-poolille: mitä sääntösi jättää huomaamatta

Kaksi asiakaspoolia, yksi yhdyskäytävä ja suunnitelma näyttää triviaalilta: yksi sääntö lähettää ensimmäisen poolin nopealle uplinkille, toinen lähettää toisen poolin kumppanin tunneliin. Sitten säännöt ovat paikallaan ja toinen pooli lähtee silti oletusreittiä. Sääntö ei ole rikki. Paketin lähde ei ole se, mitä kirjoittaja odotti hautapaikalla, koska käännös ja haku tapahtuvat saman paketin matkan eri pisteissä ja järjestys on päinvastainen kuin se mielikuva, jonka useimmat piirtävät.

Haku tapahtuu ennen kuin lähde kirjoitetaan uudelleen

VPN-asiakkaalta välitettävälle paketille ydin suorittaa kiinteän järjestyksen. Se saapuu tunnelirajapinnalle, kulkee preroutingin läpi, jossa conntrack ja DNAT asuvat, sitten tehdään reitityspäätös, sitten välitys, sitten postrouting, jossa SNAT sovelletaan viimeisenä. Muotoa from oleva sääntö tarkistetaan tuon reitityspäätöksen aikana, eli se näkee asiakkaan alkuperäisen osoitteen, ei käännettyä.

Niinpä masquerade-säännön lisääminen ei muuta sitä, mikä käytäntö vastaa lähtevää virtaa. Se muuttaa sitä, mitä kaukopää näkee, ja siten sitä, mikä paluupolku on olemassa. Nämä ovat kaksi eri seurausta, ja muutosten katselmoinnit sekoittavat ne jatkuvasti. Erota ne, niin suunnittelu käy yleensä selväksi minuutissa.

Vastaussuunnassa käännetty osoite näkyy säännöissä. Yhdyskäytävälle palaava paketti on osoitettu käännetylle osoitteelle, ja jos sinulla on käytäntösääntöjä, jotka perustuvat kohteeseen tai rajapintaan, jolta se saapui, se on arvo, jota vastaat. Sama yhteys, eri totuuden lähde kummassakin suunnassa.

Kahdella eri lähteellä varustetulla poolilla on siis todella oltava eri taulukot, ja suunnittelu on terve. Yllä oleva taulukko sulkee pois oikotien, jossa vianetsintä tehdään katsomalla, mitä kaukosivusto vastaanotti, ja päättelemällä sääntö siitä.

Testi yhdyskäytävältä ei ole poolin testi

Yhdyskäytävän itse tuottama liikenne ei koskaan kulje preroutingin läpi, koska se ei saapunut rajapinnalle. Se reititetään lähtöpolulla yhdyskäytävän oman osoitteen ollessa lähteenä, eikä asiakasalueeseen sidottu from-sääntö vastaa. Jokainen tämän alan tiketti, joka sanoo, että laatikosta toimii mutta asiakkaalta ei, on tuon saman tosiasian toisto.

Jäljittele asiakasta sen sijaan, että arvioisit sitä. Reitityshakua voi kysyä suoraan, kun lähde ja tulorajapinta annetaan:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Suorita se kerran poolia kohden. Jos molemmat komennot palauttavat saman rajapinnan, säännöt eivät erottele pooleja, ja syy on joko puuttuva sääntö tai korkeamman prioriteetin sääntö, joka vastaa molempia. Jos ne palauttavat eri rajapinnat mutta asiakas epäonnistuu silti, vika on haun jälkeen ja voit lopettaa sääntöjen tutkimisen.

Prioriteetti, ei sijainti tiedostossa

Säännöt arvioidaan nousevassa prioriteettijärjestyksessä, ja luku ratkaisee, ei se järjestys, jossa ne kirjoitit. local-taulu on prioriteetilla 0, main-taulu 32766:lla ja oletussääntö 32767:llä, siksi oletusprioriteetilla lisätty sääntö päätyy lähelle listan loppua ja häviää melkein kaikelle.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Selkeä prioriteetti tekee aiotun järjestyksen näkyväksi tiedostossa ja katselmoinnissa. Se myös estää myöhempää lisäystä hyppäämästä hiljaa olemassa olevan säännön edelle, mikä on yleisin syy siihen, että toimiva käytäntö lakkaa toimimasta irrallisen muutoksen jälkeen.

Vastaava sääntö, joka osoittaa puutteelliseen tauluun, on toinen ansa. Jos taulu 201 sisältää oletusreitin mutta ei reittiä kohteeseen, paketti pudotetaan tai lähetetään väärään paikkaan, ja sääntö näyttää yksinään täysin oikealta. Lue taulua, älä vain sääntöä. Sääntö on osoitin, ja tyhjä taulu on osoitin ei mihinkään.

Paluupolun on silti oltava olemassa

Lähdekäytäntö valitsee uloskäynnin. Se ei luo paluupolkua. Jos toinen pooli lähtee kumppanin tunnelin kautta, kumppanin on tiedettävä, miten se saavuttaa 172.31.8.0/24, joko reitillä takaisin yhdyskäytävälle tai vastaanottamalla käännettyjä osoitteita, jotka se jo tuntee.

Näiden välillä valitseminen on suunnittelupäätös, jolla on näkyvät seuraukset. Asiakasalueen reitittäminen takaisin säilyttää kunkin asiakkaan identiteetin kumppanilla ja vaatii sitä hyväksymään etuliitteesi. Käännös piilottaa poolin yhden osoitteen taakse ja vaatii kumppania hyväksymään vain tuon osoitteen, sen hinnalla, etteivät sinun ja hänen lokisi enää sovi yhteen siitä, kuka yhdisti.

Mitä ikinä valitset, kirjoita se poolin määritelmän viereen. Paluureitti, joka on olemassa vain jonkun muistissa, on juuri sellainen asia, joka kestää siihen asti, että kumppani vaihtaa palomuurin, ja vie sitten päivän sen uudelleenrakentamiseen.

Älä nappaa yhdyskäytävän omaa tunnelia käytäntöön

Säännöt, jotka kirjoitat asiakkaille, pätevät myös liikenteeseen, jonka yhdyskäytävä tuottaa, ellet sulje sitä pois. Laaja sääntö, joka perustuu merkintään tai lähtörajapintaan, voi napata yhdyskäytävän oman yhteyden kumppaniin, ja silloin käytäntöä kantava tunneli reititetään käytännön mukaan. Se tuottaa silmukan tai katkoksen, joka näyttää palveluntarjoajan vialta.

Rajaa jokainen sääntö niin kapeasti kuin suunnittelu sallii: lähde-etuliite, tulorajapinta ja tuen ollessa kyseessä merkintä, jota vain asiakaspaketit kantavat. Testaa sitten yhdyskäytävän oma yhteys jokaisen sääntömuutoksen jälkeen, koska vika on itseen viittaava eikä näy asiakastestissä.

ip-rule-komennon manuaalisivu dokumentoi valitsimen ja prioriteetin semantiikan. Yhdistä se poolikohtaiseen hakutestiin ja suunnittelusta tulee tarkistettava, mikä on ero vuoden kestävän käytäntöreitityksen ja sellaisen välillä, jota kaikki pelkäävät koskea.