Pas një ndryshimi të IP-së së serverit, rregulli SNAT vazhdon të përmend atë të vjetër

Serveri u zhvendos në një adresë të re, klientët vazhdojnë të lidhen, dhe asgjë nga ajo që dërgojnë nuk arrin në internet. Pikërisht kjo ndarje është e dhëna: soketi dëgjues dhe përcjellja e portit i mbijetuan zhvendosjes, prandaj tuneli ngrihet, ndërsa përkthimi i burimit që zbatohet mbi paketat e përcjella vazhdon të përmend një adresë që hosti nuk e zotëron më. Përgjigjet për ato paketa të rishkruara shkojnë drejt një makine që nuk ekziston më.

Lidhja dhe përcjellja dështojnë në vende të ndryshme

Vendosja varet nga pika fundore që klientët tashmë e njohin: adresa publike, përcjellja e portit përpara saj dhe dëgjuesi brenda. Trafiku i përcjellë varet nga një vendim i dytë që merret pasi paketa hyn në tunel, kur hosti rishkruan burimin e vet që përgjigjet të gjejnë rrugën e kthimit.

Ndryshimi i adresës prish vetëm vendimin e dytë, dhe për këtë arsye simptoma lexohet si "i lidhur por pa internet". Kjo shpjegon gjithashtu pse kontrollet e zakonshme në anën e klientit duken të shëndetshme: shtrëngimi i duarve përfundon, klienti merr një adresë, dhe asnjë ping drejt adresës së tunelit të serverit mund të përgjigjet. Orë të tëra shpenzohen te klienti për një defekt që jeton në anën tjetër, prandaj tabela e rregullave është vendi i parë ku duhet parë.

Lexoni rregullin dhe numëruesit e tij përpara se të redaktoni

Listoni rregullat e përkthimit me numërues dhe krahasoni burimin e konfiguruar me adresat që hosti ka vërtet. Një rregull i rishkruar drejt një adrese të vdekur zakonisht tregon trafik në rrugën e hyrjes, sepse paketat arrijnë deri tek ai dhe përkthehen, dhe asgjë në rrugën e kthimit.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Kontrolloni tre fusha ndërsa jeni atje: grupin në përputhjen e burimit, ndërfaqen e daljes nëse rregulli përmend një, dhe përjashtimin që pengon rishkrimin e trafikut mes tuneleve. Ai përjashtim humbet lehtë gjatë redaktimit, dhe humbja e tij bën që trafiku mes palëve të duket se funksionon ndërsa përgjigjet e tij ndjekin një rrugë të çuditshme.

Nëse numëruesit qëndrojnë në zero, paketat nuk arrijnë kurrë në këtë rregull dhe adresa nuk është problemi i tanishëm. Kërkoni një rregull konkurrues më lart në zinxhir, gjë që ndodh kur dikush shton një zëvendësim në vend që të redaktojë origjinalin. Krahasoni numrat e rregullave me daljen që shënuat një minutë më parë. Rendi është pjesë e konfigurimit, jo një detaj kozmetik.

Zëvendësoni burimin, ose ndaloni së përmenduri një

Kur hosti ka një adresë të qëndrueshme, zëvendësoni rregullin në vend, në vend që të shtoni një tjetër. Zëvendësimi sipas numrit të rregullit ruan rendin nga i cili varet pjesa tjetër e zinxhirit.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Kur adresa caktohet në mënyrë dinamike, mos përmendni asnjë burim dhe lërini kernelit të zgjedhë atë aktuale nga ndërfaqja e daljes. Ai variant i mbijeton zhvendosjes tjetër pa redaktim, me çmimin e fshehjes së cilës adresë u përdor.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

Konfirmoni që përcjellja e IPv4 është ende e aktivizuar përmes konfigurimit të menaxhuar, pastaj bëni rregullin të përhershëm me mekanizmin e vetë shpërndarjes. Një ndryshim i bërë vetëm në kernelin që punon kthehet me rinisjen tjetër, zakonisht gjatë një dritareje mirëmbajtjeje që askush nuk e lidh me ndryshimin.

Dy mënyra për ta bërë zëvendësimin gabimisht

Përkthimi i grupit drejt adresës së tunelit të serverit në vend të adresës së tij LAN i dërgon përgjigjet drejt e prapa në tunel, ku rrugëzohen drejt një klienti që nuk i kërkoi kurrë. Lidhja ngec në një mënyrë që duket si lak rrugëzimi, sepse i tillë është.

Grumbullimi i një përkthimi të dytë mbi atë të vjetër është gabimi tjetër. Fiton rregulli i parë që përputhet, kështu që zëri i vjetruar vazhdon të trajtojë paketa derisa të fshihet, dhe numëruesit e rregullit të ri mbeten në zero ndërsa të gjithë fajësojnë zëvendësimin. Fshini dublikatin përpara se të shtoni çdo gjë të re. Pastaj lexoni listën edhe një herë dhe konfirmoni që saktësisht një përkthim përputhet me grupin.

Nëse tuneli mbart edhe IPv6, përsëritni të gjithë rishikimin në stivën tjetër. Rruga e paracaktuar IPv6 pa përkthim dhe pa parashtesë të rrugëzuar dështon po aq në heshtje, dhe është e lehtë ta harrosh sepse gjithçka sipër duket identike.

Shërbimet hyrëse kanë nevojë për përkthimin e kundërt

Një shërbim në një klient VPN që duhet të jetë i arritshëm nga jashtë ka nevojë për përkthim destinacioni, jo për përkthim burimi: porti publik rishkruhet drejt adresës së tunelit të klientit përpara se të hyjë. Rruga e përcjelljes pastaj ka nevojë për një rregull të shprehur që lejon atë trafik.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Asnjëherë mos e përktheni portin që mbart vetë tunelin, sepse ai rishkrim ndërpret lidhjen që e mban shërbimin të arritshëm. Mbajeni portin e tunelit plotësisht jashtë rregullave të destinacionit. Në fund verifikoni nga të dy skajet: numërues në rregullin e ri, një kapje e shkurtër në pajisjen e tunelit dhe një kërkesë drejt një adrese brenda tunelit përpara se të provoni atë publike.