Nie można uzyskać dostępu do usługi zewnętrznej z wewnętrznej sieci LAN

Mam dziwny problem z przekierowaniem portów. Próbowałem otworzyć mój port 22 na zewnętrzną sieć. Byłem w stanie uzyskać do niego dostęp, dopóki nie jestem w sieci LAN. Mogę na przykład uzyskać dostęp z mojego biura. Ale z sieci LAN mogę uzyskać dostęp do portu za pomocą lokalnego adresu IP, ale nie mogę uzyskać dostępu do portu za pomocą zewnętrznego adresu IP. To tak, jakby router blokował sprzężenie zwrotne. Sprawdziłem wszystkie ustawienia routera, wyłączyłem wszystko związane z zaporą ogniową / filtrowaniem. Jakieś pomysły?

Zakładając, że Spiff jest poprawny, a router nie jest w stanie obsłużyć przekierowania portów na zewnętrzny adres IP z sieci, istnieje pewne obejście (i wygląda na to, że tak jest);

Możesz edytować plik hosts, który znajduje się w / etc / hosts w większości systemów uniksowych oraz w C: \ Windows \ system32 \ drivers \ etc \ w systemie Windows.

jeśli dodasz

192.168.0.15  example.com

w tym pliku komputer przejdzie do adresu IP za każdym razem, gdy spróbujesz uzyskać dostęp do example.com. Będziesz oczywiście musiał to zrobić na każdym komputerze, którego chcesz używać w sieci.

Możesz sprawdzić artykuł na Wikipedii, aby uzyskać więcej informacji o tym, gdzie go znaleźć: https://en.wikipedia.org/wiki/Hosts_file

Biorąc pod uwagę, że wspomniałeś o przekierowaniu portów, zakładam, że twoja brama domowa działa jako brama NAT - a ściślej NAPT - brama. To, co próbujesz zrobić, nazywa się „spinką do włosów NAT” lub „spinką do włosów NAT”, w nawiązaniu do sposobu, w jaki dosłowna szpilka do włosów podwaja się sama (ta sama aluzja jest używana przez termin „obrót szpilki do włosów” dla ostrego zakrętu, w którym droga podwaja się sama).

Niektóre bramy NAT są bzdurne i nie obsługują przypinania włosów. Może być czas na zapoznanie się z opcjami aktualizacji.

Istnieje naprawdę prosta odpowiedź na to pytanie. NAT przeszkadza.

1. Twój komputer otwiera połączenie z [ExternalIP]
2. Twój router przekazuje to połączenie do [SSHInternalIP]. Twój serwer SSH widzi połączenie z [YourInternalIP].
3. Twój serwer SSH wysyła swoje pakiety do [YourInternalIP].
4. Twój komputer widzi dziwny pakiet pochodzący z adresu IP, z którym nigdy nie rozmawiał, i odrzuca go.
5. Połączenie z TCP / 22 nie powiedzie się, ponieważ 3-drożny uzgodnienie TCP nigdy się nie kończy.

Próbujesz porozmawiać z publicznym adresem IP, ale odpowiedzi pochodzą z wewnętrznego adresu IP. Twój komputer nie może połączyć tych dwóch elementów. Rozwiązaniem jest korzystanie z wewnętrznego adresu IP za każdym razem, gdy jesteś za routerem. Rozwiązuję ten problem na moich laptopach, używając różnych ciągów połączeń ssh w zależności od tego, gdzie jestem.

Z tego, co rozumiem po uruchomieniu routera OpenBSD z NAT, Spiff ma poprawną odpowiedź: napotkany problem jest spowodowany przez bramę NAT, która nie obsługuje tego, co próbujesz zrobić.

Stacja robocza wysyła pakiety ze źródłowym adresem IP adresu wewnętrznego (powiedzmy 10.0.0.2), ale adresem docelowym jest Twój zewnętrzny adres IP. Kiedy pakiety docierają do twojego serwera (SSH?) Na porcie 22, serwer odpowiada bezpośrednio na twoją stację roboczą i nie dzieje się żadne NAT; teraz, gdy twoja stacja robocza otrzyma odpowiedź z 10.0.0.3, kiedy oczekiwała odpowiedzi z twojego adresu zewnętrznego, odrzuca pakiety.

Wydaje się, że jest to trywialny problem, ale można go rozwiązać, aktualizując plik HOSTS stacji roboczej, dodając wewnętrzny serwer DNS (lub edytując wpisy serwera DNS) lub tworząc regułę NAT do obsługi wewnętrznych-> zewnętrznych-> wewnętrznych ruch drogowy.