Publiseer ’n LAN-diens op die VPN-gateway se eie adres

Om ’n LAN-toestel by een van die gateway se eie tonneladresse te publiseer, neem een reël NAT. Die verbinding misluk steeds, want die toestel wat antwoord, het geen idee dat die kliënt se adres deur daardie gateway bereikbaar is nie. Stap die pakkie van die kliënt na binne, stap dan die antwoord terug na buite, en die ontbrekende helfte word duidelik.

Begin by die kliënt se oogpunt

Die kliënt in hierdie voorbeeld sit in die VPN-poel 10.62.0.0/24 en verbind na 10.62.0.1 op poort 8080. Daardie adres behoort aan die gateway self, so die pakkie kom by die gateway se kernel aan eerder as by ’n ander eweknie. Agter die gateway is die LAN 172.21.4.0/24. Die gateway hou 172.21.4.10, en die toestel wat werklik HTTP dien, is 172.21.4.40.

’n Adres wat aan ’n ander VPN-eweknie behoort, is nie met die gateway se diensadres verwisselbaar nie. As die kliënt na ’n eweknie se adres verbind, is geen gateway-reël hoegenaamd betrokke nie, en hierdie hele deurloop is die verkeerde een.

Baken die bestemmingstranslasie doelbewus af

Die smal weergawe publiseer een poort en herskryf net die bestemming. Die pakkie behou sy protokol en sy bron, en dit is wat die res van die deurloop interessant maak.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

’n Reël sonder protokol- en poortkriteria is die breë weergawe: dit behou watter poort die kliënt ook al gekies het, terwyl net die adres verander. Dit is regmatig wanneer die hele gasheer gepubliseer moet word, en verkeerd wanneer een diens die bedoeling was. Lees die reël terug en bevestig die koppelvlaknaam. ’n DNAT-reël op die verkeerde koppelvlak pas niks, wat dieselfde tydsverloop as ’n ontbrekende reël lewer en ’n uur se kyk na die toestel mors.

Laat die aanstuuringsgrens saamstem

Translasie verander die kop; dit verleen nie toestemming nie. Met ’n verstek-verwerpbeleid het die aangestuurde vloei sy eie toelating nodig, en die terugrigting het die gevestigde reël nodig wat jou beleid waarskynlik al het.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

’n Onvoorwaardelike toelating vir elke DNAT-vloei is breër as hierdie ontwerp en sal ook karterings toelaat wat later deur iemand anders bygevoeg word. Noem die bestemming en die poort, en laat die res gesluit bly. As die tellers op die aanstuuringsreël op nul bly terwyl die NAT-tellers styg, word die pakkie voor jou reël laat val. Lees die kettingorde eerder as om ’n tweede kopie by te voeg.

Die toestel moet iewers antwoord gee

Na translasie sien die toestel ’n bron in 10.62.0.0/24. Sy antwoord gaan na sy verstek-gateway, wat die LAN-roeteerder is, nie die VPN-gateway nie, tensy iets anders vir hom sê. Twee reëlings los dit op, en hulle is nie gelykwaardig nie. ’n Roete op die toestel of op die LAN-roeteerder stuur 10.62.0.0/24 na 172.21.4.10 en behou die kliënt as bron. ’n Beperkte brontranslasie versteek die kliënt eerder agter die gateway se LAN-adres.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Kies volgens wat die diens nodig het. Beleid per kliënt en betekenisvolle logboeke wil die gerouteerde vorm hê; ’n toestel wat nie ’n roete kan kry nie, of ’n diens wat eenvoudig ’n LAN-adres moet sien, wys na die vertaalde vorm. Moenie na ’n globale masquerade-reël gryp om een antwoord te laat werk nie. Dit versteek elke kliënt vir elke bestemming en breek stilweg die beleide wat van bronadresse afhanklik is.

Moenie van die gateway self af toets nie

’n Versoek wat op die gateway na 10.62.0.1 gegenereer word, verlaat deur die OUTPUT-ketting, nie deur die inkomende PREROUTING nie. Die mislukking of sukses daarvan sê niks oor die kliëntgerigte reël nie, en dit is hoe mense tot die gevolgtrekking kom dat ’n werkende reël stukkend is.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Hardloop ’n werklike kliëntversoek en lees albei. Die conntrack-inskrywing wys die translasie wat toegepas is, en die opnames wys of die versoek na die LAN oorgegaan het en of ’n antwoord terug na die tonnel gekom het. Gebruik ’n vars verbinding nadat jy reëls verander het, want bestaande toestand hou sy vroeëre kartering en sal op die ou manier bly faal. Bevestig dan die hele gesprek: die toesteladres, die aansturingstoestemming en die antwoordroete wat almal dieselfde vloei beskryf.