Útvonalalapú vs. házirendalapú telephelyek közötti VPN: mi a különbség

Mindkét terv ugyanazt a forgalmat védi ugyanazzal az IPsec-gépezettel, és abban különböznek, hogy mi dönti el, melyik csomag kerül az alagútba. Házirendalapú kapcsolatnál a kialkudott forgalmi szelektorok végzik ezt a munkát; útvonalalapúnál egy alagút-interfészre mutató útvonal. A kettő összekeverése azt a megszokott támogatási szálat hozza létre, amelyben az alagút felépültként jelentkezik, miközben az alkalmazás semmit nem ér el. A megkülönböztetés akkor a legfontosabb, amikor hálózatot ad hozzá, útválasztási protokollt futtat, vagy olyan útvonalat hibakeres, amely csendben a rossz kimeneten távozik.

Két módja annak, hogy eldöntsük, mi kerül az alagútba

A házirendalapú VPN biztonsági házirendet épít, amely illeszkedik a forrás- és cél-előtagokhoz, majd titkosítja, ami beleillik. A partnernek kompatibilis szelektorokat kell kialkudnia, ezért a tényleges hatókör végül a két fél által javasoltak metszete lesz. A metszeten kívül semmi nem védett, bármit is mond az útválasztási tábla.

Az útvonalalapú VPN létrehoz egy interfészt, amely az alagutat képviseli, és hagyja, hogy az útválasztási tábla forgalmat küldjön bele. Az IKE-démon továbbra is telepíti az állapotot és az interfészenkénti házirendet, és ez az a részlet, amelyet kihagynak, amikor úgy döntenek, hogy az útvonalak felváltották a titkosítást. Mindkét terv IPsec-kel titkosít; csak a kiválasztási mechanizmus tér el.

Olvassa az alábbi összehasonlítást inkább hibajelek halmazaként, mint ponttáblázatként, mert egyik oszlop sem nyer önmagában.

Házirendalapú: a szelektor a szerződés

A szelektorokról tárgyalnak, nem csak beállítják őket. Javasoljon 10.10.0.0/16-ot az egyik oldalon és 10.10.1.0/24-et a másikon, és az együttállás azt fedi le, amiben a tárgyalás megállapodott, míg minden más hoszt kívül marad.

A telepített állapotot olvassa a konfigurációs fájl helyett. Linux-partnernél a kernel saját táblái az alapigazság, és megmutatják, mi élte túl a tárgyalást. Az a házirend, amely a helyes előtagokat nevezi meg, de nincs hozzá illeszkedő állapot, azt jelenti, hogy az együttállás soha nem jött létre. A rossz előtaghoz tartozó házirenddel párosított állapot az ellenkező probléma, és olyan alagutat hoz létre, amely egészségesnek tűnik, miközben egy alhálózat semmit nem ér el.

sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sas

Hasonlítsa össze mindkét kimenetet azokkal az előtagokkal, amelyekről azt hiszi, hogy védi őket. Ez az egyetlen összehasonlítás megoldja a működő alagútról és elérhetetlen szerverről szóló jelentések többségét. Azt is megmutatja, melyik partnert kell módosítani, mert az eltérés általában csak egy irányban látható.

Útvonalalapú: az interfész a szerződés

Az XFRM-interfész nevet és identitást ad az alagútnak, és a forgalom azért ér el hozzá, mert az útválasztási tábla ezt mondja. Több távoli előtag ekkor útválasztási problémává válik szelektorprobléma helyett, és egy útválasztási protokoll meghirdetheti őket. Ez az igazi nyereség, nem a titkosítás.

Az interfész nem szünteti meg a házirend szükségességét. A démon interfészenkénti szabályokat telepít, amelyek az interfész identitásához kötődnek, így a rossz interfészre érkező csomag továbbra is elbukik. Az a forrásoldali cím is elbukik, amelyet a partner nem fogad el, még tökéletes útvonal esetén is. Az útvonalalapú azt jelenti, hogy az útvonal dönt a belépésről, nem azt, hogy a házirend eltűnt.

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10

Figyelje az interfész-számlálókat, amint az útvonal a helyére kerül. Ha az útvonal létezik, de a számlálók nullán maradnak, az azt jelenti, hogy semmi nem illeszkedik az alagútba, ami általában hiányzó állapotra utal, nem hiányzó útvonalra.

Ahol a két terv valóban elválik

A hálózat hozzáadása a legtisztább próba arra, melyik modell illik Önhöz. Az útvonalalapú terv hozzáad egy útvonalat, és legfeljebb egyszer szélesíti a szelektort, míg a házirendalapú terv mindkét partneren szerkeszti az előtagpárokat és újratárgyal. Két stabil alhálózat triviálissá teszi ezt a szerkesztést, húsz pedig projektté.

Egyik modell sem helyettesíti a tűzfalat, és az összehasonlítások általában ez előtt a pont előtt megállnak. A széles szelektor vagy a széles útvonal azt dönti el, mi titkosított, nem azt, mi engedélyezett.

Az MTU viselkedése a gyakorlatban is eltér. A beágyazás csökkenti a hasznos terhelést, és az útvonalalapú interfész saját MTU-t hordoz, ezért az MSS rögzítése mindkét átjárón elkerüli a fekete lyuk tünetét, amikor a kis válaszok megérkeznek, a nagyok pedig eltűnnek. A házirendalapú alagutak ugyanabba a falba futnak a másik oldalról, mert a szelektor semmit nem mond a csomagméretről. Szándékosan állítsa be a rögzítést, ahelyett hogy a partnert hibáztatná.

Átállás a visszaút elvesztése nélkül

Rögzítse a meglévő előtagpárokat, mielőtt bármit módosít, majd mozgasson át egy alkalmazási útvonalat, és figyelje végig. Az az alagút, amely felépül, nem az az alagút, amely továbbít, és a különbség a válasz irányában jelenik meg.

Amikor a partnerek csatlakoznak, de a LAN-hosztok nem, vizsgálja meg a visszaútvonalat és azt a forrásoldali címet, amelyet a távoli hoszt használni fog. A két interfésszel rendelkező hoszt a rosszról válaszolhat, és semmilyen szelektorváltoztatás nem javítja ezt. Rögzítsen forgalmat mindkét végén, mielőtt algoritmusokat szerkeszt.

ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-conns

Tartson fenn egy olyan kezelési útvonalat, amely nem függ az alagúttól, miközben dolgozik. A visszaállítás könnyebb, ha az átjáró saját hozzáférése nem a hibakeresett kapcsolaton utazik.