strongSwan-en tunel osoak 0.0.0.0/0 behar du bi aldeetan

Azpisare pribatu bakarrerako funtzionatzen duen strongSwan konexioak ez du interneteko trafikoa eramango norbaitek lerro bat editatu duelako bakarrik. Tunel osoa bi alderdien arteko akordioa da child SA-k zein helbide babesten dituen, eta alderdi bakoitzak bestea bere buruarekiko izendatzen du. Alde bat ondo eta bestea gaizki jarrita, child SA ez da altxatuko edo asmoa baino estuago altxatuko da. Beheko bost egiaztapenek akordio horri jarraitzen diote, bezerotik atebidearen bidez internetetara.

Egiaztatu lehenengo bezeroaren hautatzailea

Bezeroak urruneko aldean babestu nahi duena remote_ts gisa deskribatzen du, eta bidaltzen duen guztia bere helbide esleitutik abiatzen da. Interneteko trafikoarentzat balio horrek erabiltzaileak benetan iritsiko dituen helmugak estali behar ditu, eta horrek praktikan IPv4 espazio osoa esan nahi du. Azpisare bakarra zerrendatzen jarraitzen duen bezeroak tunel zatitua eskatzen du, interfazean profila nola deitzen den gorabehera. Iturburu-aldea normalean dynamic izaten da, helbidea konektatzean esleitzen delako. Han idatzitako iturburu finkoa hautsi egiten da helbide-multzoa aldatu bezain laster.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Zatia ez da konexio-fitxategi osoa, eta honek suposatzen du autentifikazioa, identitateak eta helbide birtualen multzoa jada konfiguratuta daudela. Bezeroaren iturburu-hautatzaileak eta zerbitzariak esleitzen duen helbideak bat etorri behar dute oraindik, bestela child SA bi alderdiek espero ez zuten esparru batekin altxatuko da. Kargatu swanctl --load-all erabiliz eta irakurri irteera arrakasta suposatu aurretik. Parsetzen den fitxategi bat baztertua izan daiteke oraindik beste alderdiaren proposamenarekin gainjartzen ez den hautatzaile batengatik.

Egiaztatu atebidearen hautatzailea bere aldean

Atebideak kontzeptu bera kontrako noranzkotik irakurtzen du. Interneteko helmugak atebidearentzat lokalak dira, beraz haren local_ts zabala da eta remote_ts bezeroen multzoa deskribatzen du. Inbertsio hori da tunel osoaren konfigurazioan ohikoena den akatsa, eta berrikuspena gainditzen du, bi lerroak bereizita sinesgarriak diruditelako.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Bezeroaren zatia atebidearen fitxategira kopiatzeak ezer erabilgarririk deskribatzen ez duen hautatzaile-parea sortzen du, bi alderdiek rol bera aldarrikatuko luketelako. strongSwanen birbidalketa-gidak bezeroaren eta atebidearen parekatzea espresuki dokumentatzen du, eta konexio-fitxategiaren ondoan irakurtzea merezi du, huts egin ondoren irakurtzeak baino gehiago. Atebidearen fitxategiak remote_ts-ek aipatzen duen multzoaren definizioa ere behar du. Existitzen ez den multzo bat izendatzen duen hautatzailea kexarik gabe kargatzen da eta konektatzean huts egiten du.

ipsec.conf zaharkituak ezkerreko eta eskuineko rolak erabiltzen ditu gako ezberdinekin, eta rightsubnet lerroa ez da swanctl balioaren ordezkapen zuzena. Mantendu bi sintaxiak fitxategi bereizietan, bat bestean itsatsi beharrean. Biak direktorio berean nahastea da funtzionatzen duen konexio bat berrabiarazi ondoren isiltasunean atzera egiteko modua.

Egiaztatu negoziatutako child SA, ez fitxategia

