ufw allow 443 ničio nepadarė paslaugai už VPN
Įeinantis leidimas galioja ugniasienės mazgui, o ne už jos esančiai mašinai. Perskaitykite UFW bloką ir tada parašykite maršruto taisyklę peradresuojamai paslaugai.
Ping pavyksta iš VPN kliento, TCP paslauga baigia laiką, o ufw allow 443/tcp nieko nekeičia. Kai programa veikia mazge už tinklų sietuvo, o ne pačiame sietuve, tas leidimas buvo parašytas neteisingam srauto keliui. Paketas nėra adresuotas ugniasienei ir neperduodamas vietiniam procesui, todėl įėjimo taisyklės jo niekada nemato. Pataisa yra maršruto taisyklė, nukreipta į peradresuojamą srautą, ir jos įrodymas jau yra žurnale.
Nuspręskite, ar paskirties vieta yra vietinė, ar peradresuojama
Skaitykite paketą taip, kaip jį mato branduolys. Srautas, pristatomas paslaugai sietuvo mazge, yra vietinis įėjimas. Srautas, kurį sietuvas peradresuoja kitam mazgui, yra peradresuojamas, ir UFW laiko atskirus taisyklių rinkinius dviem keliams. Skirtumą lemia paskirties adresas ir maršruto paieška, o ne sąsaja, kuria atvyko paketas.
Žurnalo eilutė, rodanti tą pačią sąsają abiejuose IN ir OUT laukuose, vis tiek gali apibūdinti maršrutuotą paketą, nes tunelis, kuris klientus įleidžia ir išleidžia per vieną įrenginį, atrodo būtent taip. Paskirties adresas šį klausimą išsprendžia greičiau nei sąsajų pavadinimai. To paties pavadinimo matymas du kartus neįrodo vietinio pristatymo, o tunelio sąsajos, kurios diegimas niekada nesukūrė, išgalvojimas taip pat nepadeda.
Perskaitykite bloką prieš pridėdami bet kokią taisyklę
Atkurkite vieną leistą prisijungimo bandymą ir užfiksuokite jo šaltinį, paskirtį, protokolą bei paskirties prievadą taip, kaip juos užfiksavo sietuvas. Palyginkite šias keturias reikšmes su žurnalo įrašu ir su tikrąja paslaugos vieta. Ankstesnis sėkmingas ping įrodo tik tai, kad buvo leistas jo paties mainai, o ugniasienė gali TCP SYN į programą apdoroti visiškai kitaip.
sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered
Pirmoji komanda grąžina sprendimą su jo laukais, o antroji parodo, kas jau įkelta ir kokia tvarka. Perskaitykite abi prieš ką nors keisdami, nes ankstesnis draudimas virš jūsų taisyklės paaiškina tą patį simptomą be jokios trūkstamos taisyklės.
Parašykite siauriausią tinkamą maršruto taisyklę
Šiame pavyzdyje klientai atvyksta į tun0 iš 172.20.8.0/24, paslauga klausosi 10.30.0.15 prievade 8443, o sietuvas išeina per ens5. Tos reikšmės pasirinktos taip, kad visai neprimintų debesijos VPC standarto 10.0.0.0/16 ar namų tinklo 192.168.0.0/16, o 8443 laiko pavyzdį atokiai nuo paties sietuvo 443 klausytojo.
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
Bandomasis paleidimas atspausdina taisyklių rinkinį, kuris susidarytų, ir tai pigiausias būdas pamatyti, ar jūsų taisyklė atsidurs prieš esamą draudimą, ar po jo. Patikrinkite sąsajų pavadinimus ir vidinius adresus pagal diegimą, o ne pagal pavyzdį, ir atminkite, kad kai paskirties NAT veikia pirmas, filtras mato jau išverstą paskirtį.
Išlaikykite grįžimo kelią būseninį
UFW seka leistus ryšius, todėl atsakymai į leistą peradresuojamą srautą įleidžiami be aiškios atvirkštinės taisyklės. Neribota taisyklė priešinga kryptimi, kad viskas veiktų, išplečia politiką daug toliau nei viena paslauga ir nėra reikalinga įprastam užklausos ir atsakymo mainams. Išlaikykite grįžimo kelią numanomą, o taisyklių rinkinį skaitomą.
Taikykite taisyklę tik tada, kai bandomasis paleidimas atitinka jūsų ketinimą, tada patvirtinkite, kad surikiuotas sąrašas rodo ją laukiamoje vietoje. Laikykite VPN klausytoją ir valdymo taisykles atskirais klausimais, nes jų keitimas yra kitas sprendimas nei įleisti vieną programą. Užrašykite pakeitimą ten, kur užrašyta topologija, kad kitam inžinieriui nereikėtų jo vėl atrasti iš paketų įrašo.
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
Patikrinkite, ko UFW negali užtikrinti už jus
Teisingai taisyklei vis dar reikia branduolio peradresavimo ir maršruto, kuris pasiekia paslaugą. Patvirtinkite abu prieš antrą kartą kaltindami ugniasienę.
sysctl net.ipv4.ip_forward
ip route get 10.30.0.15
Tada pažiūrėkite už mazgo ribų. Debesijos instancijoje svečio UFW politika nepakeičia saugos grupių, potinklio ACL ar paties tiekėjo peradresavimo konfigūracijos, todėl vietinis blokavimas yra vieno sluoksnio įrodymas, o ne įrodymas, kad visi kiti sluoksniai leidžia paslaugą.
Užbaikite išbandydami naują ryšį su įjungta ugniasiene, iš leisto šaltinio ir iš nesusijusio. Išjungus UFW simptomas pašalinamas ir įrodymas sunaikinamas ta pačia komanda, todėl tai turėtų būti paskutinis eksperimentas, o ne pirmas.