Második alhálózat hozzáadása webhelyek közötti VPN-hez: két út

Egy működő webhelyek közötti alagúthoz második alhálózatot hozzáadni az egyik tervezésnél öt perc, a másiknál majdnem egy egész délután. Amikor az alagút útvonalakat telepít a megnevezett előtagokhoz, hozzáad egy útvonalat, és a forgalom követi azt. Amikor egyetlen rögzített szelektorpárról tárgyal, az új előtag védelem nélkül marad, amíg mindkét fél meg nem egyezik egy illeszkedő párban. Három dolog dönt: mit ír le valójában az egyes oldalak konfigurációja, szűkül-e a tárgyalt forgalom a legkisebb illeszkedő párra, és kié az új tartomány visszaútja.

A kernelt olvassa, ne az állapotcímkét

Egy kapcsolatot jelentő alagút legalább egy gyermektársítást telepített, de nem feltétlenül azt, amelyre gondol. Linuxon a kernel mutatja, mi érvényesül: ip xfrm policy felsorolja a szelektorpárokat, és swanctl --list-sas (vagy a régebbi ipsec statusall) mutatja, miről tárgyaltak a felek, beleértve az irányonkénti forgalomszelektorokat. Ha az új előtag egyikben sem jelenik meg, védelem nélküli, bármit is mond a konfigurációs fájl.

Hasonlítsa össze az útvonaltáblával. Útvonal-alapú felállásban az alagút eszköze a következő ugrás a védett előtagokhoz. A házirend-alapú felállásnak gyakran nincs külön útvonala a távoli alhálózathoz, csak az alapértelmezett útvonal, mert a forgalmat a házirend választja, nem a tábla.

Házirend-alapú alagutak: mindkét félnek fel kell sorolnia az új előtagot

strongSwan szóhasználatban a szelektor a gyermekkonfiguráció local_ts és remote_ts bejegyzésében él, a leftsubnet és rightsubnet utódaiban. Az új előtagot mindkét oldalon tükrözötten kell látni: amit az A helyszín helyinek nevez, a B helyszín távolinak nevezi. Az eltérés ritkán ad tiszta hibát. A felek a metszetre szűkülnek, a régi előtag működik tovább, és csak az új hibázik csendben.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

pfSense-en vagy OPNsense-en ez egy második Phase 2 bejegyzést jelent, amely az új helyi alhálózatot az új távolival párosítja, majd alkalmazást. Tartsa meg a régi bejegyzést; a csere áthelyezi az eredeti alhálózatot ahelyett, hogy hozzáadná. Ha egy meglévő Phase 2 már lefed egy 0.0.0.0/0 típusú szuperhálózatot vagy összevont tartományt, ne adjon mellé szűkebb bejegyzést: az átfedő szelektorok versengő házirendeket telepítenek, és a kiértékelés sorrendje dönt a győztesről.

Az IKEv1 minden alhálózat-párt saját Phase 2-vé tesz, és az a fél, amely cserénként egy párt fogad, a többit eldobja. Az IKEv2 több szelektorpárt is vihet egy gyermekben, de csak ha mindkét megvalósítás elfogadja. A swanctl --list-sas listája a valóság; amit beírt, az kérés.

Útvonal-alapú alagutak: az útvonal a házirend

Az XFRM interfész vagy a VTI eszköz az útvonaltábla szerint viszi a forgalmat. Az új előtagot mindkét helyszínen az eszközre irányítja, és a interfész transzformációjához kötött állapot lép életbe. Nincs szinkronizálandó szelektorpár, ezért skálázódik ez a tervezés jobban az alhálózatok szaporodásával. A strongSwan továbbítási útmutatója részletesen tárgyalja a kernel oldalát.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

