SoftEther SecureNAT: a DHCP és a NAT két külön döntés

A SecureNAT egyetlen jelölőnégyzet, amely két szolgáltatást kapcsol be, és a vele kapcsolatos zavar nagy része innen ered. Egy virtuális DHCP-kiszolgáló címet, maszkot, átjárót és gyakran feloldót ad az ügyfélnek. Egy virtuális NAT a kiszolgálói gazdagép saját hálózati vermét használva továbbítja a csomagokat ezen az átjárón túlra. A konfigurációban egymás mellett állnak, és egymástól függetlenül hibásodnak meg: az ügyfélnek lehet tökéletes bérlete és semmilyen működő útja, vagy működő útja rossz feloldóra mutató beállításokkal. Két döntésként ellenőrizze őket, és a diagnózis rövid lesz.

Két szolgáltatás egy jelölőnégyzet mögött

A virtuális DHCP oldal egy konfigurációs kérdésre válaszol: milyen beállításokat kap ez az ügyfél ezen a virtuális hubon belül. A virtuális NAT oldal egy továbbítási kérdésre válaszol: amikor az ügyfél csomagot küld a hubon kívüli címre, a kiszolgáló lefordítja és továbbítja-e. Az első a hubhoz helyi, és nem igényel felsőbb hálózatot. A második teljesen a gazdagéptől függ.

A virtuális gazdagép-interfész az első döntéshez tartozik, nem a másodikhoz. A címe, gyakran valami olyasmi, mint 192.168.30.1 alapértelmezésben, az az átjáró, amelyet a DHCP-szolgáltatás kínál. Ez nem a kiszolgáló nyilvános figyelő címe, és a kettő összekeverése olyan tűzfalszabályokat és ügyfélbeállításokat eredményez, amelyek egy olyan gépre irányulnak, amely nem létezik azon a hálózaton.

1. döntés: ki adja a címet

Ha a virtuális DHCP engedélyezve van, az ügyfeleknek bérletet kell kapniuk az Ön által beállított készletben, átjáróként a virtuális gazdagép-interfésszel és azzal a feloldóval, amelyet megadott. A bérletet vizsgálja, ne az ügyfél állapotszövegét, mert a «csatlakozva» az alagutat írja le, nem a címkiosztást:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Két hibamódot érdemes ismerni, mielőtt bármi mást hibakeresne. Az az ügyfél, akinél egy korábbi tervezésből maradt statikus cím van, megtartja azt, és figyelmen kívül hagyja a bérletet, ami úgy tűnik, mintha a DHCP megtagadná a választ. Egy áthidalt szegmensen lévő második DHCP-forrás pedig ugyanazokért az ügyfelekért versenyez, ami szakaszos címeket és olyan támogatói sort eredményez, amely nem tudja reprodukálni a problémát.

Az átfedő készletek is ide tartoznak. Ha a virtuális DHCP készlete átfed a gazdagép LAN-alhálózatával vagy egy másik hub készletével, az ügyfél olyan címet kap, amely kétértelműen útvonalazódik, és minden későbbi teszt nem egyértelmű.

2. döntés: ki továbbít a virtuális átjárón túlra

Bekapcsolt virtuális NAT mellett a kiszolgáló fordítja le a hubból kifelé menő forgalmat, és a gazdagép útválasztási táblázatán keresztül küldi tovább. Ez azt jelenti, hogy a továbbítási lánc: ügyféltől a virtuális átjáróig, virtuális NAT-tól a gazdagép verméig, a gazdagép vermétől az alapértelmezett útvonaláig. Minden láncszem meghibásodhat anélkül, hogy a többit érintené, és a hiba jelei különböznek.

A második döntést olyasmivel tesztelje, aminek el kell hagynia a hubot, nem a hubon belüli dologgal. A virtuális átjáró pingelése csak az első láncszemet bizonyítja, semmi többet:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Ha a névfeloldás működik, de a nyilvános címre irányuló kapcsolatok meghiúsulnak, a továbbítási láncban van, nem a DHCP-ben. Ha mindkettő meghiúsul, először a feloldót ellenőrizze, mert az elérhetetlen belső címként kiosztott feloldó egy működő utat teljesen töröttnek mutat.

A SecureNAT továbbítását a kiszolgáló folyamata valósítja meg, nem az a kernel-továbbítási út, amelyet híddal használna. Ez kényelmes és lassabb a hidalásnál, és azt is jelenti, hogy a gazdagép saját tűzfalszabályai és útválasztási döntései továbbra is érvényesek a lefordított forgalomra. A virtuális NAT nem kerüli meg a gazdagép házirendjét; használja azt.

A gazdagép saját útja harmadik dolog

A fentiek mind azt feltételezik, hogy a kiszolgálói gazdagép eléri a célt. Az a gazdagép, amelynek nincs működő felsőbb útvonala, korlátozó kimenő házirendje van, vagy nincs meg az a címcsalád, amelyre szükség van, elbukik a második döntésnél, akármilyen helyes a hub konfigurációja. Ellenőrizze a gazdagépet külön, az alagúton kívül, mielőtt a hibáját a SoftEthernek tulajdonítaná.

A SecureNAT nem is felhatalmazás a kiszolgálóhoz csatlakozó minden hálózat elérésére. Lefordítja és továbbítja a hozzá érkező forgalmat; annak eldöntése, mit érhet el a gazdagép, továbbra is a gazdagép tűzfalának és útválasztásának dolga, és az a tervezés, amely a hozzáférés megadásában az alagútra támaszkodik, egy rossz szabályra van attól, hogy túl sokat adjon.

A címcsaládok saját ellenőrzést érdemelnek. Egy működő IPv4 DHCP-példa nem bizonyítja, hogy a buildjében minden IPv6-képesség jelen van, ezért olvassa el annak a verziónak a kézikönyvét, amelyet ténylegesen futtat, mielőtt kettős verem viselkedését ígérné. A kézikönyv SecureNAT-fejezete a jelenlegi kiadás virtuális NAT- és DHCP-funkcióit tárgyalja.

Minden döntést a saját tesztjével ellenőrizzen

Az első döntést bérlet-ellenőrzéssel fogadja el: cím a készletben, átjáró egyenlő a virtuális gazdagép-interfésszel, feloldó az, amelyet beállított. A másodikat az ügyféltől induló kimenő kéréssel és a kiszolgálón lévő NAT-táblázatba vetett pillantással fogadja el, mert a növekvő munkamenetszám az egyetlen közvetlen bizonyíték arra, hogy a fordítás megtörténik, és nem csak arra, hogy be van kapcsolva.

Ezután jegyezze fel a felosztást a tervezési feljegyzésbe: melyik komponens adja a címet, melyik komponens továbbít, és melyik gazdagép-interfészen lép ki a forgalom. Amikor egy újraindítás megváltoztatja a viselkedést, az a feljegyzés megmondja, melyiket kell megvizsgálni a három közül, ahelyett hogy mindent újraindítana, és abban bízna, hogy a tünet továbbmozdul.

Még egy döntés tartozik a nyilvántartásba, még ha ma nem is hozza meg: a SecureNAT és a helyi híd különböző tervek ugyanahhoz a hubhoz, és az a hub, amelynek mindkettőre szüksége van, olyan hub, amelynek más tervre van szüksége. Válasszon szándékosan, írja le, miért, és a következő embernek nem kell visszafejtenie egy futó konfigurációból.