NAT de la LAN a través de tun0 en una passarel·la VPN OpenBSD

Dos enginyers amb la mateixa passarel·la OpenBSD sovint us donaran dos conjunts de regles diferents per arribar a una xarxa remota, i tots dos es poden defensar. L'elecció entre traducció d'origen i una ruta de retorn no és en absolut una qüestió de sintaxi. Tot depèn del que el costat remot ja sap de 192.168.88.0/24 i del que necessiteu conservar als registres. Si ho feu malament, la línia nat-to semblarà perfectament correcta mentre les respostes desapareixen a la passarel·la per defecte remota.

L'encaminament i la reescriptura responen preguntes diferents

La taula d'encaminament decideix que 172.20.0.0/16 és abastable per tun0, i aquesta decisió es pren abans que es consulti cap traducció de pf. La traducció d'origen canvia llavors la capçalera del paquet perquè l'extrem remot vegi l'adreça de túnel de la passarel·la en lloc d'un amfitrió LAN. Cap mecanisme no substitueix l'altre: una regla nat no pot fer aparèixer una ruta, i una ruta no pot convèncer un encaminador remot que mai no ha sentit a parlar de la vostra subxarxa privada. Quan el costat remot no té camí de retorn, les respostes es descarten o s'envien a la seva passarel·la per defecte, i cap ajustament de regles no ho arregla.

Dit clarament, el reenviament respon on va el trànsit i la traducció respon de qui sembla que ve. Mantingueu-los en caixes mentals separades mentre dissenyeu el conjunt de regles.

Tres condicions que ho decideixen

Feu tres preguntes en ordre i el disseny normalment es tria sol. La xarxa remota té una ruta estàtica que apunta a l'adreça de túnel per a 192.168.88.0/24, o el seu administrador controla els encaminadors d'aquest camí? Si la resposta és sí, deixeu que les adreces LAN viatgin sense modificar i ometeu la traducció del tot. Necessiteu visibilitat per client al costat remot, ja sigui per a la política d'accés o per a un rastre d'auditoria? Si la resposta és sí, preservar l'origen val la pena la feina d'encaminament. L'adreça del túnel és prou estable per escriure-la en una ruta remota, o canvia entre reconnexions?

Si qualsevol resposta és no o desconeguda, nat-to és l'opció pragmàtica, i també és la reversible. Una regla de traducció s'elimina en una sola línia quan el costat remot afegeix una ruta adequada. Una ruta de retorn que mai no es va instal·lar us costa un fil de suport cada vegada que algú pregunta per què el túnel només funciona en una direcció.

Col·loqueu el fragment on pf realment l'avaluï

El fragment següent assumeix que la LAN és 192.168.88.0/24, la xarxa remota és 172.20.0.0/16 i la interfície de túnel és tun0. Res no hi tria un salt següent. Només reescriu l'origen als paquets que ja surten pel túnel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dos detalls d'aquella primera línia porten la major part del pes. Els parèntesis al voltant de tun0 diuen a pf que llegeixi l'adreça de la interfície cada vegada que construeix una entrada d'estat, cosa que importa quan el túnel es renumera després d'una reconnexió. La paraula match vol dir que la regla reescriu i després cau, de manera que una regla pass separada encara ha d'admetre el flux. La interfície nomenada a la línia match també ha de ser la que tria la taula d'encaminament, o pf avaluarà la regla en un camí de sortida diferent del que el paquet pren realment.

No us oblideu del costat del nucli. Cal habilitar el reenviament IPv4, i les regles pass amb estat per al túnel i la LAN han d'existir abans que res d'això tingui sentit. La secció PF NAT de les FAQ d'OpenBSD és la referència correcta per a l'ordre de paraules clau aquí.

Verifiqueu el conjunt de regles abans de confiar en el trànsit

Primer comproveu la sintaxi amb pfctl -nf /etc/pf.conf, que analitza el fitxer sense carregar-lo. Després carregueu la política i llegiu què té realment el nucli, perquè una regla que s'ha analitzat netament encara pot quedar ombrejada o enganxada a la interfície equivocada. pfctl -sn imprimeix les regles de traducció en la seva forma carregada, i pfctl -sr imprimeix les regles de filtre en ordre d'avaluació.

Després mireu el cable. A la passarel·la, tcpdump -ni tun0 'host 172.20.0.10' mostra si l'adreça d'origen que surt del túnel és l'adreça del túnel o l'amfitrió LAN. Un netstat -rn -f inet ràpid confirma a quina interfície es resol la destinació. Quan el trànsit flueixi, pfctl -ss llista les entrades d'estat; si un flux no ha produït cap estat, el paquet mai no ha coincidit amb una regla que en creï un.

Si el costat del túnel sembla correcte i les respostes encara no arriben mai, deixeu d'editar pf. La fallada restant és a l'encaminador remot, on la resposta s'envia cap a una adreça privada que aquell costat no pot assolir.

Quan la traducció costa més del que estalvia

La traducció amaga clients, i de vegades aquest és exactament el mal intercanvi. Les subxarxes solapades són un cas: si el costat remot també fa servir 192.168.88.0/24 internament, presentar els amfitrions LAN com a passarel·la empitjora la col·lisió en lloc de millorar-la. Les polítiques IPsec que seleccionen trànsit per parell d'adreces són un altre, perquè la base de dades de política de seguretat es compara abans de la traducció i mai no veu el paquet reescrit. Qualsevol desplegament que facturi, limiti o auditi per usuari també perd la identitat que necessita en el moment que l'origen col·lapsa en una sola adreça.

Els derivats portables de pf són una trampa a part. Els productes que generen els seus propis fitxers de regles esperen que NAT es configuri a través de la seva interfície, i els fragments editats a mà es sobreescriuen a la propera recàrrega. Els conjunts de regles copiats de guies escrites abans que existís la paraula clau match no es carregaran en un nucli actual, així que porteu la sintaxi i llegiu l'error en lloc d'endevinar.

La regla de decisió que sobreviu al contacte amb xarxes reals és curta: instal·leu una ruta de retorn quan pugueu, traduïu quan no pugueu, i anoteu quina de les tres condicions us va fer triar. Aquesta nota estalvia una tarda a la persona següent.