A WireGuard továbbviszi az ötletet. A AllowedIPs egyszerre a kriptográfiai engedélyezési lista és a wg-quick révén az útvonaltábla bejegyzése. Ha csak az egyik oldalon adja hozzá az előtagot, kézfogást, kimenő csomagokat és csendet kap, mert a távoli oldal eldobja azokat a csomagokat, amelyek forrása nincs a listáján. A wg set forma a teljes listát lecseréli, ezért ismételje meg a már működő előtagokat, különben elvágja őket:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Ez a második parancs nem opcionális, ha wg set-öt használt wg-quick helyett. A kernel azonnal elfogadja az új listát, de semmi nem ad hozzá útvonalat, így a helyben kelt forgalom továbbra is az alapértelmezett átjárón távozik. Ez a leggyakoribb oka annak, hogy egy új WireGuard alhálózat az alagút gazdagépéről működik, laptopról nem.

A visszaút gyakrabban hibázik, mint az alagút

Az új távoli alhálózat gazdagépeinek a válaszokat a VPN-átjárón keresztül kell visszaküldeniük. Ha ez az átjáró nem az alapértelmezett routerük, a válasz a LAN-routerhez megy, amely vagy eldobja, vagy privát forrásm címmel továbbítja az internetre. A távoli oldal gazdagépéről teszteljen, ne az átjáróról: ip route get 10.30.20.15 Linuxon vagy Find-NetRoute -RemoteIPAddress 10.30.20.15 PowerShellben megmutatja a következő ugrást, amelyet a gazdagép valóban használ. Ha a válasz nem az alagút végpontja, adjon ott statikus útvonalat az új előtaghoz.

Forrás-NAT azon a helyszínen, ahol hiányzik a visszaút, jogos alternatíva, és így kerüli el sok hub-and-spoke telepítés az egyes kiszolgálók érintését. Alkalmazza az új előtagra a céloldali átjárón is:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

Az ár valódi. A távoli naplók megszűnnek egyedi forrásm címeket mutatni, és az eredeti alhálózatra épülő tűzfal-szabályok egyetlen szabállyá olvadnak az átjáróhoz. Válassza ezt szándékosan, nem azért, mert hiányzott egy útvonal.

A tűzfalak a visszaút másik fele. A zónaalapú eszközök nem terjesztik ki automatikusan egy meglévő alagút-interfész zónáját az új alhálózatra, és a régi előtagra írt szabály nem fog illeszkedni. Adja hozzá az új alhálózatot a zónához vagy a szabálypárhoz mindkét irányban, mielőtt az IPsec-et hibáztatja.

Döntsön három kérdéssel, majd ellenőrizzen forgalommal

A rövid változat: az oldal konfigurációja előtagokat nevez meg (házirend-alapú), vagy a forgalom interfészbe irányul (útvonal-alapú)? Mindkét vég felsorolja az új előtagot? Van-e út vissza az új alhálózatról az eredeti forrástartományba?

Az ellenőrzés az a pont, ahol a legtöbb változtatás túl korán lezárul. Az átjáróról indított ping keveset bizonyít, mert az átjáró magából küld, és gyakran más házirendhez illeszkedik, mint egy gazdagép. Pingeljen az új alhálózat gazdagépéről, majd futtassa a változtatást kiváltó alkalmazást, és a számlálókat figyelje, ne az állapotikont.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Házirend-alapú alagútnál a ip xfrm state számlálóinak mindkét irányban nőniük kell; a lapos számlálók azt jelentik, hogy a csomag átirányul, de nem szelektálódik. WireGuardnál a wg show oldalankénti átvitelt mutat, és a nulla fogadott bájttal járó kézfogás a távoli oldal listájára vagy annak visszaútjára utal.

Fejezze be az előtag, az oldal szelektorának vagy útvonalának, a visszaút-döntésnek és a tűzfal-bejegyzésnek a rögzítésével az alagút többi leltárával együtt. Ezután indítson újra egy átjárót, és teszteljen újra: a kézzel hozzáadott útvonal eltűnik, és a következő embernek nem kell újra felfedeznie.