Kontsolak up erakusten du, strongSwanek IKE elkartze ezarria duela jakinarazten du, eta paketeak ez dira iristen. Konparatu beharreko hurrengo gauza ez da aldez aurretik partekatutako gakoa, tunelak babesten dituela alde bakoitzak uste duen aurrizkien bikotea baizik. Egin beheko egiaztapenak ordenan, lehenengo biek erabakitzen baitute tunelak zure trafikoa batere garraia dezakeen.

Itzuli AWSren izenak strongSwanen terminoetara

AWSk bezeroaren aldetik deskribatzen du konexioa: bezeroaren atebidearen helbidea eta CIDR lokala zureak dira, eta CIDR urrunekoa VPCrena da. strongSwanek bi muturrei left eta right deitzen die, zure aurrizkia leftsubnet-en eta VPCren aurrizkia rightsubnet-en daudelarik. Bikote bat alderantziz jartzeak trafiko okerra negoziatzen eta hautatzen duen tunela sortzen du.

Deskargatu AWSk konexiorako sortzen duen konfigurazioa eta erabili konexio horretarako erreferentzia gisa, tunelaren helbideak eta aurrizkiak barne. Sortzean CIDR eremu biak hutsik uzten badituzu, zerbitzuak 0.0.0.0/0 balio lehenetsia erabiltzen du alde bakoitzean. Aurrizki estua duen bideratzaile bat ez da inoiz harekin bat etorriko, beraz bete eremuak edo zabaldu hautatzailea nahita.

Hemen desadostasuna bideratze-hutsegitea dirudi eta ez da.

Finkatu AWSk benetan ikusten duen helbidea

NAT atzean dagoen bideratzaile batek beste aldeak inoiz ezagutu ez duen interfaze batetik sor dezake IKE. AWSn erregistratutako atebidearen helbidea AWSk sarean ikusten duena izan behar da, eta bideratzailea helbide lokal berari finkatu behar zaio, bere bide lehenetsiari jarraitu beharrean.

conn %default
    local_addrs = 203.0.113.10

strongSwann local_addrs-ek IKErako iturburu-helbidea hautatzen du, eta OpenSwan konfigurazio zaharrek ideia bera left gisa idazten dute. Zuzendu helbide publikoa duen interfazera, gero egiaztatu NAT gailuan bertan UDP 500 eta 4500 host horretara iristen direla, aurreko bideratzaile batetik geratu zen arau batek isilka botatzen baititu. Hautatzaile bikote zuzena iturburu-helbide okerrarekin oraindik huts egiten du, eta erregistroak proposamena salatuko du. Nahaste hori da iturburu-helbideak bere egiaztapena merezi duen arrazoia.

Baieztatu birbidaltze-araua suposatu beharrean, aurreko bideratzailearentzat zuzena zen araua askotan geratzen baita.

Landu 1. fasea eta 2. fasea bereizita

AWSk IKE eta ESP aukerak zerrenda bereizi gisa erakusten ditu. Bi aldeek onartzen duten IKE multzo batek ezer esaten ez du ESP proposamenez, bi zerrendak independenteak baitira. Irakurri biak sortutako konfiguraziotik eta konparatu bat-batean.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Sintaxia ez da inplementazioen artean bidaiatzen. OpenSwanen funtzionatzen duen bikote batek, adibidez phase2alg=aes_gcm ike=aes256-sha1;modp1024-rekin, strongSwanen esp= eta ike= formara itzuli behar du, eta algoritmoen izenak desberdinak dira. GCM enkriptatzen duen bitartean autentifikatzen duenez, ez du integritate-transformazio bereizirik behar, SHA-rekin parekatutako CBC multzo batek ez bezala. Daemon batetik bestera itzuli gabe itsatsitako 2. faseko lerro batek hautatzaileen desadostasun gisa irakurtzen den ukapena sortzen du.

Egiaztatu child elkartzea, ez tunelaren adierazlea

Konexioa kargatzen bada baina child elkartzerik sortzen ez bada, proposamena edo hautatzaileak ukatu dira. Child bat sortzen bada eta haren hautatzaileek zure aurrizkiak kanpoan uzten badituzte, paketeak tunelera iritsi aurretik iragazten dira. Kontsolaren adierazleak IKE maila soilik estaltzen du, beraz ezin dizu esan bi gauzetatik zein gertatu zen.

ipsec statusall

Bilatu child segurtasun-elkartzea eta irakurri haren ondoan inprimatutako trafiko-hautatzaileak, gero konparatu itzazu sortutako konfigurazioko aurrizkiekin.

Probatu aurrizki lokalaren barruko host batetik VPCren aurrizkiaren barruko host batera, eta egiaztatu itzulera-bidea eta AWS aldeko segurtasun-talde edo sare-ACL oro. Hautatzaile zuzenek ez dute pakete bat geroago botatzea eragozten.

Hautatzaileak bat etorri ondoren oraindik huts egiten duenean

Baieztatu bi aldeetan bidea tunelera doala, gero baieztatu NAT gailuak ez duela trafikoa politikak espero ez duen moduan berridazten. Politikan oinarritutako tunel batek paketeen helbideak bat datoz, beraz politikaren erabakiaren ondoren aplikatutako itzulpen batek emaitza aldatzen du.

Erregistratu pakete bat sarrera eta bat irteera alde bakoitzean, beste proposamen bat aldatu aurretik.

Idatzi hautatzaileak, 1. eta 2. faseko proposamenak eta iturburu-helbidea txartelean. Lau balio horiek site-to-site hutsegite gehienak azaltzen dituzte dei bat egin gabe.

Erlazionatutako artikuluak