A webszerver eltűnik, amikor a VPN-kliens csatlakozik

Egy szolgáltatás, amely abban a pillanatban eltűnik, amikor egy VPN-kliens csatlakozik, általában nincs blokkolva, hanem a rossz interfészen keresztül válaszol. A kérés a fizikai hálózati kártyára érkezik, a démon választ ír, és az útválasztási tábla ezt a választ az alagútnak adja, mivel az alagút átvette az alapértelmezett útvonalat. A távoli kliens soha nem lát választ egy általa megnyitott kapcsolatra, ezért vár, majd időtúllépést jelent. Ebben a sorrendben sehol nem szerepel tűzfalszabály.

A tünet: kérések be, válaszok a rossz ajtón ki

Az árulkodó jel egy bejövő kapcsolat, amely meghiúsul, miközben a gazdagépen minden más működik. További jel a LAN-ról elérhető, de az internetről nem elérhető gazdagép, vagy olyan, amely addig működik, amíg az alagút újra nem csatlakozik, majd leáll. Minden esetben az oda irány működött, a vissza irány nem, ami útválasztási aszimmetriára utal, nem házirendre.

Igazolja ezt annak megfigyelésével, hová megy a válasz, nem annak megfigyelésével, hogyan érkezik a kérés.

Rögzítsen egyszerre a fizikai interfészen és az alagút eszközén. Ha a kérés a fizikai interfészen, a válasz pedig az alagúton jelenik meg, a diagnózis kész. Az a válasz, amely sehol nem jelenik meg, azt jelenti, hogy a szolgáltatás soha nem fogadta el a kapcsolatot, ami külön vizsgálat külön okkal.

Két alapértelmezett útvonal és egy útválasztási döntés

Az a kliens, amely alapértelmezett útvonalat telepít, egy második bejegyzést ad hozzá a LAN-átjárónál jobb metrikával. Néhány kliens ehelyett két fél-tartományos útvonalat telepít, amelyek ugyanazt a teret pontosabban fedik le, és ugyanúgy nyerik meg a keresést. Mindkét technika hagyja, hogy a szokásos kimenő csomagok az alagút interfészét válasszák.

Ezt a választást kizárólag a cél határozza meg. A kernel nem kérdezi, honnan jött egy csomag, hacsak egy házirend-szabály nem utasítja erre. Így a nyilvános klienscímre adott válasz az alagútnak adódik, amelynek távoli vége egy olyan forrású csomagot kap, amely nem az övé, és eldobja, vagy valahová haszontalanul továbbítja. Linuxon a szigorú fordított útvonal szűrés is eldobhatja az eredeti kérést, mielőtt a szolgáltatása egyáltalán látná, ami kívülről azonosnak tűnik. Mindkét tünet ugyanabból a hiányzó kapcsolatból ered a bejövő folyam és annak válasza között.

Az alagút végig helyesen viselkedik. Utasították, hogy vigye az alapértelmezett útvonalat, és pontosan ezt teszi.

Javítsa a visszautat az alagút feltörése nélkül

Három tartós javítási forma létezik, és a választás attól függ, mennyi maradjon a gazdagép saját forgalmából az alagúton belül. A szolgáltatás céljának vagy portjának kizárása a legkisebb változás. A forrás vagy jelzés szerinti házirend-alapú forgalomirányítás a legpontosabb. A forrásfordítás a legdurvább és két év múlva a legkönnyebben elmagyarázható.

Aszerint válasszon, mit kell a gazdagépnek tennie, nem aszerint, melyik részletet találta meg először.

A cél kizárása stabil nyilvános című szolgáltatáshoz illik, és a démon fizikai címhez kötése minden cím helyett biztonságosabbá teszi ezt a kizárást. Az a házirend-szabály, amely forrás szerint választ táblát, az alagúton belül tartja a gazdagép saját kapcsolatait, miközben a szolgáltatás válaszait a WAN-átjárón keresztül küldi vissza. A válaszok maszkírozása a WAN-interfészre ugyanarra az útra jut el azon az áron, hogy elrejti a kliens címét a szolgáltatás naplóiból. Az alapértelmezett útvonal ad hoc módosítása diagnózis, nem konfiguráció, mert a kliens minden újracsatlakozáskor újraírja az útvonalakat.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Amikor a gazdagép a mögötte lévő LAN számára is forgalomirányít

Egy ugrással kijjebb ugyanaz az aszimmetria több mozgó alkatrésszel tér vissza. A forgalom az internetről eléri az útválasztót, továbbítódik egy belső eszközre, és annak az eszköznek az egyetlen visszauta az alagút, így a válasz az eredeti klienshez a szolgáltató saját címéről érkezik. Ezután a kapcsolatkövetés egy olyan folyam válaszával találkozik, amelynek a kezdetét nem látta, és eldobja azt. A kliens közben semmit sem lát.

Két változtatás javítja: célfordítás, hogy a bejövő kapcsolat elérje a belső eszközt, és forrásfordítás, hogy az eszköz válasza úgy tűnjön, mintha magától az útválasztótól jönne.

Az útválasztó firmware-ében a szokásos megfogalmazás egy házirend-szabály, amely a porttovábbítást a WAN-oldalhoz rögzíti, miközben az útválasztó saját forgalma az alagúton halad. Forrásfordítás nélkül ez a válasz a külső klienshez szól, és a belső eszköznek egyszerűen nincs útvonala hozzá. Teszteljen három dolgot külön, mert különböző okokból hiúsulnak meg: a kívülről érkező kapcsolat, az, amelyet a gazdagép maga indít, és egy névfeloldás.