ufw allow 443 ei teinud VPN-i taga olevale teenusele midagi

Ping õnnestub VPN-kliendilt, TCP-teenus aegub ja ufw allow 443/tcp ei muuda üldse midagi. Kui rakendus töötab lüüsi taga oleval hostil, mitte lüüsil endal, kirjutati see luba vale liiklustee jaoks. Pakett ei ole tulemüürile adresseeritud ja seda ei toimetata kohalikule protsessile, seega sisendreeglid ei näe seda kunagi. Parandus on edastatavale voolule suunatud marsruudireegel ja selle tõend on juba logis.

Otsustage, kas sihtkoht on kohalik või edastatav

Lugege paketti nii, nagu kernel seda näeb. Lüüsile teenusele toimetatud liiklus on kohalik sisend. Liiklus, mille lüüs suunab edasi teisele hostile, on edastatav ja UFW hoiab kahe tee jaoks eraldi reeglistikke. Erinevuse otsustab sihtkoha aadress ja marsruudiotsing, mitte liides, millelt pakett saabus.

Logirida, mis näitab sama liidest nii IN kui ka OUT väljal, võib ikkagi kirjeldada marsruuditud paketti, sest ühest seadmest kliente sisse ja välja viiv tunnel näeb täpselt selline välja. Sihtkoha aadress lahendab küsimuse kiiremini kui liideste nimed. Sama nime kaks korda nägemine ei tõesta kohalikku toimetamist ja juurutuse poolt kunagi loomata tunneliliidese väljamõtlemine ei aita samuti.

Lugege blokeeringut enne mis tahes reegli lisamist

Korrake ühte volitatud ühenduse katset ja registreerige selle allikas, sihtkoht, protokoll ja sihtport nii, nagu lüüs need salvestas. Võrrelge neid nelja väärtust logikirjega ja teenuse tegeliku asukohaga. Varajasem edukas ping tõestab ainult seda, et selle enda vahetus oli lubatud, ja tulemüür võib rakendusele suunatud TCP SYN-i käsitleda hoopis teisiti.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Esimene käsk tagastab otsuse koos oma väljadega ja teine näitab, mis on juba laaditud ja millises järjekorras. Lugege mõlemat enne millegi muutmist, sest varasem keeld teie reegli kohal selgitab sama sümptomit ka ilma ühegi puuduva reegliga.

Kirjutage kitsaim sobiv marsruudireegel

Selles näites saabuvad kliendid tun0 kaudu aadressilt 172.20.8.0/24, teenus kuulab aadressil 10.30.0.15 porti 8443 ja lüüs väljub ens5 kaudu. Need väärtused valiti nii, et need ei sarnaneks üldse pilve VPC vaikeväärtusega 10.0.0.0/16 ega koduvõrgu aadressiga 192.168.0.0/16, ja 8443 hoiab näite lüüsi enda 443-kuulajast eemal.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Proovijooks trükib reeglistiku, mis tekiks, ja see on odavaim viis näha, kas teie reegel satub olemasoleva keelu ette või järele. Kontrollige liideste nimesid ja sisemisi aadresse juurutuse, mitte näite järgi, ja pidage meeles, et kui sihtkoha NAT töötab esimesena, näeb filter tõlgitud sihtkohta.

Hoidke tagasitee olekupõhine

UFW jälgib lubatud ühendusi, seega lubatud edastatava voolu vastused võetakse vastu ilma selgesõnalise vastupidise reeglita. Piiramatu reegli lisamine vastassuunas, et asjad töötaksid, laiendab poliitikat kaugele üle ühe teenuse ja pole tavalise päringu-vastuse vahetuse jaoks vajalik. Hoidke tagasitee kaudne ja reeglistik loetav.

Rakendage reeglit alles siis, kui proovijooks vastab teie kavatsusele, seejärel kinnitage, et järjestatud loend näitab seda oodatud kohas. Hoidke VPN-kuulaja ja haldusreeglid eraldi küsimustena, sest nende muutmine on teistsugune otsus kui ühe rakenduse lubamine. Märkige muudatus samasse kohta, kuhu topoloogia on kirja pandud, et järgmine insener ei peaks seda paketipüünisest uuesti avastama.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Kontrollige, mida UFW teie eest jõustada ei saa

Korrektne reegel vajab siiski kerneli edastamist ja teenuseni jõudvat marsruuti. Kinnitage mõlemad enne, kui süüdistate tulemüüri teist korda.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Seejärel vaadake hostist väljapoole. Pilveinstantsil ei asenda külalise UFW-poliitika turbegruppe, alamvõrgu ACL-e ega teenusepakkuja enda edastamisseadistust, seega kohalik blokk on tõend ühe kihi kohta, mitte tõend, et kõik teised kihid teenust lubavad.

Lõpetage uue ühenduse testimisega tulemüüri sisselülitatud olekus, lubatud allikast ja mitteseotud allikast. UFW väljalülitamine eemaldab sümptomi ja hävitab tõendi sama käsuga, mistõttu peaks see olema viimane katse, mitte esimene.