VPN-marsruut või tulemüürireegel: milline paketi maha viskab?

Sama paketiga juhtub kaks sõltumatut otsust ja kumbki neist võib päringu vaikselt lõpetada. Marsruudiotsing valib liidese ja järgmise hüppe, seejärel otsustab paketifilter, kas see kombinatsioon on lubatud. Aegumine ütleb teile, et üks kahest keeldus, mitte kumb. Käige etapid järjekorras läbi ja parandus lakkab tavaliselt olemast oletus.

Kaks otsust, üks pakett, kaks omanikku

Marsruudiotsing konsulteerib esmalt poliitikareeglitega, seejärel tabeliga, millele need osutavad, ja valib kõige täpsema eesliite, mis sihtkohaga sobib. Klient, kes paigaldas tunnelimarsruudi, omab seda otsust ja miski tulemüürireeglis ei saa seda asendada. Kui otsing osutab ootamatule kohale, töötab iga järgmine etapp vale paketiga.

Filtreerimine on eraldi. Linuxi hostis jagavad netfilteri konksud liiklust selle järgi, kellele pakett on: väljund lahkub masinast, sisend lõpeb sellel, edastus läbib seda. Lüüs, mis võtab vastu VPN-kliendid ja marsruudib need LAN-i, vajab edastusteed ja see on täpselt see ahel, mille enamik vaikekonfiguratsioone tühjaks jätab.

Allika valik kuulub sama otsuse juurde ja just seal peitub enamik mittevastavusi. Kernel valib allikaaadressi väljuvalt liideselt, kui marsruut ei nimeta ühtegi, nii et LAN-i alamvõrgule kirjutatud filtrireegel ei sobi kunagi tunneliaadressiga väljuva paketiga.

Lugege, mille otsing tegelikult valis

Printige otsus, selle asemel et seda tuletada. Allolev käsk lahendab marsruudi, mida kernel selle sihtkoha jaoks kasutaks, sealhulgas liidese ja allika, mille see valiks:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-kliendid paigaldavad sageli poliitikareeglid prioriteetidele, mis on peamisest tabelist madalamad, nii et puhas peamine tabel ei tõesta iseenesest midagi. Võrrelge reeglite prioriteete tabelitega, mille need valivad, ja kontrollige, kas tunnelimarsruut jääb taasühendamise järel püsima, selle asemel et seda üks kord käsitsi lisada.

Poliitikal põhinev IPsec lisab kolmanda sobitamisetapi, mida marsruutimine ei kata, nagu strongSwani edastusmärkmed tunnel- ja transpordiseadistuste jaoks kirjeldavad. Turbepoliitika valib liiklust eesliite ja protokolli järgi, samas kui marsruut otsustab ainult, kuhu kaitsmata pakett läheks. Alamvõrk, mis on marsruuditud, kuid millel pole sobivat selektorit, jääb kas kaitsmata või visatakse konfiguratsioonist sõltuvalt maha ning kumbki tulemus ei näe välja nagu tulemüüriprobleem. Printige poliitika ja võrrelge selle selektoreid eesliidetega, mida eeldasite, et tunnel kannab.

Filtreerimine kehtib konksu juures, mitte marsruudil

Reegel, mis lubab VPN-kuulajat, on reegel lüüsile endale adresseeritud liikluse kohta. See ei ütle midagi klientide kohta, kes jõuavad hostideni selle lüüsi taga, sest edastatud liiklus läbib teist ahelat. Reeglistiku lugemine ühe tasase loendina on tavaline põhjus, miks õigesti näiv reegel kunagi ei rakendu.

Loendurid lahendavad küsimuse kiiresti. Nullilise paketiloenduriga reeglini ei jõutud kunagi, mis viitab valele ahelale, valele liidesele või varasemale mahaviskamisele. Kasvava loenduriga reegel mahaviskamise poliitika all on piir, mida otsisite, ja pakett visatakse kõrvale, mitte ei marsruudita valesti.

Saatke proov mööda teed, mida klient kasutab

Lüüsil endal tehtud testid läbivad väljundi ja sisendi, lüüsi enda allikaaadressiga. See on teistsugune tee kui kliendi edastatud päring, nii et edukas kohalik curl tõestab vähem, kui näib. Katsetage masinast, mis ebaõnnestub, või kinnitage liides ja allikas selgesõnaliselt.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Mõlemas otsas tehtud püük eristab ülejäänud juhtumeid. SYN, mis lahkub kliendist ega jõua kunagi kohale, tähendab marsruutimist, krüpteerimist või ülesvoolu juurdepääsuloendit. SYN, mis jõuab kohale ja ei saa vastust, tähendab teenust või selle hostifiltrit ning tunnel ei olnud kunagi probleem.

Tagasiliiklus väärib eraldi pilku. Asümmeetriline marsruutimine pluss pöördtee filtreerimine viskab maha vastused, mis saabuvad valele liidesele, mis ilmneb ühesuunalise ühendusena, mitte blokeeritud pordina. Kontrollige sysctli väärtust enne, kui süüdistate tulemüüri sümptomis, mida see ei põhjustanud.

Logimine töötab teise arvamusena, mitte esimese sammuna. Ajutine logilause edastusahelas nimetab liidese ja aadressid, mis seda tabasid, ja seda on hiljem lihtne eemaldada. Jätke see alaliselt alles ja olete loonud vastuse asemel logimahu probleemi.

Pange iga muudatus sinna, kus see jääb taasühendamise järel püsima

Käsuga ip route add lisatud marsruut elab seni, kuni liides alla läheb. Salvestage see hoopis ühenduse profiili: NetworkManager aktsepteerib ühendusel lisamarsruute ja netplan hoiab neid üle alglaadimiste. Sama reegel kehtib kliendipoolse tulemüürierandi kohta, mis kaob järgmise uuestilaadimise järel.

Serveripoolsed reeglid kuuluvad konfiguratsioonifaili, mille teenus käivitamisel laeb, mitte interaktiivsesse seanssi, mis lõpeb, kui selle sulgete. Kirjutage reegel, laadige uuesti ja kinnitage, et loendur liikus, sest süntaksi tagasi lükanud uuestilaadimine jätab vana reeglistiku vaikselt paigale.

Seejärel korrake algset rakendusepäringut otsast lõpuni ja kirjutage üles, milline kiht muutus. Marsruudiparandus, mis vajas ka filtrimuudatust, ebaõnnestub ikka ja teist ebaõnnestumist on palju kergem lugeda, kui teate, et esimene on kadunud. Märkige tulemuse kõrvale kuupäev ja kliendiversioon, sest marsruutimise ja filtreerimise vaikeväärtused liiguvad mõlemad väljalannete vahel. Hoidke see märge piletis, et järgmine inimene alustaks sealt, kus te lõpetasite, selle asemel et kahe etapiga teekonda korrata.