Twee VPN-kliënte, twee publieke adresse: laat SNAT ooreenstem

Twee VPN-kliënte kan deur twee verskillende publieke IPv4-adresse uitgaan, en die reël wat dit doen is korter as wat die meeste mense verwag. Wat dit laat werk, is nie die iptables-sintaksis nie, maar die toestand van die pakkie wanneer dit die uitgangsketting bereik: die bronadres daar moet steeds die kliënte van mekaar kan onderskei. As 'n vroeëre masquerade albei reeds op een adres saamgevat het, kan geen reël per kliënt die onderskeid herstel nie. Beslis eers daardie vraag, skryf dan die vertaling.

Watter identiteit oorleef tot by die poort

Die reël pas by die pakkie se bronadres, nie by 'n VPN-gebruikersnaam nie en ook nie by die naam wat 'n kliënttoepassing wys nie. Alles wat die pakkie vroeër op die pad vertaal, bepaal wat jou reël nog kan sien. Voer die nat-tabel in volgorde uit en vind die punt waar die bron nog per kliënt is.

iptables -t nat -S POSTROUTING

Lees daardie lys van bo af. 'n Masquerade-reël naby die bokant herskryf die bron vir elke passende stroom, en inskrywings per kliënt wat daarna geplaas word, pas by 'n adres wat nie meer bestaan nie. Wanneer twee LAN-toestelle een tonnel deel en as 'n enkele binne-adres aankom, moet die ontwerp verander voordat die firewall dit doen: hou hul bronreekse apart of gee elkeen sy eie binne-adres.

Koppel die toewysing van die binne-adres aan die geoutentifiseerde kliënt. Om daardie adres aan 'n ander toestel te gee, dra die uitgangsbeleid daarmee oor, en brontoewysing is op sigself nie 'n identiteitsbewys nie.

Vertaling kan nie 'n adres uitdink nie

Elke publieke adres moet aan hierdie uitgangspunt toegewys of daarheen gerouteer word, en die antwoorde moet hul weg daarheen terugvind. 'n Reël wat verkeer van 'n adres stuur waarheen niemand terugroeteer nie, word aan die ander kant laat val of aan 'n gasheer beantwoord wat nooit daarvoor gevra het nie. 'n Wolkverskaffer-instansie het gewoonlik sy publieke adres na 'n private koppelvlakadres vertaal voordat die pakkie vertrek, so die SNAT-bron moet die adres wees wat die verskaffer aanvaar, nie die waarde wat die konsole wys nie. Lees die verskaffer se adresmodel en volg dit eerder as om die publieke waarde in elke pakkie te kopieer.

In die praktyk beteken dit om die gerouteerde voorvoegsel in die verskaffer se konsole na te gaan voordat jy aan die firewall raak, en om die private koppelvlakadres as die vertaalbron te gebruik wanneer die kartering een-tot-een is. Die adresse wat in die voorbeelde hieronder gebruik word, kom uit die dokumentasie-reekse, so die eerste ding om te vervang is die adresteks self.

Voeg in voor die generiese masquerade

Bevestig die uitgangsinterface en die huidige ketting voordat jy enigiets byvoeg. Die eerste bepaal watter pakkies die reël kan pas, en die tweede wys wat reeds voor dit staan.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Die eerste opdrag noem die koppelvlak waardeur 'n pakkie na die internet werklik vertrek. Die tweede druk die ketting met lynnommers. Die generiese masquerade-inskrywing is die lyn om bo te bly.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Die twee reëls hierbo pas elkeen by een binne-adres, beperk die passing tot die uitgangsinterface en stel die bron eksplisiet. Voeg in eerder as om by te voeg: op posisie 1 word hulle voor die masquerade-lyn geëvalueer. Die volgorde tussen die twee maak nie saak nie, want hul bronne verskil. Vervang ens3 met wat die roete-opdrag ook al gerapporteer het, en hou ander firewall-bestuurders van dieselfde hake af, want twee gereedskap wat een tabel skryf is die gewone rede waarom 'n korrekte reël geen effek het nie.

Bewys die bron met 'n nuwe stroom

Toestandbeheerde NAT bind 'n vertaling wanneer 'n stroom begin en hergebruik dit vir latere pakkies, so 'n sessie wat voor die verandering oopgemaak is, behou sy ou bron ná die verandering. Slegs 'n nuut geïnisieerde verbinding bewys die reël.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Lees die antwoordrigting van daardie inskrywing: die bestemming daarvan is die adres wat die afgeleë eindpunt as die bron sien. Vergelyk dit met die publieke adres wat jy bedoel het, en beskou 'n inskrywing met die ou adres as bewys van 'n stroom wat te vroeg begin het, eerder as van 'n stukkende reël. Vra die kliënt om 'n nuwe verbinding oop te maak en herhaal dan die navraag. Om die hele volgtabel te spoel om die toets te forseer, onderbreek elke ander sessie op die poort.

Vertaal kies steeds nie die roete nie, laat nie die stroom deur die filter in nie en publiseer nie 'n inkomende diens nie. 'n Verkeerde roete en 'n ontbrekende toelaatreël hou aan misluk ná 'n perfekte SNAT-reël. Gaan IPv6 en enige sekondêre uitgangspad ook na, en teken dan die binne-na-publiek-pare in die firewall se dokumentasie aan sodat die volgende verandering by die kartering begin eerder as by die reëlteks.