Po spremembi IP naslova strežnika pravilo SNAT še vedno navaja starega

Strežnik se je preselil na nov naslov, odjemalci se še vedno povezujejo, in nič od tega, kar pošljejo, ne doseže interneta. Prav ta razcep je namig: vtičnica, ki posluša, in posredovanje vrat sta preživela selitev, zato se tunel dvigne, medtem ko prevajanje izvora, ki se uporablja za posredovane pakete še vedno navaja naslov, ki ga gostitelj ne poseduje več. Odgovori na te prepisane pakete gredo k stroju, ki ga ni več.

Povezovanje in posredovanje odpovesta na različnih mestih

Vzpostavitev je odvisna od končne točke, ki jo odjemalci že poznajo: javnega naslova, posredovanja vrat pred njim in poslušalca znotraj. Posredovani promet je odvisen od druge odločitve, sprejete po tem, ko paket vstopi v tunel, ko gostitelj prepiše svoj izvor, da odgovori najdejo pot nazaj.

Sprememba naslova pokvari le drugo odločitev, zato se simptom bere kot "povezano, a brez interneta". To pojasni tudi, zakaj so običajni pregledi na strani odjemalca videti zdravi: rokovanje se zaključi, odjemalec prejme naslov, in tudi ping na tunelski naslov strežnika lahko odgovori. Ure se izgubljajo na odjemalcu zaradi napake, ki živi na drugi strani, zato je tabela pravil prvo mesto za pogled.

Preberite pravilo in njegove števce pred urejanjem

Naštejte pravila prevajanja s števci in primerjajte nastavljeni izvor z naslovi, ki jih gostitelj resnično ima. Pravilo, prepisano na mrtvi naslov, običajno kaže promet na vhodni poti, ker paketi do njega pridejo in se prevedejo, na povratni poti pa nič.

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

Preverite tri polja, dokler ste tam: nabor pri ujemanju izvora, izhodni vmesnik, če ga pravilo navaja, in izključitev, ki preprečuje prepisovanje prometa med tuneli. To izključitev je med urejanjem lahko izgubiti, izguba pa naredi, da promet med partnerji deluje, medtem ko njegovi odgovori ubirajo nenavadno pot.

Če števci obtičijo na ničli, paketi nikoli ne dosežejo tega pravila in naslov ni trenutna težava. Poiščite konkurenčno pravilo višje v verigi, kar se zgodi, ko nekdo doda zamenjavo, namesto da bi uredil izvirnik. Primerjajte številke pravil z izpisom, ki ste si ga zapisali pred minuto. Vrstni red je del konfiguracije, ne kozmetična podrobnost.

Zamenjajte izvor ali prenehajte navajati enega

Ko ima gostitelj stabilen naslov, zamenjajte pravilo na mestu, namesto da dodate še eno. Zamenjava po številki pravila ohrani vrstni red, od katerega je odvisna preostala veriga.

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

Ko se naslov dodeljuje dinamično, ne navajajte nobenega izvora in pustite jedru, da izbere trenutnega z izhodnega vmesnika. Ta različica preživi naslednjo selitev brez urejanja, za ceno tega, da skriva, kateri naslov je bil uporabljen.

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

Potrdite, da je posredovanje IPv4 še vedno omogočeno prek upravljane konfiguracije, nato pa pravilo naredite trajno z lastnim mehanizmom distribucije. Sprememba, narejena samo v delujočem jedru, se vrne ob naslednjem ponovnem zagonu, običajno med servisnim oknom, ki ga nihče ne poveže s spremembo.

Dva načina, kako zamenjavo narediti narobe

Prevajanje nabora na tunelski naslov strežnika namesto na njegov naslov LAN pošlje odgovore naravnost nazaj v tunel, kjer se usmerijo k odjemalcu, ki jih ni nikoli zahteval. Povezava se ustavi tako, da je videti kot zanka usmerjanja, ker to tudi je.

Nalaganje drugega prevajanja na starega je druga napaka. Zmaga prvo ujemajoče pravilo, zato zastarel vnos še naprej obdeluje pakete, dokler ni izbrisan, števci novega pravila pa ostanejo na ničli, medtem ko vsi krivijo zamenjavo. Izbrišite dvojnik, preden kar koli novega dodate. Nato seznam preberite še enkrat in potrdite, da se z naborom ujema natanko eno prevajanje.

Če tunel prenaša tudi IPv6, ponovite celoten pregled na drugem skladu. Privzeta pot IPv6 brez prevajanja in brez usmerjene predpone odpove prav tako tiho, in to je lahko pozabiti, ker je vse nad njo videti enako.

Vhodne storitve potrebujejo obratno prevajanje

Storitev na odjemalcu VPN, ki mora biti dosegljiva od zunaj, potrebuje prevajanje cilja, ne izvora: javna vrata se pred vstopom prepišejo na tunelski naslov odjemalca. Pot posredovanja nato potrebuje izrecno pravilo, ki dovoljuje ta promet.

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

Nikoli ne prevajajte vrat, ki prenašajo sam tunel, ker ta prepis prekine povezavo, ki ohranja storitev dosegljivo. Držite tunelska vrata popolnoma zunaj pravil cilja. Na koncu preverite z obeh strani: števci na novem pravilu, kratek posnetek na tunelski napravi in ena zahteva na naslov znotraj tunela, preden poskusite javnega.