Wêrom OpenVPN-klanten de IPsec-selektors fan de gateway misse
In ping fan de gateway bewissiget in oare flow. Folgje de kliïntpool fia de útsmiten rûte, de IPsec-selektors, de trochstjoerketting en it antwurdpaad.
Pingje in host efter de fiere IPsec-tunnel fan de gateway en hy antwurdet skjin, dat de tunnel liket sûn en it ticket giet fierder. Dan besiket in ferbûn klant deselde host en krijt neat werom. Dy ping wie nea bewiis foar de flow fan de klant, want hy gie fuort mei it eigen boarne-adres fan de gateway en kaam oerien mei in oare IPsec-selektor. Begripe wêrom’t de twa gefallen útinoar rinne is it grutste part fan de oplossing.
De ping fan de gateway testet in flow dy’t jo klant nea brûkt
It boarne-adres beslút hokker belied jildt. In pakket dat op de gateway makke wurdt, giet fuort mei in adres út syn pleatslike LAN of fan syn tunnel-einpunt, en it belied dat dêrby past is krekt foar dat gefal skreaun. It pakket fan in klant komt op de OpenVPN-ynterface oan mei in adres út de kliïntpool, wat in folslein oare selektor is.
Dêrom liket de flater op in rûteprobleem wylst er eins in probleem fan beliedsromte is. Berikberens fan de gateway bewiist dat de peer oan is en de foarstellen ûnderhannele binne, en it bewiist neat oer oft de pool beskerme is.
Stjoer it fiere prefiks út dat de applikaasje echt nedich hat
Nim it yllustrative pear 10.8.0.0/24 foar ferbûn klanten en 172.30.239.0/25 foar it beskerme fiere netwurk. Wat in klant nedich hat is in rûte nei dat twadde prefiks, net nei de LAN fan de gateway en net nei in oar tunneladres. In rûte dy’t nei de pool stjoerd wurdt is wat de klant dat ferkear oan de gateway oerjaan lit. Sûnder dat berikt it pakket nea it beliedsbeslút dat jo debugge.
Op in Community-tsjinner dy’t stjoerde rûtes akseptearret, nimt de rjochtline it echte masker: push "route 172.30.239.0 255.255.255.128". Access Server konfigurearret deselde bestimming fia de ynstellings foar privee-netwurk of tagongsregels fan de ynstallearre ferzje, mei de rûtearjende of oersette modus bewust keazen. Bewurkje fan generearre firewall-ketens ynstee fan de eigner-konfiguraasje is hoe’t in wurkjende opset ûnmooglik te reprodulearjen wurdt.
Lês nei it ferbinen de rûtetabel fan de klant ynstee fan de bedoeling fan de tsjinner. In rûte dy’t allinnich de pool dekt betsjut dat de stjoerder nea oankaam, en in standertrûte troch de tunnel is breder as dizze eask en sil jo letter ferrasse. Kontrolearje it masker likegoed as it prefiks, want in /25 dy’t as /24 stjoerd wurdt stjoert ferkear foar buoradressen yn in paad dat it net drage kin. Befêstigje dan dat de klant de tunnel-ynterface foar dy bestimming keazen hat.
Lit de selektors de kliïntpool omfetsje
Foar rûtearre tagong dy’t klantadressen bewarret, moat it IPsec-belied ferkear tusken de pool en it fiere prefiks beskermje. Selektors skreaun foar de eigen LAN fan de gateway litte de ping troch en smite it fersyk fan de klant fuort, en dat is krekt de asymmetrie dy’t dit ûndersyk begûn.
Ûndersykje it ûnderhannele belied likegoed as de konfigurearre foarstellen, bygelyks mei ipsec statusall op strongSwan of it lykweardige statuskommando foar jo ymplemintaasje. By beliedsbasearre IPsec kin de gewoane rûte nei in fysike ynterface wize wylst passend ferkear noch altyd fersifere wurdt, dat in ûntbrekkend tunnelapparaat bewiist neat. Ferlykje de selektorpearen mei de pool en it prefiks dat jo opskreaun hawwe.
Generyk boarne-NAT op de gateway kin de oerienkomst ek brekke. As in masquerade-regel de boarne fan de klant werskriuwt foardat de beliedskontrôle, liket it pakket net mear op de selektor dy’t jo skreaun hawwe. Dat is ien reden wêrom’t in breed masquerade-regel in minne twadde-VPN-oplossing is: it feroaret hokker belied jildt en hokker adres de fiere kant logt. Befrij it ferkear dat jo rûtearje wolle, of set it bewust oer en wurkje de selektors by.
Kies bewust foar rûtearjen of oersetten
Rûtearjen hâldt it klantadres sichtber foar de fiere kant, dat fiere logs en regels per boarne bliuwe sinfol, en it freget dat de fiere gateway it werompaad nei de pool ken. Oersetten ferberget de pool efter ien adres, wat it weromrûteprobleem fuorthellet en de identiteit per klant ferneatiget.
Kies ien ûntwerp en skriuw it op, want de twa hawwe ferskillende selektors en in oare firewall-oarder nedich. In heal tapaste masquerade lânet der tuskenyn en foldocht oan gjinien. De opskreaune kar is ek wat de folgjende yngenieur in bug fan in bewuste beslissing ûnderskiede lit.
Slút de lus op trochstjoeren en it antwurd
De gateway moat it protokol en de bestimming trochstjoere dy’t jo bedoele, wat betsjut dat IP-trochstjoeren oan is en dat in trochstjoerketting it pear tastiet. Dan moat de fiere kant antwurden weromstjoere fia it IPsec-paad, en dat is in rûtebeslút op harren gateway en net op joos. Beide helten binne gewoane konfiguraasje, en beide litte har maklik heal dien litte. Test se apart, sadat in ûntbrekkende trochstjoerregel net foar in stikken tunnel oansjoen wurdt.
Ferifiearje mei ien echt fersyk fan klant nei applikaasje, en sjoch hoe’t it de OpenVPN-ynterface, it IPsec-beslút en de fiere host passearret. Besjoch it antwurd as in aparte observaasje, want in fersyk dat oankomt en in antwurd dat nea weromkomt sjogge der fan de klant syn plak itselde út. Ien folge fersyk is mear wurdich as hokker oantal gateway-pings dan ek.
Hâld de autorisaasje fan de bestimming smel wylst jo teste, en befêstigje dat in klant sûnder de regel de tsjinst net berikke kin. In ynstallearre rûte plus in fêstige assosjaasje is net itselde as ferliende tagong.