Non kokatzen da VPN NAT UFWren before.rules fitxategian eta nola probatu

Shell batean idatzita funtzionatzen duen NAT arauak huts egiten du before.rules fitxategian itsatsita, fitxategi hori ez delako script bat. Berreskuratze-formatuko dokumentua da, taula-atalekin, kate-deklarazioekin eta taula bakoitzeko COMMIT markarekin. Leku okerrean dagoen lerro batek berreskuratze osoa eteten du edo han zeudela uste zenuen arauak isilean botatzen ditu. Beheko gidalerroak zatia markoak espero duen tokian jartzen du eta emaitza frogatzen du hurrengo berrikarga baino lehen.

Shell komando bat ez da berreskuratze-fitxategi bat

iptables -t nat hasten den lerroa iptables binariorako jarraibidea da, UFWk irakurtzen duen fitxategia arau-multzo oso baten deskribapena den bitartean. Aldea ez da kosmetikoa: berreskuratze-formatuak jakin behar du zein taulatan dagoen, zein kate dauden eta non amaitzen den taula. Dokumentu horretan itsatsitako komandoa sintaxi-akatsa da edo, okerrago, taula okerrean erantsitako araua. Markoak fitxategi horiek berreskuratze-tresnen bidez kargatzen ditu hain zuzen ere deklaratzaileak direlako, ez sekuentzialak.

Dokumentua osorik kargatzen da, beraz atal gaizki eratuta batek fitxategiaren gainerakoa aplikatzea eragotzi dezake. Horrela, NAT zatiko akats txiki batek iragazki-arauak ere berekin eramaten ditu, eta horrela bihurtzen da suebaki-aldaketa etenaldi.

Jarri zatia lehendik dagoen taula-atalean

NAT zatiak forma bat du, eta forma hori garrantzitsuagoa da barruan duen arauaren testua baino. Taula-goiburuak atala irekitzen du, kate-deklarazioek kontagailuak ezartzen dituzte, arauak jarraitzen dira eta COMMIT batek atala ixten du.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Goiko pool eta interfazea zure balioetarako leku-markak dira; egitura da kopiatzea merezi duen zatia. Fitxategiak dagoeneko *nat atala badu, gehitu araua atal horren barruan, bigarren bat ireki beharrean, formatuak taula bakoitzeko COMMIT bat espero baitu eta taula bererako bi atal konponketa bat baitira, gertatzear dena. Mantendu banaketaren kate-definizioak osorik, hornitzaileak bere integraziorako gehitutakoak barne. UFW markoaren eskuliburuak before, user eta after fitxategiak dokumentatzen ditu, dagokion COMMIT baten baldintzarekin batera.

Fitxategia hutsik badago, ez bete tutorial batekin. Berretsi zein paketek duen jabetza eta zein den benetako politika bizia, fitxategi iraunkor huts batek ez baitu frogatzen nukleoak araurik ez duenik, eta kargatutako arau-multzo batek ez baitu frogatzen hurrengo berrikargak irakurtzeko fitxategi osoa izango duenik. Lehenengo berreskuratu onartutako oinarri-lerroa, eta gero aplikatu berriro guneko aldaketak haren gainean.

Probatu hautagaia aplikatu gabe

Berreskuratze-tresnak arau-multzo bat analizatu eta eraiki dezake aplikatu gabe, eta hori da eskuragarri dagoen probarik merkeena. Exekutatu babestutako kopia baten aurka, ez fitxategi bizian, eta irakurri errorearen testua, ez soilik irteera-egoera. Analisi-hutsegiteak lerro bat eta normalean taula bat izendatzen ditu, eta hori gehiago da huts egindako berrikarga batek esango dizuna baino.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Egiaztapen hori igarotzeak frogatzen du dokumentua analizatzen dela, eta besterik ez. Ez du frogatzen hautagaiak oraindik UFWren mendeko kate guztiak dituenik, nahi zenituen iturburuak soilik uzten dituenik edo urrutiko administrazioa irisgarri jarraitzen duenik. Berrikuspen bereiziak dira, eta azkenak hasi aurretik irekitako bigarren saio bat merezi du.

Aukeratu instalatutako backend-ari eta helbide-familiari dagokion tresna. nft backend-a bateragarritasun-geruzaren bidez exekutatzen duen ostalariak dagokion komandoa behar du, eta IPv6 arauak erabat beste fitxategi batean bizi dira.

Eduki bereizita birbidaltzea, NATa eta sarbide-politika

Iturriaren itzulpenak helbideratze-arazo bat konpontzen du eta ez du ezer ematen. Birbidaltzea sysctl batek eta iragazki-taulak kontrolatzen duten baimen bereizia da, eta hori da jendeak ahazten duena tunelak bideratzen duenean baina trafikorik pasatzen ez duenean. Sarbide-politika hirugarren erabakia da, zein iturburuk zein zerbitzutara irits daitezkeen, eta NAT arau batek ere ez du adierazten. Hirurak bereiz edukitzeak egiten du hutsegitea diagnostikagarri, sintoma lauso bakar baten ordez.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Irakurri hiru irteera horiek elkarrekin, ez banan-banan. Birbidaltzea desgaituta duen masquerade arau batek konektatzen den baina inora iristen ez den bezero bat sortzen du, eta bezeroaren aldetik bideratze-hutsegite baten itxura zehatza du eta jendea fitxategi okerrean bidaltzen du. Iragazki-taula da, gainera, accept gehiegi zabal bat ezkutatzen den tokia, beraz, han zauden bitartean, egiaztatu haren politika lehenetsia.

Egiaztatu berrikarga bat, ukapen bat eta VPN galera bat

Hiru behaketak onarpen-proba osoa osatzen dute: berrikargak arrakasta du, baimendutako bezero-eragiketa batek funtzionatzen du, eta ukatu behar litzatekeen eskaera bat benetan ukatzen da. Hirugarrena da saltatzen dena, eta politikak ezer egiten duen froga bakarra da.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Ondoren, diseinatu zenuen hutsegitea probatu. Utzi tunela erortzen eta begiratu zer egiten duen ostalariak, VPN-a martxan dagoen bitartean soilik funtzionatzen duen politika bat adierazi gabeko mendekotasuna duen politika baita. Berrikargatu berriro geroago frogatzeko fitxategiak, eta ez geratzen den exekuzio-egoera batek, ematen duela emaitza funtzionala.

IPv4ren NATak ez du ezer esaten IPv6ri buruz, beraz, adierazi bi familientzako estaldura aurreikusia arauarekin batera ohar berean. Helburua politika kudeatu koherentea da, eta kasualitatez analizatu zen zati bat ez da horren froga.