Pianificare l’accesso privato IKEv2 a doppio stack con strongSwan

Un tunnel a doppio stack non è una decisione ma tre, e si possono rispondere in modo diverso. Su quale famiglia viaggia il tunnel esterno, quali famiglie riceve il client all’interno e su quali famiglie rispondono davvero i servizi protetti. Un progetto che le tratta come un’unica scelta o trasporta IPv6 che non è mai servito, oppure distribuisce indirizzi che nulla può instradare indietro. Separate le tre e il resto della configurazione diventa quasi meccanico.

Tre tipi di indirizzo, decisi separatamente

L’indirizzo esterno è come i due gateway si raggiungono, e può essere IPv4 mentre il traffico interno trasporta entrambe le famiglie. L’indirizzo virtuale interno è l’identità del client dentro il tunnel, e ogni famiglia ha bisogno del proprio pool. I prefissi protetti sono ciò che il client può raggiungere, e appartengono ai servizi e non al tunnel. Confondere il terzo con il secondo causa la maggior parte degli errori di pianificazione, perché entrambi sembrano intervalli privati.

Un trasporto esterno solo IPv4 con traffico interno a doppio stack è una disposizione normale e ben supportata.

Decidete ciascuna in modo esplicito e annotate le decisioni. Se il percorso esterno è solo IPv4, ditelo e smettete di preoccuparvi della raggiungibilità degli endpoint IPv6. Se una famiglia viene assegnata all’interno ma nulla vi risponde, o la togliete dal piano o rendete quei servizi davvero a doppio stack.

Assegnate un indirizzo virtuale in ogni famiglia

In una configurazione swanctl il client richiede indirizzi virtuali, e un carattere jolly in ogni famiglia chiede al risponditore di assegnarne uno di ciascuna. Il risponditore li preleva dai pool, e i pool sono oggetti separati dalle reti dietro il gateway. Teneteli separati anche nel piano, perché un pool che si sovrappone a un prefisso di servizio produce instradamento che sembra corretto fino al momento in cui il traffico atterra in un punto indesiderato.

Chiedete entrambe le famiglie quando vi servono entrambe, e una quando non vi serve, perché un indirizzo inutilizzato è superficie di politica senza beneficio. Una richiesta specifica è una richiesta e non una prenotazione, e il risponditore può restituire un valore diverso secondo la propria politica. Quel dettaglio conta ovunque un indirizzo sia codificato in una regola del firewall o in un controllo di monitoraggio. Fate riferimento ai pool per nome nella connessione e tenete le reti dei servizi fuori da essi.

vips = 0.0.0.0, ::

Generate il vostro prefisso locale univoco per il pool IPv6 invece di adottare un breve valore di esempio. L’esempio mostra la forma dell’impostazione, non un valore predefinito da ereditare.

Descrivete le destinazioni a parte dai pool

I selettori di traffico descrivono ciò che ciascun lato si aspetta di scambiare, quindi i selettori locali del gateway devono nominare prefissi di servizi protetti e non pool di client. I selettori remoti del client riflettono quell’intenzione. Quando i due elenchi descrivono oggetti diversi, il tunnel può salire e comunque non trasportare nulla di utile.

Gli stessi prefissi hanno bisogno di rotte di ritorno e di inoltro consentito dentro la rete del gateway, per ogni famiglia che abilitate.

Qui è dove un piano IPv6 privato smette di bastare. L’indirizzamento locale univoco compra raggiungibilità privata e non crea uscita IPv6 pubblica, quindi un progetto che presume che la famiglia senza numeri segua semplicemente le regole di mascheramento IPv4 deluderà i suoi utenti. Se l’accesso IPv6 pubblico fa parte del requisito, serve un piano instradato e un upstream che sia d’accordo. Altrimenti dite chiaramente che il lato IPv6 è solo privato, il che è un confine onesto e non una limitazione da nascondere.

Rendete intenzionali il DNS e i percorsi di ritorno

La risoluzione dei nomi non segue il trasporto. Un resolver può restituire record A e AAAA attraverso un tunnel solo IPv4, e il client proverà allora una famiglia che non avete mai pianificato. Decidete quali nomi di servizio devono portare risposte a doppio stack utilizzabili e rendete intenzionali entrambi i percorsi. Un nome che risolve verso una famiglia senza percorso funzionante produce uno stallo invece di un errore pulito, e gli stalli sono molto più difficili da diagnosticare.

Documentate separatamente la raggiungibilità dell’endpoint esterno, incluso se è in gioco una traversata NAT e quale famiglia usa.

Poi scrivete il piano in sei righe: endpoint esterno, pool IPv4, pool IPv6, prefisso di servizio IPv4, prefisso di servizio IPv6 e il router che possiede le risposte per ciascuno. Un piano di quella forma risponde alle domande che un operatore pone davvero alle tre di notte. Qualcosa di più corto lascia il doppio stack come secondo indirizzo avvitato a una politica solo IPv4, ed è così che di solito finisce per funzionare a metà.