Etter ei endra tenar-IP peikar SNAT-regelen framleis på den gamle

Tenaren flytta til ei ny adresse, klientane koplar framleis til, og ingenting av det dei sender når internettet. Den delinga er sporet: den lyttande sockelen og portvideresendinga overlevde flyttinga, så tunnelen kjem opp, medan kjeldeomsetjinga som blir brukt på vidaresende pakkar framleis peikar på ei adresse som verten ikkje lenger eig. Svar på desse omskrivne pakkane går til ein maskin som ikkje finst lenger.

Tilkopling og vidaresending feilar på ulike stader

Etableringa avheng av endepunktet klientane allereie kjenner: den offentlege adressa, portvideresendinga framfor henne og lyttaren inni. Den vidaresende trafikken avheng av eit anna vedtak som blir teke etter at pakken kjem inn i tunnelen, når verten skriv om kjelda si slik at svara finn vegen tilbake.

Ei adresseendring bryt berre det andre vedtaket, og difor blir symptomet lese som "tilkopla men utan internett". Det forklarer òg kvifor dei vanlege klientkontrollane ser sunne ut: handtrykket blir fullført, klienten får ei adresse, og jamvel ein ping til tunneladressa til tenaren kan svare. Timar blir brukte på klienten på ein feil som bur på den andre sida, og difor er regeltabellen det fyrste staden å sjå.

Les regelen og teljarane før du redigerer

List opp omsetjingsreglane med teljarar og samanlikn den konfigurerte kjelda med adressene verten faktisk har. Ein regel som er skriven om til ei død adresse viser vanlegvis trafikk på veg inn, fordi pakkane når han og blir omsette, og ingenting på veg tilbake.

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

Sjekk tre felt medan du er der: bassenget i kjeldekoplinga, utgangsgrensesnittet om regelen nemner eitt, og unntaket som hindrar trafikk mellom tunnelar i å bli skriven om. Det unntaket er lett å miste under ei redigering, og mistar du det, ser peer-trafikk ut til å verke medan svara tek ein merkeleg veg.

Står teljarane på null, når pakkane aldri denne regelen, og adressa er ikkje det aktuelle problemet. Sjå etter ein konkurrerande regel tidlegare i kjeda, noko som skjer når nokon legg til ei erstatning i staden for å redigere originalen. Samanlikn reglenumra med utskrifta du noterte for eit minutt sidan. Rekkjefølgje er ein del av konfigurasjonen, ikkje ein kosmetisk detalj.

Erstatt kjelda, eller slutt å nemne ei

Når verten har ei stabil adresse, erstatt regelen på staden i staden for å leggje til ein ny. Erstatning etter reglenummer held på rekkjefølgja resten av kjeda avheng av.

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

Når adressa blir tildelt dynamisk, nemn inga kjelde i det heile og lat kjernen velje den gjeldande frå utgangsgrensesnittet. Den varianten overlever neste flytting utan redigering, mot å skjule kva adresse som vart brukt.

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

Stadfest at IPv4-vidaresending framleis er aktivert via styrt konfigurasjon, og gjer deretter regelen varig med distribusjonen sitt eige mekanisme. Ei endring som berre er gjort i den køyrande kjernen, kjem tilbake ved neste omstart, vanlegvis i eit vedlikehaldsvindauge som ingen knyter til endringa.

To måtar å gjere erstatninga feil på

Å omsetje bassenget til tunneladressa til tenaren i staden for LAN-adressa sender svara rett tilbake i tunnelen, der dei blir ruta mot ein klient som aldri bad om dei. Sambandet stoppar på ein måte som ser ut som ei rutingsløyfe, fordi det er ei.

Å stable ei andre omsetjing oppå den gamle er den andre feilen. Den fyrste samsvarande regelen vinn, så den utdaterte oppføringa held fram med å handsame pakkar til ho blir sletta, og teljarane til den nye regelen blir ståande på null medan alle klandrar erstatninga. Slett duplikatet før du legg til noko nytt. Les deretter lista ein gong til og stadfest at nøyaktig éi omsetjing samsvarar med bassenget.

Om tunnelen òg ber IPv6, gjer heile gjennomgangen om att på den andre stakken. Ei IPv6-standardrute utan omsetjing og utan ruta prefiks feilar like stille, og det er lett å gløyme fordi alt over ser identisk ut.

Innkommande tenester treng den motsette omsetjinga

Ei teneste på ein VPN-klient som må vere tilgjengeleg utanfrå, treng destinasjonsomsetjing, ikkje kjeldeomsetjing: den offentlege porten blir skriven om til tunneladressa til klienten før han kjem inn. Vidaresendingsvegen treng då ein uttrykkeleg regel som tillèt den trafikken.

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

Omset aldri porten som ber sjølve tunnelen, for den omskrivinga bryt sambandet som held tenesta tilgjengeleg. Hald tunnelporten heilt utanfor destinasjonsreglane. Stadfest deretter frå begge endar: teljarar på den nye regelen, eit kort opptak på tunneleininga og éin førespurnad til ei adresse inne i tunnelen før du prøver den offentlege.