Gordetako konfigurazioak asmoa frogatzen du eta besterik ez. Beste alderdiak eskatutakoa estutu dezake, eta lehendik dagoen child SA ez da ordezkatzen azpian fitxategia aldatu delako soilik. Egiaztatu zer dagoen benetan instalatuta beste ezer aldatu aurretik.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Lehen komandoak daemonak zer kargatu duen erakusten du, bigarrenak ezarritako child SA-ak, eta hirugarrenak nukleoak aplikatuko dituen politikak. Fitxategiak 0.0.0.0/0 esaten badu eta zerrendak azpisare bakarra erakusten badu, negoziazioak esparrua estutu du eta fitxategia berriro irakurtzeak ez du hori azalduko. Amaitu child, berrabiarazi eta konparatu hiru irteerak berriro. Esparru estutu berarekin itzultzen den child bat urruneko aldeak estutzen du, ez fitxategi lokalak, eta hori beste administratzailearekin izandako elkarrizketa da, ez tokiko aldaketa.

Irakurri bi noranzkoak politika-zerrendan, noranzko bat instalatzen duen eta bestea ez duen tunel bat konfigurazio-jantzizko bideratze-arazoa delako. Aurrera eta atzera politikak hautatzaile-pare bera ispilu-iruditan izendatu behar dute, eta falta den ispilua daemonaren edo proposamenaren akatsa da, ez hautatzailearen testuarena.

Egiaztatu birbidalketa eta itzulera-ibilbidea

Hautatzaile batek trafikoa atebidera onartzen du; ez du atebidea trafiko hori aurrera bidaltzera behartzen. Birbidalketa gaituta egon behar da, suebakiak fluxua baimendu behar du, eta erantzunak bezeroen multzoraino itzultzeko bidea aurkitu behar du. Hiru baldintza bereizi dira, eta bakoitzak sintoma ezberdin batekin egiten du huts. Falta den birbidalketa-arau batek zulo beltz gisa jokatzen du, eta falta den itzulera-ibilbide batek norabide bakarreko tunel gisa.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Bezeroen helbide pribatuek iturburuaren itzulpen deliberatua behar izaten dute interfaze publikoa utzi aurretik, eta esplizituki bideratutako esleipenak beste tratamendu bat behar du. NAT jokoan badago, mantendu inplementazioak onartzen dituen salbuespenak, segurtasun-politika batek ikuskatu beharko lukeen trafikoa haren ondotik itzul ez dadin. Beste atebide batetik kopiatutako masquerade-arau zabal batek autoreak asmo zuen baino askoz fluxu gehiago aldatzen ditu. Idatzi araua bezeroen multzorako soilik, eta utzi komentario bat zergatik dagoen azaltzen.

Bezeroan, egiaztatu backendak instalatutako ibilbideak, suposatu zenituen ibilbideak ez ezik. Ibilbideen instalazioa desgaituta duen kudeatzaile batek eskuz mantentzen den bideratze-diseinua behar du, eta diseinu hori tunela aldatu ahala eguneratu behar da. Egiaztatu bideratze-taula berriz konektatu ondoren, ez bakarrik abio berri baten ondoren.

Egiaztatu tunelak oraindik estaltzen ez duena

Hautatzaile-pareak IPv4 estaltzen du eta besterik ez. IPv6, DNS eta aplikazio mailako edozein politika erabaki bereiziak dira, hautatzaile IPv4 zabal batek isiltasunean baztertzen dituenak. IPv4 pakete bakoitza daraman tunel batek izen-kontsulta bakoitza filtratzen jarrai dezake.

Adierazi espresuki aurreikusitako DNS bidea, tokiko resolveraren bidez izenak oraindik ebazten dituen tunel oso batek kontsultak tunelaren kanpora ihes egiten duelako eta izen pribatuak hausten dituelako. Bezeroari IPv6 helbidea esleitzen bazaio, helbide-familia horrek tratamendu bera behar du, bestela ostalariak tunelak babesten ez duen bidea nahiago izango du. Probatu alde pribatuak soilik erantzun dezakeen izen batekin, eta erantzun publikoa ihes gisa hartu.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Egiaztatu katea bi komando horiekin eta goiko zerrendako negoziatutako hautatzaileekin. Traceroute-ak tokiko bideratzailea lehen jauzi gisa erakusten badu, trafikoak ez du tunela erabiltzen, hautatzaileek diotenari kalterik gabe. Interneteko sarbidea osatuta dago soilik aukeratutako trafikoa diseinatutako atebidetik onartzen, birbidaltzen eta itzultzen denean. Profil batean 0.0.0.0/0 aurkitzea kate horren hasiera da, ez haren froga.