OpenVPN amb túnel complet: afegiu una sortida a internet al costat del servidor
Empenyar una ruta per defecte és només la meitat del servei de túnel complet. El servidor també necessita reenviament, una regla de reenviament acotada i un camí de tornada per al conjunt.
Un client s'autentica, rep una adreça del conjunt i arriba als serveis de l'amfitrió VPN, però cada destinació pública expira. Així es veu un túnel sense sortida, i així continua fins que es compleixen quatre coses separades. El client ha d'acceptar una ruta per defecte, el servidor ha de reenviar, el tallafoc ha de permetre el trànsit i les respostes necessiten un camí de tornada al conjunt. Les quatre fallades comparteixen un sol símptoma, així que canvieu un element per intent i anoteu el resultat.
Empenyeu la ruta per defecte i confirmeu què ha instal·lat el client
La línia del costat del servidor és curta i només afecta els clients que accepten opcions empenyudes. La forma def1 instal·la dues rutes mig per defecte en lloc d'esborrar la per defecte existent, cosa que manté la connexió actual viva mentre encara captura cada destinació.
push "redirect-gateway def1"
Després de reconnectar, llegiu la taula d'encaminament del client en lloc de confiar en el perfil. A Linux les dues entrades /1 apareixen al costat de la per defecte original, i Windows mostra la mateixa parella com 0.0.0.0/1 i 128.0.0.0/1. Un client que ignora les opcions empenyudes, o un de configurat per refusar-les, conserva la seva vella per defecte i mai envia trànsit d'internet al túnel. Resoleu aquesta qüestió abans de canviar res al servidor, perquè cap regla del costat del servidor no ho pot compensar.
El reenviament és un paràmetre del servidor, no del VPN
Llegiu el flag de reenviament abans de tocar l'encaminament. Un zero allà vol dir que el nucli rep el paquet del client i es nega a passar-lo, cosa que sembla exactament un bloqueig de tallafoc des de l'altre extrem. Definiu el valor a través del directori de configuració del sistema perquè sobrevisqui a un reinici.
sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system
A continuació, confirmeu que l'amfitrió mateix té una ruta funcional fins a la sortida d'internet. Una petició des de l'intèrpret del servidor demostra que el camí ascendent és utilitzable i no diu absolutament res sobre reenviar el paquet d'un client, així que tracteu-los com dos tests separats. Si el servidor no pot arribar a la destinació, cap quantitat de configuració de reenviament no ajudarà.
Permeteu el trànsit que voleu, i res més
Els paquets reenviats creuen el camí forward; el trànsit adreçat a l'amfitrió VPN mateix creua input. Són decisions diferents, i obrir el camí input no permet el trànsit per la màquina. Confondre'ls és la raó més habitual que un tallafoc sembli permetre-ho tot mentre els clients encara expiren.
Una política mínima accepta connexions noves del conjunt cap a la interfície de sortida i accepta respostes que pertanyen a fluxos establerts. Poseu-la a qualsevol propietari de conjunt de regles que faci servir la vostra distribució, en lloc d'afegir una regla duplicada a cada arrencada; les regles duplicades s'acumulen i els comptadors deixen de significar res.
sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Canviar cada cadena a acceptar fa passar el test i elimina la raó per la qual existeix el tallafoc. Mantingueu l'abast al conjunt i a la interfície de sortida, i deixeu en pau el reenviament no relacionat.
Doneu a les respostes un lloc on anar
Les adreces del conjunt són privades, així que un servidor públic no pot lliurar una resposta directament a elles. O l'amfitrió VPN tradueix l'adreça d'origen a la sortida, o un dispositiu més amunt té una ruta de tornada al conjunt.
sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE
Afegiu exactament una capa de traducció. Un segon NAT més amunt amaga el primer i fa que tots dos registres siguin gairebé inútils quan alguna cosa es trenca més endavant. Si un encaminador més amunt ja encamina el conjunt de tornada, afegir traducció a l'amfitrió és redundant, i el camí de tornada aleshores depèn de la configuració d'aquell encaminador i no de la vostra.
Les instàncies al núvol afegeixen una porta més, perquè algunes plataformes descarten paquets l'adreça d'origen dels quals no és la de la instància tret que es relaxi aquesta comprovació. Aquest paràmetre és fora del convidat i és fàcil d'oblidar quan una màquina de prova local funciona.
Demostreu-ho des del client, no des de l'intèrpret del servidor
Comenceu amb una petició IPv4 numèrica, després una consulta de nom, després l'aplicació. Un ping demostra reenviament i traducció;no demostra res sobre la resolució, perquè les opcions DNS només tenen efecte quan la integració del client les instal·la.
curl -4 -m 5 http://198.51.100.10/
dig +short example.com
Anoteu els canvis i el pas de desfer sobre la marxa, perquè la política de sortida es pugui revertir en una acció quan un test falli. Aquesta recepta només cobreix IPv4; feu l'inventari d'IPv6 per separat abans d'afirmar que el desplegament porta tot el trànsit.