Etter en endret server-IP peker SNAT-regelen fortsatt på den gamle

Serveren flyttet til en ny adresse, klientene kobler fortsatt til, og ingenting av det de sender når internettet. Den delingen er sporet: den lyttende sockelen og portvideresendingen overlevde flyttingen, så tunnelen kommer opp, mens kildeoversettelsen som brukes på videresendte pakker fortsatt peker på en adresse som verten ikke lenger eier. Svar på disse omskrevne pakkene går til en maskin som ikke finnes lenger.

Tilkobling og videresending feiler på forskjellige steder

Etableringen avhenger av endepunktet klientene allerede kjenner: den offentlige adressen, portvideresendingen foran den og lytteren inni. Den videresendte trafikken avhenger av en annen beslutning som tas etter at pakken kommer inn i tunnelen, når verten skriver om kilden sin slik at svarene finner veien tilbake.

En adresseendring bryter bare den andre beslutningen, og derfor leses symptomet som "tilkoblet men uten internett". Det forklarer også hvorfor de vanlige klientkontrollene ser sunne ut: håndtrykket fullføres, klienten får en adresse, og til og med en ping til serverens tunneladresse kan svare. Timer brukes på klienten på en feil som bor på den andre siden, og derfor er regeltabellen det første stedet å se.

Les regelen og tellerne før du redigerer

List opp oversettelsesreglene med tellere og sammenlign den konfigurerte kilden med adressene verten faktisk har. En regel som er skrevet om til en død adresse viser vanligvis trafikk på vei inn, fordi pakkene når den og oversettes, og ingenting på vei tilbake.

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

Sjekk tre felt mens du er der: bassenget i kildematchingen, utgangsgrensesnittet hvis regelen navngir ett, og unntaket som hindrer trafikk mellom tunneler i å bli skrevet om. Det unntaket er lett å miste under en redigering, og mister du det, ser peer-trafikk ut til å virke mens svarene tar en merkelig vei.

Hvis tellerne står på null, når pakkene aldri denne regelen, og adressen er ikke det aktuelle problemet. Se etter en konkurrerende regel tidligere i kjeden, noe som skjer når noen legger til en erstatning i stedet for å redigere originalen. Sammenlign reglenumrene med utskriften du noterte for et minutt siden. Rekkefølge er en del av konfigurasjonen, ikke en kosmetisk detalj.

Erstatt kilden, eller slutt å navngi en

Når verten har en stabil adresse, erstatt regelen på stedet i stedet for å legge til en ny. Erstatning etter reglenummer beholder rekkefølgen resten av kjeden avhenger 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 adressen tildeles dynamisk, navngi ingen kilde i det hele tatt og la kjernen velge den gjeldende fra utgangsgrensesnittet. Den varianten overlever neste flytting uten redigering, mot å skjule hvilken adresse som ble brukt.

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

Bekreft at IPv4-videresending fortsatt er aktivert via administrert konfigurasjon, og gjør deretter regelen varig med distribusjonens egen mekanisme. En endring som bare er gjort i den kjørende kjernen, kommer tilbake ved neste omstart, vanligvis i et vedlikehavnsvindu som ingen kobler til endringen.

To måter å gjøre erstatningen feil på

Å oversette bassenget til serverens tunneladresse i stedet for LAN-adressen sender svarene rett tilbake i tunnelen, der de rutes mot en klient som aldri ba om dem. Forbindelsen stopper på en måte som ser ut som en rutingsløyfe, fordi det er en.

Å stable en andre oversettelse oppå den gamle er den andre feilen. Den første samsvarende regelen vinner, så den utdaterte oppføringen fortsetter å håndtere pakker til den slettes, og tellerne til den nye regelen blir stående på null mens alle klandrer erstatningen. Slett duplikatet før du legger til noe nytt. Les deretter listen en gang til og bekreft at nøyaktig én oversettelse samsvarer med bassenget.

Hvis tunnelen også bærer IPv6, gjenta hele gjennomgangen på den andre stakken. En IPv6-standardrute uten oversettelse og uten rutet prefiks feiler like stille, og det er lett å glemme fordi alt over ser identisk ut.

Innkommende tjenester trenger den motsatte oversettelsen

En tjeneste på en VPN-klient som må være tilgjengelig utenfra, trenger destinasjonsoversettelse, ikke kildeoversettelse: den offentlige porten skrives om til klientens tunneladresse før den kommer inn. Videresendingsveien trenger da en uttrykkelig regel som tillater den trafikken.

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

Oversett aldri porten som bærer selve tunnelen, for den omskrivingen avbryter forbindelsen som holder tjenesten tilgjengelig. Hold tunnelporten helt utenfor destinasjonsreglene. Verifiser deretter fra begge ender: tellere på den nye regelen, en kort opptak på tunneleenheten og én forespørsel til en adresse inne i tunnelen før du prøver den offentlige.