tak podival sem se nato cez wiresharnek a zjistil sem ze na poslu TCP SYN paket a nedostavi se zadna odpoved ani jeden paket. Coz se samozrejme dalo predpokladat.
Tak to už bude horší.
tem nechapu, ale nevadi. To musela byt nejaka haluz.
Jakápak halůz?Pokud se budeme držet konvence:
Na 10.6.2.2:
-vygeneruje SYN paket s cílovou adresou 88.89.100.103 a zdrojovou 10.6.2.2
-Routovací tabulka se začne projížďet od shora dolů a jelikož tato adresa neleží na lokální síti, tak se bude pokračovat dokud se nenarazí na cíl 0.0.0.0/0(tedy default gateway) a podle něj se vyplní cílová MAC adresa na MAC adresu default gateway(10.6.2.1)
-Paket je připraven a tak se vypustí na drát a bude se očekávat SYN/ACK od cíle 88.89.100.103
Na 10.6.2.1:
-Dorazil paket s cílovou adresou 88.89.100.103 na rozhraní eth0 a MAC adresa odpovídá MAC adrese rozhraní eth0, ale cílová adresa nesedí, takže paket asi bude pokračovat a spustí se na Routeru celá ta mašinerie
-v PREROUTING chainu bude odpovídat cílová adresa paketu dst-address pravidla a je pro ni přichystána akce přepisu cílové adresy na 10.6.2.3(tedy WEB-Serveru), tudíž staň již se tak.
-Přejde se na samotné směrování a směrovací tabulka se začne projíždět od shora dolů dokuď se nenarazí na to, že 10.6.2.0/24 je v tabulce a je pro ni určeno rozhraní eth0(je na LAN)
-Paket je připraven a to s cílovou adresou 10.6.2.3 a zdrojovou adresou 10.6.2.2(o žádném manglování ani src-natu nebyla zatím řeč). Provedou se takové podřadnosti jako zjištenía doplnění MAC adresy a paket je neohroženě vyslán na drát vstříc svým osudům
Na 10.6.2.3:
-Dorazil SYN paket s portem na kterém běží služba, takže by nebylo od věci odpovědět SYN/ACK paketem.Zdrojová adresa odesilatele je 10.6.2.2
-Přejde se na určování kam vůbec paket vhodit.10.6.2.2 odpovídá 10.6.2.0/24, které je na LAN, takže se zjistí jeho MAC adresa a
-SYN/ACK Paket je vypuštěn na drát s zdrojovou adresou 10.6.2.3 a s cílovou 10.6.2.2
Znovu na 10.6.2.2:
-Ten ještě stále čeká na SYN/ACK Paket od 88.89.100.103 a když v tom, něco dorazilo
-SYN/ACK se zdrojovou adresou 10.6.3.2 a s cílovou adresou 10.6.2.2. 10.6.2.2 neví nic o tom, že by chtěl komunikovat s 10.6.2.3(ten přece čeká na potvrzení od 88.89.100.103), takže ignorace a paket je zahozen
-88.89.100.103 nějak neodpovídá, asi byl SYN paket po cestě ztracen, takže provede odeslání SYN paketu znova a znova mu dorazí odpověď od 10.6.2.3 a takto pořád dokola dokud mu nevyprší časový limit pro vytvoření spojení
-Cílový hostitel není dostupný a pohádky je konec
Už jinak fakt nevím jak to vysvětlit. Už by pomohla asi jenom tužka, papír a pivo.
88.89.100.103 je ma vlastni verejna ip adressa, s kterou ten mikrotik nema nic spolecneho. On skratka dela iba NAT. Podla teho vysse popsaneho pravidla, muj TCP SYN packet se src=10.6.2.2 a dst=88.89.100.103 dojde na mikrotik, mikrotik v POSTROUTE zameni src=10.6.2.2 za src=10.6.2.1 a vubec nechapu, jak se ten paket s dst=88.89.100.103 dostane na moje rozhrani 10.6.2.2.
Asi to bude trošku složitější. Jen ať si ujasníme topologii: Host.6.2.2 na LAN0, Router s DST-NAT pravidlem: 10.6.2.1 na LAN0, WEB-Server: 10.6.2.3 na LAN0
BTW.ěl by spíše být DST-NAT v PREROUTING chainu?
Jeste se chci zeptat, ma to pravidlo by pred ale az po mojich NAT pravidlach, teda
iptables -t nat -A PREROUTING -i eth0 -d 88.89.100.103 -j DNAT --to-destination 10.6.2.2
iptables -t nat -A POSTROUTING -o eth0 -s 10.6.2.2 -j SNAT --to-source 88.89.100.103
alebo natem nezalezi ?
Ano, po a v POSTROUTINGu. Ale když tak teď nad tím přemýšlím. Když SYN/ACK dorazí zpět na router ale s cílem 88.89.100.103, tak ten jej znova přeloží na adresu WEB-Serveru a ten ho odešle zase zpět serveru. Nebylo by lepší místo SNATu použít maškarádu?
