Miks teie avalik Linuxi teenus vastab hoopis VPN-i kaudu

Sokis ei mäleta miski, milline liides päringu kohale toimetas, seega võib täistunneliga VPN-i vaikemarsruut tabada vastuse, mis kuulub WAN-i. Teenus ei eira sissetulevat liidest; Linux marsruudib kohapeal loodud vastuse sihtkoha ja allikapõhimõtte järgi. Allikapõhine reegel saab hoopis saata ainult teenuse vastused täieliku WAN-tabeli kaudu, jättes tavapärase väljundi tunnelisse. Port jääb avatuks, samal ajal kui vastus lahkub vale tee kaudu, ja seetõttu näib sümptom ühepoolne.

Väärarusaam: vastused järgivad liidest, mille kaudu need saabusid

Tundub loogiline, et eth0-l saabuv pakett peaks lahkuma eth0-lt. Olekuta paketifiltreid saab nii kirjutada ja tcpdump sissetuleval poolel näitab päringut täpselt seal, kus seda oodatakse. Marsruutimine ei toimi nii liikluse puhul, mille host ise loob.

Kui teenus ühenduse vastu võtab, on selle vastus uus kohapeal loodud pakett. Kernel kontrollib marsruudireegleid vastuse sihtkoha ja allika jaoks ning VPN-i vaikemarsruut on täiesti kehtiv vastus. Sokis ei mäleta miski, milline liides päringu kohale toimetas.

Seetõttu näib sümptom ühepoolne: päringud saabuvad, vastused kaovad. Seetõttu ei muuda ka sissetuleva pordi jaoks tulemüürireegli lisamine midagi. Paketti ei blokeerita sissepoole minnes; see marsruuditakse väljapoole minnes mujale. Jälgige vastust allikapõhise otsinguga ja kõrvaltee muutub nähtavaks.

Mida kernel tegelikult marsruudib: allikaaadress

Käepide, mida vajate, on kohalik aadress, mida teenus vastuste jaoks kasutab. Hostil, mille näidis-eth0 aadress on 192.0.2.10/24 ja lüüs 192.0.2.1, on see aadress liidesel olemas. Pilve-VM-is võib avalik aadress olla ülalvoolu tõlgitud ja külalisest puududa, seega kasutage aadressi, mis hostil tegelikult on.

Kontrollige praegust olekut enne tabelinumbri või reegli prioriteedi reserveerimist. Olemasolevad poliitikareeglid võivad uue varjutada ja sama numbriga vana tabel võib juba kanda mitteseotud marsruute:

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

Seejärel valige tabel allika järgi. Reegel sobib vastustega, mis juba kannavad 192.0.2.10, täpselt see kohapeal lõpetatud liiklus, mille soovite välja jätta. Edasisaadetud liiklus ja teistelt kohalikelt aadressidelt tulevad paketid ei sobi.

Ehitage täielik tagasitabel, mitte pool vaikemarsruuti

Ainult vaikemarsruudiga tabelist ei piisa. Kernel peab ikkagi lüüsi lahendama ja see lahendus vajab ühendatud prefiksit samas tabelis. Tabel, millel see prefiks puudub, ebaõnnestub lüüsi lahendamisel isegi siis, kui selle vaikemarsruut näib korrektne. Lisage mõlemad ja suunake seejärel allikareegel tabelile:

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

Kasutage tegelikku prefiksit ja lüüsi, mitte ärge kopeerige näidet. Pilveliides, mis on konfigureeritud /32-na koos lingil oleva lüüsiga, vajab teistsugust ühendatud marsruuti ja vale prefiksi põhjal ehitatud tabel ebaõnnestub esimesel hüppel. Atribuut src näitab selle marsruudi eelistatud allikat; see ei asenda allikareeglit.

Ka järjekord on oluline. Laiem reegel madalama prioriteedinumbri korral hinnatakse esimesena, seega tuleb allikareeglini jõuda enne mis tahes reeglit, mis saadaks selle liikluse peamisesse tabelisse tagasi. Kontrollige prioriteete ip rule show abil pärast lisamist, mitte ainult käivitamisel.

Kontrollige allikapõhise otsinguga

Paluge kernelil marsruudida testisihtkoht teenuse aadressilt. Vastus peaks nimetama eth0 ja WAN-i lüüsi, mitte tunnelit:

ip -4 route get 198.51.100.25 from 192.0.2.10

Seejärel looge uus volitatud ühendus ja jälgige mõlemat suunda. Otsing, mis valib õige tabeli, samal ajal kui reaalne ühendus ikka ebaõnnestub, viitab pöördtee filtreerimisele või tulemüürireeglile, mitte tabelile. Kontrollige neid juhtelemente enne, kui midagi globaalselt välja lülitate.

Pange lõplikud marsruudid ja reegel liidest omava võrguhalduri alla. Aadressimuudatused, DHCP uuendamine ja VPN-i taasühendused kirjutavad kogu kerneli oleku üle ning käsitsi lisatud reegel kaob või osutab järgmise sündmuse järel aegunud lüüsile.

Kus see erand lõpeb

Reegel vabastab kohapeal lõpetatud liikluse ühelt allikaaadressilt. See ei kata Dockeri avaldatud porte, DNAT-i ega hosti kaudu edasisaadetud teenuseid, sest need paketid marsruuditakse edasisaadetud liiklusena ega kanna kunagi hosti kohalikku allikat samamoodi. Sellised lahendused vajavad tavaliselt sissesõidul seatud märgist ja reeglit, mis märgisega sobib.

See ei too ka hosti avalikku aadressi liidesele nähtavale. Kui ülalvoolu NAT omab seda aadressi, peab vastus ikkagi lahkuma teed, mida see NAT ootab, mistõttu peab WAN-tabel peegeldama algset lüüsi ja prefiksit, mitte oletatud avalikku vahemikku.

Hoidke erand dokumenteerituna koos tabelinumbri, reegli prioriteedi ja täpse allikaaadressiga. Järgmine muudatus VPN-is või liideses võib selle vaikselt katki teha ning kolme väärtust nimetav märkus on kiirem kontrollida kui sümptomi kliendiaruandest uuesti avastada.

Kui teenus vastab pärast allikapõhise otsingu õnnestumist ikka vale tee kaudu, võrrelge reaalse soki allikaaadressi reeglis olevaga. Metamärgiga aadressile seotud teenus võib valida teistsuguse allika kui teie testitud aadress ja see lahknevus on allesjäänud lünk.