As IKEv2 TS_UNACCEPTABLE weromjout, fergelykje de echte subnetsjes

Lês TS_UNACCEPTABLE as in ûnienigens oer dekking, net as in skansearre profyl. De gateway seit dat de beide kanten it net iens wurde koenen oer hokker adressen dizze tunnel drage mei. De IKE SA kin op dat stuit al oan wêze, en dêrom kin in klant ferbûn lykje sûnder in bern-SA efter him. As jo it sa frame, wurdt it wurk meganysk. Skriuw de bedoelde prefiksen fan beide kanten op, fergelykje se yn ien rjochting en fernauje oant se elkoar snije.

Skriuw earst de bedoelde pearen op

Foardat jo de konfiguraasje oanreitsje, listje fjouwer wearden op: it boarnerak fan 'e inisjator, syn bestimmingsberik en itselde pear sjoen fan 'e responder. Skriuw ek de adresfamylje fan elk op. In IPv4-berik en in IPv6-berik binne ferskate selektortypen, en gjin fan beide kin yn 'e payloade fan 'e oare fold wurde.

Foegje elke protokol- of poartbeheining ta dy't it belied draacht. In regel dy't allinnich TCP 445 nei in triemtsjinner tastiet, beskriuwt in smeller set as it subnetsje dêr't er yn sit. Lit dat út dyn notysjes wei en it ûnderhannelingsresultaat sil ynkonsistint lykje om redenen dy'tsto net sjochst.

Draai de labels om foardatsto se fergelykst

Lokaal en op ôfstân binne relative labels. It lokale prefiks fan 'e klant is it berik op ôfstân fan 'e gateway, en it lokale berik fan 'e gateway is dat fan 'e klant op ôfstân. Dêrom komme skermôfbyldings fan 'e twa einen nea oerien, en se letterlik fergelykje is de gewoane manier om in middei te ferliezen.

In responder kin in oanbod fernauje ta in akseptabele dielset ynstee fan it te wegerjen. Dat resultaat is slimmer as in skjinne mislearring, want it wurket heal. Freegje om 10.0.0.0/16 wylst it belied 10.0.5.0/24 tastiet, en jo kinne einigje mei in bern-SA dy't allinnich dat /24 dekt. Ien host antwurdet, al it oare falt bûten, en neat yn 'e klant seit dat. Lês de akseptearre selektors ynstee fan 'e oanfrege, foardat jo konkludearje dat de ûnderhanneling slagge is.

Road-warrior-profylen dy't in standertrûte freegje, lânje hjir geregeldwei. In gateway boud foar splitst tagong fernauet in oanbod mei fol berik ta syn eigen subnetsjes, en de klant moat it fernaude resultaat akseptearje of lûd mislearje.

Lês de wegering út ien besykjen

Sammelje beide logs út itselde ferbiningsobesyk. In bewarre profyl lit sjen wat jo konfigurearre hawwe, net wat foarsteld waard, en op strongSwan printsje swanctl --log de ûntfongen notify tegearre mei de selektors dy't it droech.

Undersykje dan wat der eins ynstallearre is. swanctl --list-sas lit de selektors fan 'e bern-SA sjen, en ip xfrm policy lit deselde berikken sjen as kernelbeliedsitems. In bern-SA yn dy list mei selektors dy't jo net bedoelden is in fernaujende barrens; gjin bern-SA plus TS_UNACCEPTABLE yn it log is in wegering.

Skied de tichtbye buorlju wylst jo der binne. INVALID_SELECTORS klaget oer in selektor binnen in fêstige bern-SA, wylst INTERNAL_ADDRESS_FAILURE betsjut dat de responder gjin firtueel adres tawize koe, wat in poolprobleem is en gjin dekkingprobleem.

Kontrolearje wat de set stil krimpt

Trije dingen krimpe in selektorset sûnder wat te sizzen. Responderbelied is it earste, fia subnetsjeslisten, groepsregels of autorisaasje per brûker dy't it oanbod ta in dielset ferlytsje. Adresfamylje is it twadde: in dual-stack-klant stelt faak IPv6 foar neist IPv4 en krijt in wegering foar berikken dy't de gateway nea konfigurearre hat.

Protokol- en poartbeheinings binne it tredde. Wêr't it belied allinnich TCP 445 tastiet, kin in bern-SA oankomme wylst ICMP en UDP derbûten bliuwe, en de brûker meldt in stikken tunnel wylst ien protokol alles wie dat ea tastien wie.

Dêrom kin allinnich it ferbreedzjen fan adressen in poartbeheind belied net reparearje, en dat is krekt it gefal dat it meast wierskynlik trije rûnen fan probleemoplossing ûnferoare oerlibbet.

Bewiis dekking mei ferkear dat past

Nei't de bern-SA ynstallearre is, stjoer ien oanfraach dy't grif binnen de akseptearre berikken falt. Sjoch nei de tellers ynstee fan it statusikoantsje: ip -s xfrm state en de tellers efter ip xfrm policy groeie as in pakket byinoar brocht en beskerme wurdt. In bytetelling dy't op nul bliuwt nei echt ferkear betsjut dat de kernel dat belied nea keazen hat.

Dat nul is in routing- of beliedsoarderprobleem, gjin kryptoprobleem. It liket ek krekt op in selektorwegering fan 'e brûkersstoel ôf, dêrom binne de tellers de muoite wurdich te sammeljen foardat jo it profyl wer iepenje. Tellers dy't mar yn ien rjochting groeie, wize ynstee op it weromwei.

Einigje troch it akseptearre pear yn 'e ticket te skriuwen, njonken it berik dat oarspronklik oanfrege wie. Hâld de seleksje sa smel as de eask, want de flater weihhelje troch in privee berik te ferfangen troch alle adressen jout folle mear tagong as't it akkount goedkard wie.