Un solo host pubblico per VPN e web: come dividere i ruoli

Una sola macchina può soddisfare tutte e tre le esigenze insieme: terminare tunnel, rispondere in HTTPS e inoltrare tra due LAN private. Se questo sia sensato dipende da tre cose che potete decidere sulla carta: chi possiede l’indirizzo pubblico, chi possiede ogni coppia di porta e protocollo e quale processo è autorizzato a inoltrare pacchetti. Se sono giuste, l’host condiviso non ha nulla di speciale. Se sono sbagliate, passerete un fine settimana su un servizio che parte pulito e non risponde mai.

Quello che segue è una procedura di decisione, non un foglio di costruzione. Ogni passo termina con la verifica che dimostra che il ruolo appena aggiunto è davvero isolato.

Scegliete il proprietario dell’indirizzo prima delle porte

Un endpoint di tunnel e un server web possono condividere un kernel; condividere un indirizzo, una porta e un protocollo nello stesso momento è ciò che fallisce. WireGuard di solito prende UDP 51820, OpenVPN prende UDP 1194 o TCP 443, e un server web prende TCP 443. La coppia che fa male è OpenVPN su TCP 443 accanto a HTTPS, perché entrambi vogliono lo stesso socket e il kernel lo dà a chi si è legato per primo. Solo un demultiplexer davanti, come sslh o un proxy consapevole di TLS, permette loro di condividere quella porta, e aggiunge un componente il cui guasto sembra esattamente un problema di firewall.

Guardate i proprietari prima di cambiare qualcosa: ss -lntup stampa l’indirizzo locale, la porta e il processo di ogni socket in ascolto. Due righe che mostrano 0.0.0.0:443 significano che il secondo servizio non si è mai legato, per quanto allegro fosse il suo script init. Il bridging sposta anche il proprietario. Quando eth0 si unisce a br0, l’IP passa a br0 e ogni regola del firewall che nomina eth0 smette di corrispondere, quindi legate i servizi sul bridge e confermate con ip -br addr.

La stessa regola di proprietà spiega una sorpresa che compare con le macchine virtuali. Un server di tunnel che gira dentro un ospite sulla stessa LAN mantiene l’indirizzo dell’ospite, quindi le connessioni dirette all’indirizzo dell’host restano sull’host e il tunnel dell’ospite non le vede mai, qualunque cosa dica il profilo del client.

Instradate tra le due LAN o fate NAT su un lato

Due LAN che non si vedono possono ciascuna chiamare l’host pubblico, che poi inoltra tra i tunnel. Quel progetto instradato richiede tre cose: inoltro attivo, una rotta verso ogni prefisso remoto e una politica di inoltro che lascia passare il transito. sysctl -w net.ipv4.ip_forward=1 copre la prima, ip route add 10.20.0.0/24 dev wg1 la seconda, e una riga nftables come nft add rule inet filter forward iifname "wg0" oifname "wg1" accept la terza.

Il NAT di origine è più facile da aggiungere e più difficile da debuggare. Il masquerading riscrive l’indirizzo del client, quindi il lato remoto vede l’hub invece dell’host reale, e le sue regole di accesso e i log smettono di essere utili per l’attribuzione. Quando entrambe le reti sono vostre, instradate. Quando un lato appartiene a una terza parte che non aggiungerà una rotta di ritorno, il NAT è l’opzione che parte questa settimana. In ogni caso, scrivete il piano degli indirizzi, perché due /24 sovrapposte non possono essere instradate da nessuna configurazione.

Niente nel fatto che la macchina faccia da uscita Internet per un portatile impedisce alla stessa macchina di terminare tunnel in entrata. Lo impediscono solo gli indirizzi sovrapposti, ed è per questo che il piano degli indirizzi è il documento che conta.

Provate la separazione con due ruoli fermi

Il test utile è una sottrazione: fermate due ruoli e confermate che il terzo risponde ancora. Una richiesta web deve completarsi con il servizio tunnel spento, e una stretta di mano del tunnel deve completarsi con il server web fermo. Se entrambi funzionano solo quando tutto gira, avete una dipendenza accidentale, come una tabella del firewall condivisa, una rotta vagante o un nome che punta all’indirizzo sbagliato.

Tre comandi rendono concreto quel test. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dimostra che l’ascoltatore locale risponde senza DNS esterno, wg show sul client dimostra che la stretta di mano è completata, e tcpdump -ni any port 51820 sull’hub separa un problema di instradamento da un problema di chiave. Una stretta di mano che non compare mai nella cattura è morta prima dell’host: firewall del provider, indirizzo pubblico sbagliato o una regola NAT lungo il percorso.

Ripetete la sottrazione per le LAN inoltrate. Con un peer disconnesso, un ping attraverso l’hub deve fallire; riconnesso, il ping deve tornare senza toccare una regola. Un ping che torna solo dopo aver riavviato il tunnel punta alla politica e non alla raggiungibilità, che è una correzione diversa.

Mantenete leggibile l’insieme di regole mentre sottraete ruoli. nft list ruleset dovrebbe mostrare una regola di accettazione per ogni direzione che vi serve davvero, e una catena di inoltro che accetta tutto non è separazione, è una demo funzionante.

Linee di accesso solo IPv6 e servizi IPv4

Alcune linee di accesso danno solo raggiungibilità IPv6, e i servizi vanno comunque pubblicati su IPv4. Il tunnel stesso viaggia sulla famiglia che ancora fa passare traffico, mentre il servizio pubblicato sta su un indirizzo dentro il tunnel. Questo inverte l’ipotesi abituale e rompe silenziosamente il monitoraggio: una regola del firewall o un controllo di uptime scritto per il percorso IPv4 ora sorveglia un’interfaccia che non porta nulla.

Provate ogni famiglia separatamente con curl -4 e curl -6, perché una richiesta riuscita non dice nulla sul percorso che non avete provato. La proprietà delle porte non cambia tra famiglie, ma l’ascoltatore sì: ss -lntup elenca i socket IPv4 e IPv6 su righe separate, e 0.0.0.0:443 non copre [::]:443 a meno che il processo non abbia chiesto un socket dual-stack.

Un servizio che risponde su una famiglia e rifiuta sull’altra è di solito un problema di ascoltatore, non di instradamento. Prima di dichiarare finito il progetto, confermate che ogni ruolo possieda il proprio indirizzo o la propria porta, che l’inoltro sia attivo e consentito, e che ogni ruolo risponda ancora con gli altri due fermi.