A StrongSwan olyan DNS-címet küld, amelyet a Mac nem ér el

Minden működik, amíg valaki nem nyit meg egy MacBookot. A tunnel felépül, a belső hosztok cím szerint válaszolnak, és a névfeloldás meghal. Az iPhone-on ugyanaz a profil ugyanígy viselkedik, míg a Windows és Linux ügyfelek rendben vannak. Általában a küldött DNS-attribútum a hibás: a kiszolgáló a saját nyilvános interfészcímét osztja ki, és az Apple IKEv2-ügyfele nem küld oda lekérdezéseket a tunnelen keresztül. Helyezze a feloldót a poolba, és a tünet eltűnik anélkül, hogy hozzányúlna az ügyfélhez.

A tünet a küldött címre mutat

Amikor csak néhány platform hibázik, a tunnel és a hitelesítő adatok szinte biztosan rendben vannak, mert azok közösek. Az tér el, hogy az egyes ügyfelek hogyan alkalmazzák a kapott konfigurációs terhelést, beleértve a belső DNS-kiszolgálót. Az az ügyfél, amely elfogadja a címet, de a lekérdezéseket a tunnel mellett irányítja, olyan feloldóhoz jut, amelyet lát és nem tud használni.

A nyilvános cím a szokásos választás, mert ez az egyetlen, amelyet az adminisztrátor már ismer. Ez az egyetlen cím is, amely garantáltan a tunnel saját előtagján kívül esik, és pontosan ez a tulajdonság töri meg az Apple ügyfeleit.

Nézze meg az értéket, mielőtt bármit módosítana. Ha a küldött feloldó a kiszolgáló WAN-címe, megtalálta a probléma formáját, és kihagyhatja a többi találgatást. Hasonlítsa össze a pool előtagjával is, mert a poolon belül, de a bérleti tartományon kívül eső cím pontosan az lesz, amilyen a javítás lesz. Két perc a konfigurációval többet ér egy délutánnyi csomagrögzítésnél az ügyfélen.

Vágja ki a feloldót a bérleti tartományból

Adjon a tunnelnak olyan címtervet, amelyben a feloldó a pool saját alhálózatának tagja, majd foglalja le ezt a címet, hogy soha ne adják bérbe egyetlen ügyfélnek sem. Ebben a példában a pool 10.180.7.0/24, a kiszolgáló a 10.180.7.1-et tartja, és a bérletek 10.180.7.2-nél kezdődnek.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

A pool előtagja és a feloldó egy alhálózatot oszt meg, így az az útvonal, amely már hordozza a tunnel forgalmát, a lekérdezéseket is hordozza. Ez az egyetlen tulajdonság teszi a javítást ügyfelek között hordozhatóvá. Egy swanctl-konfigurációban ugyanez a két tény pool-definícióként és a kapcsolat DNS-beállításaként jelenik meg, nem ipsec.conf szintaxisban.

A kiszolgálónak ehhez nem kell új fizikai interfész. A 10.180.7.1 hozzáadása a loopback interfészhez elég ahhoz, hogy a feloldó kötődjön és válaszoljon, mert az ügyfelek a már létező pool-útvonalon keresztül érik el. Tartsa a címet a bérleti tartományon kívül, hogy egyetlen ügyfél se foglalja le véletlenül. Ha a poolt külső DHCP- vagy RADIUS-szolgáltatás kezeli, ott is foglalja le a címet, különben az első kérdező ügyfél elviszi.

Kösse be a feloldót, és zárja be az 53-as portot

Címet kiosztani nem ugyanaz, mint rajta figyelni. Az a feloldó, amely csak a LAN-címen figyel, elutasítja vagy figyelmen kívül hagyja a pool címére küldött lekérdezéseket, és az ügyfél olyan időtúllépést lát, amely útvonalhibának tűnik.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Ez az unbound-töredék elfogadja a tunnel pooljából érkező lekérdezéseket, és minden mást elutasít, ami a legtöbb vállalati feloldó politikája. Ha ugyanaz a példány a LAN-ügyfeleknek is válaszol, adja hozzá kifejezetten a LAN-előtagot, ahelyett hogy a figyelőt minden forrásra kiterjesztené.

Ezután a tűzfal-szabályoknak meg kell egyezniük a feloldó saját hozzáférés-ellenőrzésével. Fogadja el az 53-as portot a poolból, és dobja el mindenhol másutt, de előbb ellenőrizze a lánc sorrendjét.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Egy korábbi, szélesebb elfogadási szabály dekorációvá teszi az utolsó két sort, és a feloldó elérhető marad az internetről. A számlálókkal együtt olvassa a tényleges szabálykészletet, ahelyett hogy a szándékolt sorrendben bízna. Az alternatív politika, a nyilvános cím küldése és a bármely forrásból érkező lekérdezések engedélyezése sok ügyfélnél működik, de az internetre teszi a feloldót, és saját sebességkorlátozást és megfigyelést igényel.

Ellenőrizze, mit kapott valójában az ügyfél

Először a kiszolgáló nézetét ellenőrizze, majd az ügyfélét, mert a kettő tanulságos módon tér el. A pool listája megmutatja, melyik címet adták bérbe, a biztonsági társulások listája pedig azt, hogy a kapcsolat áll-e a várt identitással.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

A közvetlen lekérdezés bizonyítja, hogy a feloldó a pool címén válaszol egy olyan hosztról, amely eléri. Nem bizonyítja, hogy a Mac ezt a kiszolgálót választotta. macOS-en a scutil --dns hatókörös szolgáltatásonként listázza a feloldókat, és informatívabb az összegző panelnél; Windows-on a Get-DnsClientServerAddress mutatja, hogy a tunnel-adapter elfogadta-e a küldött értéket.

Ha az ügyfél a pool címét mutatja, és a lekérdezések továbbra is időtúllépnek, a tunnel-útvonal vagy a tűzfal-lánc a hibás. Az az ügyfél, amely semmilyen feloldót nem jelent, azt jelenti, hogy a konfigurációs terhelés soha nem érkezett meg, ezért nézze meg, hogyan alkalmazza az a platform a küldött beállításokat, ne a hálózatot. Jegyezze fel, melyik esetet látta, mielőtt bármi mást módosítana. Ez a két hiba azonosnak látszik egy támogatási jegyben, és ellentétes javításokhoz vezet.