Publiqueu un servei LAN a l’adreça pròpia de la passarel·la VPN

Presentar un dispositiu LAN en una de les adreces de túnel pròpies de la passarel·la només requereix una línia de NAT. La connexió encara falla, perquè el dispositiu que respon no té ni idea que l’adreça del client és abastable a través d’aquesta passarel·la. Seguiu el paquet des del client cap endins i després seguiu la resposta cap enfora, i la meitat que falta es fa evident.

Comenceu per la visió del client

El client d’aquest exemple és a la piscina VPN 10.62.0.0/24 i es connecta a 10.62.0.1 al port 8080. Aquesta adreça pertany a la mateixa passarel·la, així que el paquet arriba al nucli de la passarel·la i no a un altre parell. Darrere de la passarel·la, la LAN és 172.21.4.0/24. La passarel·la té 172.21.4.10 i el dispositiu que realment serveix HTTP és 172.21.4.40.

Una adreça que pertany a un altre parell de VPN no és intercanviable amb l’adreça de servei de la passarel·la. Si el client es connecta a l’adreça d’un parell, no hi intervé cap regla de la passarel·la i tot aquest recorregut és el cas equivocat.

Delimiteu la traducció de destinació a propòsit

La versió estreta presenta un port i reescriu només la destinació. El paquet conserva el protocol i l’origen, i això és el que fa interessant la resta del recorregut.

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

Una regla sense criteris de protocol i port és la versió àmplia: conserva el port que el client hagi triat i només canvia l’adreça. És legítima quan s’ha de presentar tot l’amfitrió i és incorrecta quan la intenció era un sol servei. Torneu a llegir la regla i confirmeu el nom de la interfície. Una regla DNAT a la interfície equivocada no coincideix amb res, cosa que produeix el mateix temps d’espera que una regla absent i fa perdre una hora mirant el dispositiu.

Feu que la frontera de reenviament estigui d’acord

La traducció canvia la capçalera, però no atorga permís. Amb una política de descart per defecte, el flux reenviat necessita la seva pròpia acceptació, i la direcció de tornada necessita la regla d’establiment que la vostra política probablement ja té.

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

Una acceptació incondicional per a cada flux DNAT és més àmplia que aquest disseny i també permetrà mapatges que algú altre afegeixi més endavant. Nomeu la destinació i el port, i deixeu la resta tancada. Si els comptadors de la regla de reenviament es queden a zero mentre els comptadors de NAT pugen, el paquet s’està descartant abans de la vostra regla. Llegiu l’ordre de la cadena en lloc d’afegir una segona còpia.

El dispositiu ha de respondre d’alguna manera

Després de la traducció, el dispositiu veu un origen dins de 10.62.0.0/24. La seva resposta va a la passarel·la per defecte, que és l’encaminador de la LAN, no la passarel·la VPN, tret que alguna cosa li digui el contrari. Dues disposicions ho arreglen i no són equivalents. Una ruta al dispositiu o a l’encaminador de la LAN envia 10.62.0.0/24 a 172.21.4.10 conservant l’origen del client. Una traducció d’origen limitada amaga el client darrere de l’adreça LAN de la passarel·la.

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

Trieu segons el que necessiti el servei. La política per client i uns registres significatius volen la forma encaminada; un dispositiu al qual no es pot donar una ruta, o un servei que simplement ha de veure una adreça LAN, assenyalen la forma traduïda. No recurreu a una regla masquerade global per fer funcionar una sola resposta. Amaga cada client de cada destinació i trenca silenciosament les polítiques que depenen de les adreces d’origen.

No proveu des de la mateixa passarel·la

Una petició generada a la passarel·la cap a 10.62.0.1 surt per la cadena OUTPUT, no per la PREROUTING d’entrada. El seu fracàs o èxit no diu res sobre la regla que mira al client, i així és com la gent conclou que una regla que funciona està trencada.

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

Executeu una petició real de client i llegiu les dues coses. L’entrada de conntrack mostra la traducció aplicada, i les captures mostren si la petició ha creuat cap a la LAN i si ha tornat una resposta cap al túnel. Feu servir una connexió nova després de canviar regles, perquè l’estat existent conserva el mapatge anterior i continuarà fallant a la manera antiga. Després confirmeu tota la conversa: l’adreça del dispositiu, el permís de reenviament i la ruta de resposta descriuen el mateix flux.