Kaksipinoisen IKEv2-yksityiskäytön suunnittelu strongSwanilla

Kaksipinoinen tunneli ei ole yksi päätös vaan kolme, ja niihin voi vastata eri tavoin. Minkä perheen yli ulompi tunneli kulkee, mitkä perheet asiakas saa sisällä ja mille perheille suojatut palvelut todella vastaavat. Suunnittelu, joka kohtelee niitä yhtenä valintana, joko kuljettaa IPv6:ta, jota ei koskaan tarvittu, tai jakaa osoitteita, joita mikään ei voi reitittää takaisin. Erota kolme, ja muu kokoonpano muuttuu lähes mekaaniseksi.

Kolme osoitetyyppiä, päätetty erikseen

Ulompi osoite on se, miten kaksi yhdyskäytävää tavoittaa toisensa, ja se voi olla IPv4, kun sisempi liikenne kuljettaa molempia perheitä. Sisempi virtuaaliosoite on asiakkaan identiteetti tunnelin sisällä, ja jokainen perhe tarvitsee oman poolinsa. Suojatut etuliitteet ovat se, mihin asiakas saa päästä, ja ne kuuluvat palveluille eivätkä tunnelille. Kolmannen sekoittaminen toiseen aiheuttaa useimmat suunnitteluvirheet, koska molemmat näyttävät yksityisiltä alueilta.

Ulompi siirto vain IPv4:n yli ja sisempi kaksipinoinen liikenne on tavallinen ja hyvin tuettu järjestely.

Päätä jokainen nimenomaisesti ja kirjoita päätökset muistiin. Jos ulompi polku on vain IPv4, sano se ja lakkaa murehtimasta IPv6-päätepisteiden tavoitettavuudesta. Jos perhe annetaan sisällä mutta mikään ei vastaa sillä, joko poista se suunnitelmasta tai tee niistä palveluista aidosti kaksipinoisia.

Varaa virtuaaliosoite kussakin perheessä

swanctl-kokoonpanossa asiakas pyytää virtuaaliosoitteita, ja jokaisen perheen jokerimerkki pyytää vastaajaa varaamaan yhden kustakin. Vastaaja ottaa ne pooleista, ja poolit ovat erillisiä objekteja yhdyskäytävän takana olevista verkoista. Pidä ne erillään myös suunnitelmassa, koska palvelun etuliitteen kanssa päällekkäinen pooli tuottaa reitityksen, joka näyttää oikealta siihen hetkeen asti, kun liikenne laskeutuu jonnekin tahattomaan paikkaan.

Pyydä molemmat perheet, kun tarvitset molempia, ja yhtä, kun et tarvitse, koska käyttämätön osoite on käyttämätöntä politiikkapintaa. Yksittäinen pyyntö on pyyntö eikä varaus, ja vastaaja voi palauttaa toisen arvon oman politiikkansa mukaisesti. Tämä yksityiskohta on tärkeä kaikkialla, missä osoite on kovakoodattu palomuurisääntöön tai valvontatarkistukseen. Viittaa pooleihin nimellä yhteydessä ja pidä palveluverkot niiden ulkopuolella.

vips = 0.0.0.0, ::

Luo oma ainutlaatuinen paikallinen etuliite IPv6-poolille sen sijaan, että ottaisit käyttöön lyhyen esimerkkiarvon. Esimerkki näyttää asetuksen muodon, ei perittävää oletusarvoa.

Kuvaa kohteet erillään pooleista

Liikenteen valitsimet kuvaavat, mitä kumpikin osapuoli odottaa vaihtavansa, joten yhdyskäytävän paikallisten valitsimien tulee nimetä suojattuja palveluetuliitteitä eikä asiakaspoolia. Asiakkaan etävalitsimet heijastavat tätä aikomusta. Kun kaksi luetteloa kuvaavat eri objekteja, tunneli voi nousta ja silti kuljettaa mitään hyödyllistä.

Samat etuliitteet tarvitsevat paluureittejä ja sallitun edelleenlähetyksen yhdyskäytävän verkon sisällä, jokaiselle perheelle, jonka otat käyttöön.

Tässä yksityinen IPv6-suunnitelma lakkaa riittämästä. Ainutlaatuinen paikallinen osoitteistus ostaa yksityisen tavoitettavuuden eikä luo julkista IPv6-lähtöä, joten suunnittelu, joka olettaa numeroimattoman perheen yksinkertaisesti seuraavan IPv4-naamiointisääntöjä, tuottaa pettymyksen käyttäjilleen. Jos julkinen IPv6-pääsy on osa vaatimusta, se tarvitsee reititetyn suunnitelman ja ylävirran, joka on samaa mieltä. Muussa tapauksessa sano selvästi, että IPv6-puoli on vain yksityinen, mikä on rehellinen raja eikä piilotettava rajoitus.

Tee DNS:stä ja paluupoluista tarkoituksellisia

Nimien selvitys ei seuraa siirtoa. Ratkaisija voi palauttaa A- ja AAAA-tietueet vain IPv4-tunnelin yli, ja asiakas yrittää silloin perhettä, jota et koskaan suunnitellut. Päätä, mitkä palvelunimet kantavat käyttökelpoisia kaksipinoisia vastauksia, ja tee molemmista poluista tarkoituksellisia. Nimi, joka ratkeaa perheeseen ilman toimivaa polkua, tuottaa pysähdyksen eikä puhdasta virhettä, ja pysähdyksiä on paljon vaikeampi diagnosoida.

Dokumentoi ulomman päätepisteen tavoitettavuus erikseen, mukaan lukien onko NAT-läpäisyä pelissä ja mitä perhettä se käyttää.

Kirjoita sitten suunnitelma kuudelle riville: ulompi päätepiste, IPv4-pooli, IPv6-pooli, IPv4-palveluetuliite, IPv6-palveluetuliite ja reititin, jolle kunkin vastaukset kuuluvat. Sen muotoinen suunnitelma vastaa kysymyksiin, joita operaattori todella kysyy kolmelta aamuyöllä. Kaikki lyhyempi jättää kaksipinon toiseksi osoitteeksi, joka on pultattu vain IPv4-politiikkaan, ja niin se yleensä päätyy toimimaan puolittain.