Ping-ak arrakasta du VPN bezero batetik, TCP zerbitzuak denbora agortzen du, eta ufw allow 443/tcp-k ez du ezer aldatzen. Aplikazioa atebidearen atzeko ostalari batean exekutatzen denean eta ez atebidearen beraren gainean, baimen hori trafiko-bide okerrarentzat idatzi zen. Paketea ez dago suebakiari zuzenduta eta ez zaio prozesu lokal bati ematen, beraz sarrera-arauak ez dute sekula ikusten. Konponbidea birbidalitako fluxuari zuzendutako ibilbide-arau bat da, eta horren froga jada erregistroan dago.

Erabaki helmuga lokala ala birbidalia den

Irakurri paketea kernelak ikusten duen bezala. Atebidean zerbitzu bati ematen zaion trafikoa sarrera lokala da. Atebideak beste ostalari batera bideratzen duen trafikoa birbidalia da, eta UFW-k bi bideetarako arau-multzo bereiziak mantentzen ditu. Bereizketa helmuga-helbideak eta ibilbide-kontsultak erabakitzen dute, ez paketea iritsi zen interfazeak.

IN eta OUT eremuetan interfaze bera erakusten duen erregistro-lerro batek bideratutako pakete bat deskriba dezake oraindik, gailu batetik bezeroak sartu eta irteten dituen tunel bat hain zuzen horrela agertzen delako. Helmuga-helbideak interfaze-izenek baino azkarrago erabakitzen du galdera. Izen bera bi aldiz ikusteak ez du tokiko entrega frogatzen, eta inplementazioak inoiz sortu ez zuen tunel-interfaze bat asmatzeak ere ez du laguntzen.

Irakurri blokeoa edozein arau gehitu aurretik

Behin baimendutako konexio-saiakera bat erreproduzitu eta haren iturria, helmuga, protokoloa eta helmuga-portua grabatu, atebideak erregistratu zituen bezala. Konparatu lau balio horiek erregistroko sarrerarekin eta zerbitzuaren benetako kokapenarekin. Lehenagoko ping arrakastatsu batek bere trukea baimenduta zegoela baino ez du frogatzen, eta suebaki batek aplikazio batera doan TCP SYN guztiz bestela trata dezake.

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

Lehenengo komandoak epaia itzultzen du bere eremuekin, eta bigarrenak zer dagoen jada kargatuta eta zein ordutan erakusten du. Irakurri biak ezer editatu aurretik, zure arauaren gaineko ukapen goiztiar batek sintoma bera azaltzen baitu falta den araurik gabe.

Idatzi egokitzen den ibilbide-arau estuena

Adibide honetan bezeroak tun0-ra iristen dira 172.20.8.0/24-tik, zerbitzuak 10.30.0.15-n entzuten du 8443 portuan, eta atebideak ens5-tik ateratzen du. Balio horiek hodeiko VPC lehenetsi bat 10.0.0.0/16 edo etxeko 192.168.0.0/16 sare bat ez bezalakoak izateko aukeratu ziren, eta 8443-ak adibidea atebidearen beraren 443 entzulearengandik urrun mantentzen du.

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

Proba-exekuzioak sortuko litzatekeen arau-multzoa inprimatzen du, eta hori da zure araua lehendik dagoen ukapen baten aurretik edo ondoren geratzen den ikusteko modurik merkeena. Egiaztatu interfaze-izenak eta barne-helbideak inplementazioaren aurka eta ez adibidearen aurka, eta gogoratu helmugako NAT lehenengo exekutatzen denean iragazkiak itzulitako helmuga ikusten duela.

Mantendu itzulera-bidea egoeraz

UFW-k baimendutako konexioak jarraitzen ditu, beraz baimendutako fluxu birbidalitu baten erantzunak onartzen dira alderantzizko arau esplizitu bat gabe. Alderantzizko norabidean murrizketarik gabeko arau bat gehitzeak gauzak funtziona dezan politika zerbitzu bakarraren askoz harago zabaltzen du eta ez da beharrezkoa ohiko eskaera-erantzun truke baterako. Mantendu itzulera-bidea inplizitua eta arau-multzoa irakurgarria.

Aplikatu araua proba-exekuzioak zure asmoarekin bat egiten duenean soilik, eta gero egiaztatu zerrenda ordenatuak espero den tokian erakusten duela. Mantendu VPN entzulea eta kudeaketa-arauak gai bereizi gisa, haiek aldatzea aplikazio bat onartzea baino erabaki desberdina baita. Ohartarazi aldaketa topologia idatzita dagoen leku berean, hurrengo ingeniariak pakete-kaptura batetik berriro aurkitu behar ez dezan.

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

Egiaztatu UFW-k zuretzat betearazi ezin duena

Arau zuzen batek kernelaren birbidalketa eta zerbitzura iristen den ibilbide bat behar ditu oraindik. Egiaztatu biak suebakia bigarren aldiz erruduntzatu aurretik.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Gero begiratu ostalariaren kanpora. Hodeiko instantzia batean gonbidatuaren UFW politikak ez ditu segurtasun-taldeak, azpisareko ACLak edo hornitzailearen beraren birbidalketa-konfigurazioa ordezkatzen, beraz blokeo lokal bat geruza bati buruzko froga da, eta ez beste geruza guztiek zerbitzua onartzen duten froga.

Amaitu konexio berri bat suebakia gaituta dagoela probatuz, baimendutako iturri batetik eta erlazionatuta ez dagoen beste batetik. UFW desgaitzeak sintoma kentzen du eta froga suntsitzen du komando berean, eta horregatik azken esperimentua izan beharko luke, ez lehena.

Erlazionatutako artikuluak